5 ms·

> This year, I decided to look into Zig. Both Zig and Rust are more or less in the same space, replacing C. Maybe we should think about this in terms of space

by Zababa 5y ago

> This year, I decided to look into Zig. Both Zig and Rust are more or less in the same space, replacing C. Maybe we should think about this in terms of space occupied by the languages and not the language themselves. One of the features of C is that pretty much anything can interface with it. Another is that you can write very fast code with it. Another is that pretty much any platform has a C compiler. Another is that it's small and fits in your head. Depending on what you're trying to do, you might use one "C replacement" or another. Another way of looking at it would be to see the shortcomings of C you're trying to overcome. I think this way of thinking would be more productive than just thinking about "replacing C", "replacing C++" or things like that.

xhealthgothx 5y ago
Zig libraries can be exported with the C ABI[0], so pretty much anything can interface with it. You can write very fast code with it. It is also small and fits in your head. The only thing missing is a variety of implementations, however there is a clear path to bootstrapping the compiler from source with a semi-recent C++ compiler[1] and from there, there's already a growing number of supported targets[2]. There is also a major focus on making sure cross-compilation is well supported out of the box, including C code that Zig can also compile[3]. It's perfectly fair to compare Zig to C in this case, as the project originated as a dialect of C before the author decided to do a complete clean break[4]. The primary frame of reference when designing the language was C and addressing its shortcomings, both language and tooling. [0]: https://ziglang.org/learn/overview/#export-functions-variables-and-types-for-c-code-to-depend-on https://ziglang.org/learn/overview/#export-functions-variabl... [1]: https://github.com/ziglang/zig-bootstrap https://github.com/ziglang/zig-bootstrap [2]: https://ziglang.org/download/0.8.0/release-notes.html#Support-Table https://ziglang.org/download/0.8.0/release-notes.html#Suppor... [3]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace... [4]: https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g
- Zababa 5y ago
  I'll restate my point: sometimes when replacing C people want something that's just as fast but also way more safe, and in that case will usually reach out for Rust. That's what the people doing the cryptography in Python did. Rust can also expose a C ABI, you can write code as fast as C. People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. This is why I think talking about what you're trying to achieve is more fruitful than just talking about the language you want to replace. For example, if you want to replace C code and you don't need all of the performance in the world, you couold simply switch to a garbage collected language. In that case, since speed wasn't the most important requirement, a language that isn't usually thought as a C replacement can replace C code. If you want to make the point that Zig is "closer to C" compared to other language that wants to replace C, that's a fair claim to make.
  - xhealthgothx 5y ago
    Rust is also not 'small and fits in your head', so that's yet another point it is missing in your initial set of criteria. Its main implementation and library also emits rather large binaries in the usual case. You may not find this important, but others do.
    - Zababa 5y ago
      I addressed that point: > People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. For some people, having a language that's small and fits in your head is not a requirement, not a priority, and sometimes not even important.
    - nicoburns 5y ago
      As others have pointed out, neither is C if you take into account avoiding UB, the preprocessor, the build systems, the many stdlib functions you need to avoid, etc. You might already know how these work, but that doesn't mean there's less to learn than a language like Rust.
oddity 5y ago
Absolutely! A common example I like to use is Java. It might be hard to imagine now, but there was a time where Java (and then C#) were pitched as a replacements to C++ (even the name "C#" supposedly derived from "C++++"). There was no reason to write native code any more, many people said. And, they were kind of right. Many people were writing applications in C++ because they thought they had to, even though they weren't writing C++ in the style needed to make proper use of it. A lot of old C++ code bases today look like much more verbose Java applets. This peeling, when it happens, is usually good for everyone since languages (and tools) evolve to better fit the domains in which they are most used and happens so gradually that few notice. The inverse also happens, but with more conflict: you can see this today in Python (and other dynamic languages) adopting typing features aimed at assisting tooling for large code bases, well beyond the traditional learning or glue scripting mentality for which they were designed. This often results fierce debates around language features (like static typing vs dynamic typing) that are really proxy battles for the usage intent of the language. Unfortunately, I think the "replacing X language" mentality happens because it's the easiest point to start with. The field of programming and computers is so vast now that most (all?) people have a very narrow view and it's easy to assume it's universal. I've lost track of all the "things all programmers should read/know/do" articles.
- Zababa 5y ago
  > Unfortunately, I think the "replacing X language" mentality happens because it's the easiest point to start with. The field of programming and computers is so vast now that most (all?) people have a very narrow view and assume it's universal. I've lost track of all the "things all programmers should read/know/do" articles. I think another effect is that if you really like a language, promoting it is one of the best thing you can do to work with it. When you see the recent (2010 and later) new languages, they all have a story of addressing a particular pain point. Typescript is Javascript at scale, Kotlin is old Java on android, Go is web services, Rust is performance and safety. This is solid marketing, and is part of how these languages end up dominating their domains. On the other hand, a language that's "X but slighly better everywhere" won't really attract people, since there is already code and jobs in that language. Currently in the Great War Of Replacing C And C++, there are lots of fighters. Some people promote Rust, some others Go, some others D, some others Zig, some others to just keep writing C and C++. Part of the battle is writing code, libraries. Part of the battle is making the language and tooling itself better. And part of the battle is making articles, comments, talking to people and promote your language.
mypalmike 5y ago
I think there's an implicit, often unspoken list of C shortcomings wherever these replacement languages are concerned. Some of the most obvious ones are: Macro hell, transitive include hell, and the ease with which even experienced developers can unwittingly create unsafe code.
- rightbyte 5y ago
  > Macro hell I can hardly think of any language addon more innocent than Cpp (the preprocessor). Imagine what madness would have emerged if it had proper variable assignment, goto:s or any loop construct?
- cassepipe 5y ago
  Well Zig addresses all of those
  - lerno 5y ago
    Well, except for Zig has the dubious distinction of actually having more UB than C.
oconnor663 5y ago
> Another is that it's small and fits in your head. I know this is a common view, but I want to highlight some counterexamples: - C programmers need to learn about many different forms of UB: https://blog.regehr.org/archives/1520 https://blog.regehr.org/archives/1520. Most take years to learn these rules. Many never learn them. - Most real world C programs use some nonstandard language extensions on some target platforms. C learners trying to read production code have to navigate these. - The C compilation and linking model is complicated and platform dependent. Compilation is a major stumbling block for students who have to learn Make or CMake at the same time they learn C. There is some truth to the "C is simple" idea, I'll grant that. It's obviously simpler than C++. But I think there's a big effect where we tend to forget how hard it was to learn, because we learned it so long ago. There's also been substantial progress since the 70's on designing simpler programming languages.
- Zababa 5y ago
  That's a good point. I personally don't share this view, and it's also not something I look for in a language. But people using C currently seem to be very attached to this, and knowing how to connect to your audiance is important.
- surajs 5y ago
  A reduced feature/keyword set does not a simple language make. C is smaller, but definitely not simpler. Also definition of simplicity is context dependent, I would say in many scenarios C++ turns out to be the simpler choice.
- alfiedotwtf 5y ago
  Thanks! This is probably the first time I've heard C called not a small language. Perl was my main language for over a decade, and when I wanted to go lower, I honestly struggled... but not with the language itself, with the peripherals which are exactly what you described!
  - SAI_Peregrinus 5y ago
    C is small, but it's not simple or easy to get right.
0-_-0 5y ago
Nim compiles to C, so it can be a drop in replacement.
- Zababa 5y ago
  I think you should be a bit more precise on exactly when. If it compiles to C, that means that it inherits from C the great platform support. I don't know much about it, so I can't judge Nim on other qualities that people attribute to C: you can call it from pretty much any language, it's seen as simple, you can write highly performant code in it, you can use it in very restricted environments, and I'm probably forgetting some others.
  - jasfi 5y ago
    It's also very easy to write Nim, the syntax has been compared to Python.
    - Zababa 5y ago
      Honestly, I don't think these kind of drive-by shallow comments are selling anyone on Nim. Many people here have posted long and insightful comments about the complexities of replacing C and some other topics, and two of the three comments about Nim are a bit shallow.
      - 0-_-0 5y ago
        I'm on my phone, otherwise I would have written more
auxym 5y ago
I think the fact that Nim compiles to C is neat in that you can use it on any platform that has a C compiler. Here is a recent project that uses nim for AVR platforms, for example: https://github.com/PMunch/badger https://github.com/PMunch/badger

by Zababa 5y ago

xhealthgothx 5y ago

Zig libraries can be exported with the C ABI[0], so pretty much anything can interface with it. You can write very fast code with it. It is also small and fits in your head. The only thing missing is a variety of implementations, however there is a clear path to bootstrapping the compiler from source with a semi-recent C++ compiler[1] and from there, there's already a growing number of supported targets[2]. There is also a major focus on making sure cross-compilation is well supported out of the box, including C code that Zig can also compile[3]. It's perfectly fair to compare Zig to C in this case, as the project originated as a dialect of C before the author decided to do a complete clean break[4]. The primary frame of reference when designing the language was C and addressing its shortcomings, both language and tooling. [0]: https://ziglang.org/learn/overview/#export-functions-variables-and-types-for-c-code-to-depend-on https://ziglang.org/learn/overview/#export-functions-variabl... [1]: https://github.com/ziglang/zig-bootstrap https://github.com/ziglang/zig-bootstrap [2]: https://ziglang.org/download/0.8.0/release-notes.html#Support-Table https://ziglang.org/download/0.8.0/release-notes.html#Suppor... [3]: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replacement-gcc-clang.html https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace... [4]: https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g

Zababa 5y ago
I'll restate my point: sometimes when replacing C people want something that's just as fast but also way more safe, and in that case will usually reach out for Rust. That's what the people doing the cryptography in Python did. Rust can also expose a C ABI, you can write code as fast as C. People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. This is why I think talking about what you're trying to achieve is more fruitful than just talking about the language you want to replace. For example, if you want to replace C code and you don't need all of the performance in the world, you couold simply switch to a garbage collected language. In that case, since speed wasn't the most important requirement, a language that isn't usually thought as a C replacement can replace C code. If you want to make the point that Zig is "closer to C" compared to other language that wants to replace C, that's a fair claim to make.
- xhealthgothx 5y ago
  Rust is also not 'small and fits in your head', so that's yet another point it is missing in your initial set of criteria. Its main implementation and library also emits rather large binaries in the usual case. You may not find this important, but others do.
  - Zababa 5y ago
    I addressed that point: > People will often choose Rust instead of Zig because Rust has stronger guarantees about memory safety, and these guarantees are more important for them than having a language that's small and fits in your head. For some people, having a language that's small and fits in your head is not a requirement, not a priority, and sometimes not even important.
  - nicoburns 5y ago
    As others have pointed out, neither is C if you take into account avoiding UB, the preprocessor, the build systems, the many stdlib functions you need to avoid, etc. You might already know how these work, but that doesn't mean there's less to learn than a language like Rust.

oddity 5y ago

Absolutely! A common example I like to use is Java. It might be hard to imagine now, but there was a time where Java (and then C#) were pitched as a replacements to C++ (even the name "C#" supposedly derived from "C++++"). There was no reason to write native code any more, many people said. And, they were kind of right. Many people were writing applications in C++ because they thought they had to, even though they weren't writing C++ in the style needed to make proper use of it. A lot of old C++ code bases today look like much more verbose Java applets. This peeling, when it happens, is usually good for everyone since languages (and tools) evolve to better fit the domains in which they are most used and happens so gradually that few notice. The inverse also happens, but with more conflict: you can see this today in Python (and other dynamic languages) adopting typing features aimed at assisting tooling for large code bases, well beyond the traditional learning or glue scripting mentality for which they were designed. This often results fierce debates around language features (like static typing vs dynamic typing) that are really proxy battles for the usage intent of the language. Unfortunately, I think the "replacing X language" mentality happens because it's the easiest point to start with. The field of programming and computers is so vast now that most (all?) people have a very narrow view and it's easy to assume it's universal. I've lost track of all the "things all programmers should read/know/do" articles.

Zababa 5y ago
> Unfortunately, I think the "replacing X language" mentality happens because it's the easiest point to start with. The field of programming and computers is so vast now that most (all?) people have a very narrow view and assume it's universal. I've lost track of all the "things all programmers should read/know/do" articles. I think another effect is that if you really like a language, promoting it is one of the best thing you can do to work with it. When you see the recent (2010 and later) new languages, they all have a story of addressing a particular pain point. Typescript is Javascript at scale, Kotlin is old Java on android, Go is web services, Rust is performance and safety. This is solid marketing, and is part of how these languages end up dominating their domains. On the other hand, a language that's "X but slighly better everywhere" won't really attract people, since there is already code and jobs in that language. Currently in the Great War Of Replacing C And C++, there are lots of fighters. Some people promote Rust, some others Go, some others D, some others Zig, some others to just keep writing C and C++. Part of the battle is writing code, libraries. Part of the battle is making the language and tooling itself better. And part of the battle is making articles, comments, talking to people and promote your language.

mypalmike 5y ago

I think there's an implicit, often unspoken list of C shortcomings wherever these replacement languages are concerned. Some of the most obvious ones are: Macro hell, transitive include hell, and the ease with which even experienced developers can unwittingly create unsafe code.

rightbyte 5y ago
> Macro hell I can hardly think of any language addon more innocent than Cpp (the preprocessor). Imagine what madness would have emerged if it had proper variable assignment, goto:s or any loop construct?
cassepipe 5y ago
Well Zig addresses all of those
- lerno 5y ago
  Well, except for Zig has the dubious distinction of actually having more UB than C.

oconnor663 5y ago

> Another is that it's small and fits in your head. I know this is a common view, but I want to highlight some counterexamples: - C programmers need to learn about many different forms of UB: https://blog.regehr.org/archives/1520 https://blog.regehr.org/archives/1520. Most take years to learn these rules. Many never learn them. - Most real world C programs use some nonstandard language extensions on some target platforms. C learners trying to read production code have to navigate these. - The C compilation and linking model is complicated and platform dependent. Compilation is a major stumbling block for students who have to learn Make or CMake at the same time they learn C. There is some truth to the "C is simple" idea, I'll grant that. It's obviously simpler than C++. But I think there's a big effect where we tend to forget how hard it was to learn, because we learned it so long ago. There's also been substantial progress since the 70's on designing simpler programming languages.

Zababa 5y ago
That's a good point. I personally don't share this view, and it's also not something I look for in a language. But people using C currently seem to be very attached to this, and knowing how to connect to your audiance is important.
surajs 5y ago
A reduced feature/keyword set does not a simple language make. C is smaller, but definitely not simpler. Also definition of simplicity is context dependent, I would say in many scenarios C++ turns out to be the simpler choice.
alfiedotwtf 5y ago
Thanks! This is probably the first time I've heard C called not a small language. Perl was my main language for over a decade, and when I wanted to go lower, I honestly struggled... but not with the language itself, with the peripherals which are exactly what you described!
- SAI_Peregrinus 5y ago
  C is small, but it's not simple or easy to get right.

0-_-0 5y ago

Nim compiles to C, so it can be a drop in replacement.

Zababa 5y ago
I think you should be a bit more precise on exactly when. If it compiles to C, that means that it inherits from C the great platform support. I don't know much about it, so I can't judge Nim on other qualities that people attribute to C: you can call it from pretty much any language, it's seen as simple, you can write highly performant code in it, you can use it in very restricted environments, and I'm probably forgetting some others.
- jasfi 5y ago
  It's also very easy to write Nim, the syntax has been compared to Python.
  - Zababa 5y ago
    Honestly, I don't think these kind of drive-by shallow comments are selling anyone on Nim. Many people here have posted long and insightful comments about the complexities of replacing C and some other topics, and two of the three comments about Nim are a bit shallow.
    - 0-_-0 5y ago
      I'm on my phone, otherwise I would have written more

auxym 5y ago

I think the fact that Nim compiles to C is neat in that you can use it on any platform that has a C compiler. Here is a recent project that uses nim for AVR platforms, for example: https://github.com/PMunch/badger https://github.com/PMunch/badger