5 ms·

Language-level guarantees of memory safety are not critical to all low-level programmers, and sometimes this is fine! Developers of games, compilers, digital a

Language-level guarantees of memory safety are not critical to all low-level programmers, and sometimes this is fine! Developers of games, compilers, digital audio workstations, video editors, and live performance software (such as openFrameworks) likely don't rank memory safety as their top concern. Zig is already an attractive choice for those domains because it offers: - Great compile times compared to C++/Rust, and future plans to implement hot reloading as a core part of the tooling: https://www.jakubkonka.com/2022/03/16/hcs-zig.html https://www.jakubkonka.com/2022/03/16/hcs-zig.html - The ability to reason about where data exists in memory: https://ziglang.org/documentation/master/#Where-are-the-bytes https://ziglang.org/documentation/master/#Where-are-the-byte... - Good readability and learnability, especially if you have a C/C++ background. - Comptime that enables clean generics, compile-time reflection and general metaprogramming as a happy side-effect: https://kristoff.it/blog/what-is-zig-comptime/ https://kristoff.it/blog/what-is-zig-comptime/ - Better tooling than C/C++. The ability to cross-compile Zig and C/C++ from one machine lets you set up much more stable and reproducible build environments already. You can clone zig-gamedev and have the demos working with just three commands on Windows/macOS/Linux, for example, and two of those three are cloning the repo and changing to the directory: https://github.com/michal-z/zig-gamedev https://github.com/michal-z/zig-gamedev (to build the examples you will need the latest copy of Zig from the 'master' section for your platform at https://ziglang.org/download/ https://ziglang.org/download/ ) We should all be careful about insinuating that memory unsafe languages should not exist. I see “friends don't let friends use memory-unsafe languages” on social media and feel sick. It's much healthier to embrace the melting pot of Zig, Odin, D, Beef, Vale, Hare, V, Lobster, Jai, C3, Val, Roc and all the rest and see what new ideas and trade-offs they bring. Also worth noting that new languages tend to take time to develop their own philosophies to memory safety (Vale's approach is only just now emerging, for example: https://verdagon.dev/blog/making-regions-part-1-human-factor https://verdagon.dev/blog/making-regions-part-1-human-factor ). Others take years to gradually improve and develop techniques for better memory safety (like D). Zig's story might not be as good as Rust's ( https://www.scattered-thoughts.net/writing/how-safe-is-zig/ https://www.scattered-thoughts.net/writing/how-safe-is-zig/ ), but then it's not Zig's priority at the moment, and Zig's full story is not yet written. Even if Zig's safety features don't improve further between now and 1.0, it already has great value as a language.

KerrAvon 4y ago
I think you're misunderstanding the value proposition of languages like Rust and Swift. It's not that they help safeguard user data or statistically reduce crash logs in analytics, although those are certainly useful properties in every domain you've named; I will stipulate for the purpose of this reply that developers in those domains don't value their users at all, although I don't believe it to be true. The value proposition is that they eliminate entire classes of low-level bugs. Certain problems that you'd otherwise spent weeks debugging during a large project just don't happen. You can spend your time on the actual logic of your task rather than debugging all of the boilerplate around it. Developers of games, compilers, DAWs, NLEs and live performance software absolutely care about productivity.
- verdagon 4y ago
  They do eliminate certain classes of low-level bugs, but we shouldn't always ignore the tradeoffs that can come with memory safety. GC and RC have a performance tradeoff, and borrow checking has complexity and developer velocity tradeoffs (and yes, I know there are some people who say they are immune to this effect). For this reason it's important that we keep exploring alternative approaches and languages such as Zig, even if they don't have the level of memory safety one might personally deem appropriate for a certain domain. Vale is even more memory safe than Rust, yet I don't go around saying Rust shouldn't exist ;)
- modernerd 4y ago
  I write Rust and enjoy spending less time on memory bugs. I am not blind to the benefits. But I’d struggle to match your claim along the lines of, “games and DAW developers would be more productive with a memory-safe language because they wouldn’t have to debug memory safety bugs”. Memory safety in Rust might be “zero-cost” but it isn’t free. Languages like Zig accept that developers spend time on things outside of memory bugs, seek to improve their productivity and quality of life in those areas, and trust that devs will pick tools that reduce their largest pain points, be that Zig or Rust or Odin. The best response we as an industry can have to this is to say, “wow, I’m glad so many hard-working people feel motivated to bring some of those bars down on the Ways Software Sucks Chart, let’s give them our money and our support!” To me that’s healthier than assuming that everyone’s Suck Chart looks the same, tapping the memory safety bar over on the right and saying, “sheesh, anyone using a language that doesn’t fix this bar just doesn’t realise how productive they could be!”. It also detracts from celebrating the engineering achievement here. Two people deleted their creaking C++ compiler by writing a custom interpreter in two weeks so their language can be bootstrapped using only system-installed tools. It is uncharitable to insinuate that they needn’t have bothered because if you really care about productivity you wouldn’t use languages like their one anyway.

KerrAvon 4y ago

I think you're misunderstanding the value proposition of languages like Rust and Swift. It's not that they help safeguard user data or statistically reduce crash logs in analytics, although those are certainly useful properties in every domain you've named; I will stipulate for the purpose of this reply that developers in those domains don't value their users at all, although I don't believe it to be true. The value proposition is that they eliminate entire classes of low-level bugs. Certain problems that you'd otherwise spent weeks debugging during a large project just don't happen. You can spend your time on the actual logic of your task rather than debugging all of the boilerplate around it. Developers of games, compilers, DAWs, NLEs and live performance software absolutely care about productivity.

verdagon 4y ago
They do eliminate certain classes of low-level bugs, but we shouldn't always ignore the tradeoffs that can come with memory safety. GC and RC have a performance tradeoff, and borrow checking has complexity and developer velocity tradeoffs (and yes, I know there are some people who say they are immune to this effect). For this reason it's important that we keep exploring alternative approaches and languages such as Zig, even if they don't have the level of memory safety one might personally deem appropriate for a certain domain. Vale is even more memory safe than Rust, yet I don't go around saying Rust shouldn't exist ;)
modernerd 4y ago
I write Rust and enjoy spending less time on memory bugs. I am not blind to the benefits. But I’d struggle to match your claim along the lines of, “games and DAW developers would be more productive with a memory-safe language because they wouldn’t have to debug memory safety bugs”. Memory safety in Rust might be “zero-cost” but it isn’t free. Languages like Zig accept that developers spend time on things outside of memory bugs, seek to improve their productivity and quality of life in those areas, and trust that devs will pick tools that reduce their largest pain points, be that Zig or Rust or Odin. The best response we as an industry can have to this is to say, “wow, I’m glad so many hard-working people feel motivated to bring some of those bars down on the Ways Software Sucks Chart, let’s give them our money and our support!” To me that’s healthier than assuming that everyone’s Suck Chart looks the same, tapping the memory safety bar over on the right and saying, “sheesh, anyone using a language that doesn’t fix this bar just doesn’t realise how productive they could be!”. It also detracts from celebrating the engineering achievement here. Two people deleted their creaking C++ compiler by writing a custom interpreter in two weeks so their language can be bootstrapped using only system-installed tools. It is uncharitable to insinuate that they needn’t have bothered because if you really care about productivity you wouldn’t use languages like their one anyway.