this post was submitted on 03 Oct 2024
38 points (86.5% liked)

Programming

17202 readers
424 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities [email protected]



founded 1 year ago
MODERATORS
 

Zig vs Rust. Which one is going to be future?

I think about pros and cons and what to choose for the second (modern) language in addition to C.

@[email protected]

(page 2) 30 comments
sorted by: hot top controversial new old
[–] [email protected] 2 points 1 week ago (1 children)

What are your goals?

If you want to learn another language just for the fun of it (the best reason) than learn both.

Of you want to improve your tool set to be able to land a job, then there is no good answer. Probably some other high level language like Python, Java, JavaScript, C#. Etc.

Also: Zig bay be easier to get started when coming from C, because it is mostly imperative.

Rust introduces concepts from functional programming. This could be interesting for you, of you don't have any experience in functional programming to get in touch with other programming styles. Or not, of you explicitly don't want to learn such things.

I use both languages, and I enjoy both. Shameless plug: I've written a blog post ~ 2 years ago what I like about each language: https://zigurust.gitlab.io/blog/posts/three-things/

[–] [email protected] 1 points 1 week ago

Rust introduces concepts from functional programming.

I'd rather go with Erlang.

[–] [email protected] 1 points 1 week ago (1 children)
load more comments (1 replies)
[–] [email protected] -2 points 1 week ago (6 children)

I'd say if you're happy with #C, there's no need to choose any second language. 🤷

Before even looking at any alternatives, the question should be "why not C". Some of the typical complaints are:

  • memory safety – or, more generally, the fact that C is only partially defined, leaving a lot to the dangerous area of undefined behavior. There's no way to reliably detect undefined behavior by static code analysis, and it will often hide well at runtime. Especially errors regarding memory management often directly expose security vulnerabilities. In my experience, the risk can be reduced a lot by some good coding and design practices. Examples are avoiding magic numbers, using sizeof everywhere possible, preferably on expressions instead of type names, defining clear ownership of allocated objects (and, where not possible, add manual reference counting), making ownership explicit by using const where appropriate and naming your functions well, and so on. Given also there's no guarantee alternative languages will safeguard you from all the possible issues and there are also a lot of other ways to create security vulnerabilities, my take on this would be: partially valid.
  • programming paradigm – you can only program in classic procedural style. Well, that's simply not true. First of all, you can program whatever you want in any turing-complete language, so what we talk about shouldn't be what's directly supported by the constructs of the language, but what's practically usable. In C, using some simple OOP is commonplace. Well, you can apply OOP to assembler programming without too much hassle, so, it's not surprising you can do it in C, as it's a pretty thin abstraction on top of machine code. C helps further with its linkage rules, where everything in a compilation unit is by default inaccessible to other units, and its incomplete types, where only a type name is known, but neither its size nor inner structure, giving you almost perfect information hiding for free. If you want/need polymorphism, it gets a bit more complicated (you have to think about how you identify types and manage virtual tables for them), but still perfectly doable. You'll hit the practical limits of the language when you want to go functional. The very basics are possible through function pointers, but most concepts of functional programming can't be applied to C in a somewhat sane way. Unless that's what you need, my take would be: invalid.
  • limited standard lib. Indeed, the C standard library misses lots of things that are often needed, for example generic containers like lists, hashtables, queues, etc. It's straight-forward to build them yourself, but then, there are many ways to do that (with pros and cons). You'll find tons of different implementations, many non-trivial libraries bring their own, of course this also increases the risk to run into buggy ones ... I wouldn't consider it a showstopper, but I'd mark this complaint as: valid.

Then, the next question would be: For what purpose are you looking for a second language?

For applications and services, there's already a wide range of languages used, and I'd say do what everyone does and pick what you're most comfortable with and/or think best suits the job. IOW, it makes little sense to ask what would be "the future", there have always been many different languages used, just pick one that's unlikely to quickly disappear again, so you'd have to restart from scratch.

For systems programming "the future" has been C for many decades 😏 ... some people want to change that, actually for good reasons. IMHO, the current push for #Rust (I don't see anything similar regarding #Zig yet?) into established operating systems is dangerous. An operating system is very different from individual apps and services. It's required by these as a reliable and stable (in terms of no breaking changes) platform. It's complex and evolves over an extremely long period of time. It needs to interface with all sorts of hardware using all sorts of machine mechanisms (PIO, DMA, MMIO, etc pp). I conclude it needs a very stable, proven and durable programming language. You'll find C code from the 30 years ago that just still builds and works. IMHO a key factor is that there's an international standard for the C language, governed by a standards body that isn't controlled by any individual group. And correlated to that, there are many different implementations of the language. Before considering any different language in core areas of an established operating system, I'd like to see similar for that new language.

Now, C was developed more or less together with #Unix, so back then, nobody knew it would be such a success, of course there was no standard yet. But then, I think this is the sane way to introduce a new systems programming language: Use it in a new (research?) OS.

[–] [email protected] 1 points 1 week ago

Thank you for such extended answer, I appreciate it.
Thank you for your experience!

load more comments (5 replies)
load more comments
view more: ‹ prev next ›