8 ms·

I'd be interested in "Why Zig over Rust?". Having dabbled with Rust, it seems to be the perfect solution/replacement for C/C++. I'm not clear why I should both

I'd be interested in "Why Zig over Rust?". Having dabbled with Rust, it seems to be the perfect solution/replacement for C/C++. I'm not clear why I should bother with an alternative.

xtian 6y ago
The Zig site has an answer: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/
linkdd 6y ago
> it seems to be the perfect solution/replacement for C/C++ Many languages tried for 50 years to replace C without success. While Rust brings many improvements for low-level development on classical architecture, simplifying hard problems (especially memory safety), there is still a HUGE number of platforms (embedded ones mainly?) where C and even Assembly are still relevant. Believing that any language will burry C/C++ is ignoring what C/C++ are.
socialdemocrat 6y ago
I have spent some time with Rust and written some non-trivial Zig code (a simpler assembler). My simple take-away is that Rust is simply too complicated. I spend some time on other technologies on occasion. I could get into Zig fairly quickly and do some useful stuff with it. With Rust it felt like I had to really decide on some significant time investment to be able to get anything done. It really reminds me a lot of Haskell. Those kinds of pure, elegant languages which are awesome once you grok them, but which is never really going to be used apart from in a small niche because they are too hard to learn from an average developer with limited time on his hands. Rust and Haskell is more like the languages I looked for when I was younger. When I had these utopian visions of THE best programming language. I have long lost any belief in that. I do think strong type systems are helpful, but I also think they tend to get overhyped and overrated. I am with Rob Pike, one of the Go designers on this. Writing correct code is a lot about understanding and being able to reason about that code. A simpler language makes it easier to reason about code and understand it. That makes it more likely that you make the code correct or is able to maintain and fix it. I do believe this complexity barrier begins at different places for different people. But for me I think Rust is too complex. Knowing myself I would get back to 3-4 weeks old code and wonder what the hell I wrote. If you get into that situation you are likely to make mistakes. This is what I believe developers often forget when chasing down the BEST tool. That ultimately it is your brain that is supposed to solve problems not the tool. If a tool solves some problems but reduce your brains ability to do its job, then the tool isn't really an aid. To be honest I am not actually certain if Zig has hit the sweat spot either. Go is quite good. You can pick up quite old Go code and still read it with relative ease. Zig is definitely not as easy as Go to read. I feel like I have to wait until a 1.0 release before passing judgment. Some of the issues I felt I had with Zig is down to lack of documentation and rough edges in the standard library.
- dm3 6y ago
  I really enjoyed your comment. Probably because I've been thinking the same for a long time now. I've had to learn and write a lot of C++ in the past year and the only way to stay sane is to use as small subset of the beast as possible. In many ways Rust is a better C++ - no undefined behaviour, no lvalues/rvalues/xvalues/..., complicated move semantics, tooling, etc. Rust feels like a nice subset of C++ with additional safety features on top. However, once people reach for C, C++, Rust or Zig - performance is on the line. To push the maximum out of the program we need to do as much compile-time programming as possible. C++ template meta-programming language is Turing-complete but extremely hard to learn and effectively program with. Rust compile-time programming is evolving - two sorts of macros and a Zig-comptime-like `const fn` feature. What I like about Zig's approach is summarized well by pron[0]. [0]: https://news.ycombinator.com/item?id=22112382 https://news.ycombinator.com/item?id=22112382
cageface 6y ago
It looks like Zig requires manual memory magagement, right? That seems like a pretty big downside compared to GC or the Rust approach.
- linkdd 6y ago
  That's because the Zig approach is "no hidden control flow". Everything in Zig is explicit, this is not a downside, this is a feature of the language. Choose the tool that best fits your needs.
  - cageface 6y ago
    That's fair but that does mean that I wouldn't consider it unless I really needed that kind of control. That's a niche few devs need to worry about.
    - linkdd 6y ago
      One advantage of that kind of control is that your code does not depend of the implementation of any abstraction (except the operating system if any?) since everything is written "in stone". I also think it makes a great learning tool, mainly to understand: - how a GC or memory management is/should be implemented - what pain points they solve (or: why they are important) When you don't have to think about the abstractions but only your code, it prevents the student from being confused about what happens when. But I would not use it in production, just like you said, because in production, I want to maintain as little code as possible, and delegate the complexity to other better tools/people.
    - mtzet 6y ago
      Well the choices so far seems to be manual memory allocation, RAII or GC. The complexity of C++/Rust indicates that RAII is certainly not a panacea either. GC offers distinct trade-offs as well. Zig takes a stab at the problem by trying to make manual memory management more ergonomic. I've been pleasantly surprised at how easy I found it to do tasks in Zig I would otherwise have used a scripting language like Python for. If go's fast GC is taking a stab at C's territory, then I think Zig is taking a stab at the managed runtime's territory. Ultimately the judge is still out.
enriquto 6y ago
> Rust, it seems to be the perfect solution/replacement for C/C++ If you are the sort of person who writes "C/C++" you'll have some trouble understanding the purpose of Zig... maybe start by grokking why the expression "C/C++" is nonsensical?
- thraway123412 6y ago
  Look bro I like Haskell so Haskell is a perfect replacement for Scheme/Java.
- flohofwoe 6y ago
  Argh I'm so tired of this "technicality". Yes, technically C and C++ are different languages, and C is not a subset of C++ (which is a pretty big problem btw). But C++ has been derived from C, then forked its C subset into an incompatible dialect, while not fixing any of C's problems (which would've been an actually good reason to not call it "C/C++"). I think it's fair to call C++ "C/C++", because it will always be a confusing mishmash of C and the features that C++ added on top. Sorry about the rant.
  - thraway123412 6y ago
    The problem is that we have no idea what you're talking about when you say C/C++. For you it seems to be C++, for someone else it might be both or it might be "one or the other but I don't know which." For yet someone else it might be really just C. If you were to think that Rust is a good replacement for C++, why not just say that Rust is a good replacement for C++? That makes it clear what you mean, and thus the obvious follow-up: a lot of people would like a replacement for C, which is arguably not what Rust is. And this is very on-topic for a discussion where someone asked "why Zig over Rust?" Zig is arguably closer in spirit to C than Rust is. When you say Rust is a good replacement for C/C++, a lot of people read it as if you were treating C and C++ as one language and that Rust is a good replacement for both. It should not be hard to see why this is very controversial, given that they are very different languages and people tend to like one and dislike the other. It's going to be very hard to please both camps.
efiecho 6y ago
The ubiquitous SJW bullshit in the Rust community made me run for the hills. http://www.paulgraham.com/say.html http://www.paulgraham.com/say.html
- dunefox 6y ago
  Like what?
  - logicchains 6y ago
    They canceled the guy who wrote the fastest Rust web framework because he wasn't apologetic enough about using too much unsafe code.
    - dunefox 6y ago
      But that's unrelated to "social justice", isn't it? It is idiotic nonetheless.

I'd be interested in "Why Zig over Rust?". Having dabbled with Rust, it seems to be the perfect solution/replacement for C/C++. I'm not clear why I should bother with an alternative.

xtian 6y ago

The Zig site has an answer: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/

linkdd 6y ago

> it seems to be the perfect solution/replacement for C/C++ Many languages tried for 50 years to replace C without success. While Rust brings many improvements for low-level development on classical architecture, simplifying hard problems (especially memory safety), there is still a HUGE number of platforms (embedded ones mainly?) where C and even Assembly are still relevant. Believing that any language will burry C/C++ is ignoring what C/C++ are.

socialdemocrat 6y ago

I have spent some time with Rust and written some non-trivial Zig code (a simpler assembler). My simple take-away is that Rust is simply too complicated. I spend some time on other technologies on occasion. I could get into Zig fairly quickly and do some useful stuff with it. With Rust it felt like I had to really decide on some significant time investment to be able to get anything done. It really reminds me a lot of Haskell. Those kinds of pure, elegant languages which are awesome once you grok them, but which is never really going to be used apart from in a small niche because they are too hard to learn from an average developer with limited time on his hands. Rust and Haskell is more like the languages I looked for when I was younger. When I had these utopian visions of THE best programming language. I have long lost any belief in that. I do think strong type systems are helpful, but I also think they tend to get overhyped and overrated. I am with Rob Pike, one of the Go designers on this. Writing correct code is a lot about understanding and being able to reason about that code. A simpler language makes it easier to reason about code and understand it. That makes it more likely that you make the code correct or is able to maintain and fix it. I do believe this complexity barrier begins at different places for different people. But for me I think Rust is too complex. Knowing myself I would get back to 3-4 weeks old code and wonder what the hell I wrote. If you get into that situation you are likely to make mistakes. This is what I believe developers often forget when chasing down the BEST tool. That ultimately it is your brain that is supposed to solve problems not the tool. If a tool solves some problems but reduce your brains ability to do its job, then the tool isn't really an aid. To be honest I am not actually certain if Zig has hit the sweat spot either. Go is quite good. You can pick up quite old Go code and still read it with relative ease. Zig is definitely not as easy as Go to read. I feel like I have to wait until a 1.0 release before passing judgment. Some of the issues I felt I had with Zig is down to lack of documentation and rough edges in the standard library.

dm3 6y ago
I really enjoyed your comment. Probably because I've been thinking the same for a long time now. I've had to learn and write a lot of C++ in the past year and the only way to stay sane is to use as small subset of the beast as possible. In many ways Rust is a better C++ - no undefined behaviour, no lvalues/rvalues/xvalues/..., complicated move semantics, tooling, etc. Rust feels like a nice subset of C++ with additional safety features on top. However, once people reach for C, C++, Rust or Zig - performance is on the line. To push the maximum out of the program we need to do as much compile-time programming as possible. C++ template meta-programming language is Turing-complete but extremely hard to learn and effectively program with. Rust compile-time programming is evolving - two sorts of macros and a Zig-comptime-like `const fn` feature. What I like about Zig's approach is summarized well by pron[0]. [0]: https://news.ycombinator.com/item?id=22112382 https://news.ycombinator.com/item?id=22112382

cageface 6y ago

It looks like Zig requires manual memory magagement, right? That seems like a pretty big downside compared to GC or the Rust approach.

linkdd 6y ago
That's because the Zig approach is "no hidden control flow". Everything in Zig is explicit, this is not a downside, this is a feature of the language. Choose the tool that best fits your needs.
- cageface 6y ago
  That's fair but that does mean that I wouldn't consider it unless I really needed that kind of control. That's a niche few devs need to worry about.
  - linkdd 6y ago
    One advantage of that kind of control is that your code does not depend of the implementation of any abstraction (except the operating system if any?) since everything is written "in stone". I also think it makes a great learning tool, mainly to understand: - how a GC or memory management is/should be implemented - what pain points they solve (or: why they are important) When you don't have to think about the abstractions but only your code, it prevents the student from being confused about what happens when. But I would not use it in production, just like you said, because in production, I want to maintain as little code as possible, and delegate the complexity to other better tools/people.
  - mtzet 6y ago
    Well the choices so far seems to be manual memory allocation, RAII or GC. The complexity of C++/Rust indicates that RAII is certainly not a panacea either. GC offers distinct trade-offs as well. Zig takes a stab at the problem by trying to make manual memory management more ergonomic. I've been pleasantly surprised at how easy I found it to do tasks in Zig I would otherwise have used a scripting language like Python for. If go's fast GC is taking a stab at C's territory, then I think Zig is taking a stab at the managed runtime's territory. Ultimately the judge is still out.

enriquto 6y ago

> Rust, it seems to be the perfect solution/replacement for C/C++ If you are the sort of person who writes "C/C++" you'll have some trouble understanding the purpose of Zig... maybe start by grokking why the expression "C/C++" is nonsensical?

thraway123412 6y ago
Look bro I like Haskell so Haskell is a perfect replacement for Scheme/Java.
flohofwoe 6y ago
Argh I'm so tired of this "technicality". Yes, technically C and C++ are different languages, and C is not a subset of C++ (which is a pretty big problem btw). But C++ has been derived from C, then forked its C subset into an incompatible dialect, while not fixing any of C's problems (which would've been an actually good reason to not call it "C/C++"). I think it's fair to call C++ "C/C++", because it will always be a confusing mishmash of C and the features that C++ added on top. Sorry about the rant.
- thraway123412 6y ago
  The problem is that we have no idea what you're talking about when you say C/C++. For you it seems to be C++, for someone else it might be both or it might be "one or the other but I don't know which." For yet someone else it might be really just C. If you were to think that Rust is a good replacement for C++, why not just say that Rust is a good replacement for C++? That makes it clear what you mean, and thus the obvious follow-up: a lot of people would like a replacement for C, which is arguably not what Rust is. And this is very on-topic for a discussion where someone asked "why Zig over Rust?" Zig is arguably closer in spirit to C than Rust is. When you say Rust is a good replacement for C/C++, a lot of people read it as if you were treating C and C++ as one language and that Rust is a good replacement for both. It should not be hard to see why this is very controversial, given that they are very different languages and people tend to like one and dislike the other. It's going to be very hard to please both camps.

efiecho 6y ago

The ubiquitous SJW bullshit in the Rust community made me run for the hills. http://www.paulgraham.com/say.html http://www.paulgraham.com/say.html

dunefox 6y ago
Like what?
- logicchains 6y ago
  They canceled the guy who wrote the fastest Rust web framework because he wasn't apologetic enough about using too much unsafe code.
  - dunefox 6y ago
    But that's unrelated to "social justice", isn't it? It is idiotic nonetheless.