4 ms·

The short of it is C without the warts plus a few small quality of life improvements. The long of it: The competition right now in this space as I see it is: C

The short of it is C without the warts plus a few small quality of life improvements. The long of it: The competition right now in this space as I see it is: C, Rust, C++. Even C++ doesn't fully fit because you have to turn off language features like exceptions to have the guarantees you need for systems programming. So in turn. C hasn't really changed in 40 years so all it's warts are still intact and has specific pain points that will never be addressed. C++ conversely has added every language feature plus the kitchen sink over the past 30 years. People say: "Just don't use the features you don't want", but that is unrealistic when you have to interoperate with third party libraries etc. If you have to drop a large portion of the C++ ecosystem to use the subset of the language you like then you've lost a major benefit of choosing C++ in the first place. Rust, while being more thoughtful about it than C++, has provided a large set of features to work with. It is a much bigger language than C. It's also taken a very opinionated stance on safety with the borrow checker which causes a large learning curve and a lot of mental overhead. Finally Zig is an attempt to be more safe than C where it can without being as overbearing as Rust. Add just the necessary features that a huge boost to quality of life while not flooding the programmers mental model of the language. I think of it as kind of a C+.

rapsey 8y ago
Rust's borrow checker does not have a lot of mental overhead while working once you are moderately proficient. It imposes design constraints that in the end work out for the better. This is why Rust users are so fanatical about it.
- foldr 8y ago
  This is only true in cases where a single ownership model makes sense. In cases where it doesn't, there is a definite overhead. I think even the strongest Rust advocates would not deny the existence of this overhead. They'd just point out that you'd have the same overhead in C++, but without the compiler helpfully telling you when you've made a mistake. I'd also add that there are (small) warts on Rust's current implementation of borrow checking which everyone agrees are minor annoyances, even to experienced users: https://github.com/rust-lang/rust/issues/43234 https://github.com/rust-lang/rust/issues/43234 Judging by that issue thread, some of these issues are about to be fixed.
- jeremycw 8y ago
  > It imposes design constraints that in the end work out for the better. I feel the jury is still out on this. It does impose design constraints that remove a certain subclass of errors, whether this correlates to actually causing better designed programs in the sense of readability, maintainability, etc. I'm unsure. I understand the desire for this to be true and I feel that some of the fanaticism around the language is the belief that this is true. Developers like to have the 'one true way' to solve problems. Go's popularity I feel is in part because of this as well but achieved it by having a bare bones language with less options instead of a restrictive compiler. If you take the 'restrictive compiler' argument to its logical conclusion for a program that accepts input x and produces output y there would only be one valid way to code this program. This would be good in the sense that presumably the compiler has proven that your program works and is correct. On the other hand though I have no inclination to believe that this program would be the most understandable, modifiable way to get from x -> y.
  - sephware 8y ago
    Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve, which can be confusing and counterproductive when choosing a language because of the classes of errors it aims to solve (often a big motivator in both designing and choosing a language; see Swift and Go).
    - vram22 8y ago
      >Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve What are some of those?
      - steveklabnik 8y ago
        The big one is memory leaks. People also assume “race conditions” instead of “data races.”
        8y ago
sephware 8y ago
Thanks for that. So far Zig sounds amazing. They should have something like this on their home page.
SwellJoe 8y ago
"If you have to drop a large portion of the C++ ecosystem to use the subset of the language you like then you've lost a major benefit of choosing C++ in the first place." But, it'll still be orders of magnitude larger than the Zig ecosystem is likely to be anytime in the next couple of decades. I'm not saying one shouldn't use Zig or that one should use C++...I've never been able to grok C++, as it is far too large for the small amount of time I have to spend on learning about systems languages (I can barely read it, much less write it effectively). I just think it's weird to argue for Zig with a point about ecosystem size. Zig will likely never look good on that metric, compared to C or C++.
hawski 8y ago
I know that is superficial, but although Rust has many great features it looks too much like C++ for me. All those :: and template<likes> are making it look too busy for me. Also type inference looks a bit too powerful - it may make things easier to write, but harder to read. Personally I cheer for Zig and think that it has the biggest potential to really become a C replacement for me. Other then that I hope that Myrddin [0] will see stable development till 1.0 and beyond. Myrddin has my vote, because it uses QBE [1] compiler backend instead of LLVM. Now that I think about it it would be cool to see Zig on QBE. I just don't think that the current LLVM monoculture is healthy in a long run. Maybe I'm weird, but I would like to imagine a language like Zig compiled also to DEX for Android and CIL for Windows. Then it could have mostly free platform-native calls. So one could really write truly first-class cross-platform apps. [0] https://myrlang.org/ https://myrlang.org/ [1] https://c9x.me/compile/ https://c9x.me/compile/
- AndyKelley 8y ago
  > it would be cool to see Zig on QBE. from https://c9x.me/compile/ https://c9x.me/compile/: > Text input only. A C library interface is work in progress. this is a bit of a non-starter > Some ongoing work on the Myrddin compiler aims to use QBE as backend. sounds like myrddin does not use QBE as a backend. ---- It is unlikely that Zig will ever use QBE as a backend, optional or otherwise. However, it is quite possible that in some distant future Zig has its own backend that avoids the LLVM dependency entirely. This would be in pursuit of fast compile times.
  - hawski 8y ago
    Oh. You're right. My bad. I thought that they are pretty focused on QBE switch and as Myrddin is still in quite early phase of development I thought it's not much of a difference. Well looking at public commits in main branches it seems that QBE development is not really active. Too bad. I hope that there's a flame remaining. I'm not tracking mailing lists either. It's great to hear that a home grown backend is something even considered for future. I know that it's a long way there, but that's life. Thank you for your efforts with Zig. From all the new systemish languages I find Zig with it's current momentum the most probable to become the C replacement for me.

rapsey 8y ago

Rust's borrow checker does not have a lot of mental overhead while working once you are moderately proficient. It imposes design constraints that in the end work out for the better. This is why Rust users are so fanatical about it.

foldr 8y ago
This is only true in cases where a single ownership model makes sense. In cases where it doesn't, there is a definite overhead. I think even the strongest Rust advocates would not deny the existence of this overhead. They'd just point out that you'd have the same overhead in C++, but without the compiler helpfully telling you when you've made a mistake. I'd also add that there are (small) warts on Rust's current implementation of borrow checking which everyone agrees are minor annoyances, even to experienced users: https://github.com/rust-lang/rust/issues/43234 https://github.com/rust-lang/rust/issues/43234 Judging by that issue thread, some of these issues are about to be fixed.
jeremycw 8y ago
> It imposes design constraints that in the end work out for the better. I feel the jury is still out on this. It does impose design constraints that remove a certain subclass of errors, whether this correlates to actually causing better designed programs in the sense of readability, maintainability, etc. I'm unsure. I understand the desire for this to be true and I feel that some of the fanaticism around the language is the belief that this is true. Developers like to have the 'one true way' to solve problems. Go's popularity I feel is in part because of this as well but achieved it by having a bare bones language with less options instead of a restrictive compiler. If you take the 'restrictive compiler' argument to its logical conclusion for a program that accepts input x and produces output y there would only be one valid way to code this program. This would be good in the sense that presumably the compiler has proven that your program works and is correct. On the other hand though I have no inclination to believe that this program would be the most understandable, modifiable way to get from x -> y.
- sephware 8y ago
  Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve, which can be confusing and counterproductive when choosing a language because of the classes of errors it aims to solve (often a big motivator in both designing and choosing a language; see Swift and Go).
  - vram22 8y ago
    >Also, there are many classes of errors that Rust doesn't help solve, but which people seem to get the impression that it does aim to solve What are some of those?
    - steveklabnik 8y ago
      The big one is memory leaks. People also assume “race conditions” instead of “data races.”
      - 8y ago

sephware 8y ago

Thanks for that. So far Zig sounds amazing. They should have something like this on their home page.

SwellJoe 8y ago

"If you have to drop a large portion of the C++ ecosystem to use the subset of the language you like then you've lost a major benefit of choosing C++ in the first place." But, it'll still be orders of magnitude larger than the Zig ecosystem is likely to be anytime in the next couple of decades. I'm not saying one shouldn't use Zig or that one should use C++...I've never been able to grok C++, as it is far too large for the small amount of time I have to spend on learning about systems languages (I can barely read it, much less write it effectively). I just think it's weird to argue for Zig with a point about ecosystem size. Zig will likely never look good on that metric, compared to C or C++.

hawski 8y ago

I know that is superficial, but although Rust has many great features it looks too much like C++ for me. All those :: and template<likes> are making it look too busy for me. Also type inference looks a bit too powerful - it may make things easier to write, but harder to read. Personally I cheer for Zig and think that it has the biggest potential to really become a C replacement for me. Other then that I hope that Myrddin [0] will see stable development till 1.0 and beyond. Myrddin has my vote, because it uses QBE [1] compiler backend instead of LLVM. Now that I think about it it would be cool to see Zig on QBE. I just don't think that the current LLVM monoculture is healthy in a long run. Maybe I'm weird, but I would like to imagine a language like Zig compiled also to DEX for Android and CIL for Windows. Then it could have mostly free platform-native calls. So one could really write truly first-class cross-platform apps. [0] https://myrlang.org/ https://myrlang.org/ [1] https://c9x.me/compile/ https://c9x.me/compile/

AndyKelley 8y ago
> it would be cool to see Zig on QBE. from https://c9x.me/compile/ https://c9x.me/compile/: > Text input only. A C library interface is work in progress. this is a bit of a non-starter > Some ongoing work on the Myrddin compiler aims to use QBE as backend. sounds like myrddin does not use QBE as a backend. ---- It is unlikely that Zig will ever use QBE as a backend, optional or otherwise. However, it is quite possible that in some distant future Zig has its own backend that avoids the LLVM dependency entirely. This would be in pursuit of fast compile times.
- hawski 8y ago
  Oh. You're right. My bad. I thought that they are pretty focused on QBE switch and as Myrddin is still in quite early phase of development I thought it's not much of a difference. Well looking at public commits in main branches it seems that QBE development is not really active. Too bad. I hope that there's a flame remaining. I'm not tracking mailing lists either. It's great to hear that a home grown backend is something even considered for future. I know that it's a long way there, but that's life. Thank you for your efforts with Zig. From all the new systemish languages I find Zig with it's current momentum the most probable to become the C replacement for me.