6 ms·
> THE language to replace C. One thing I think people keep getting hung up on is this idea of there being a pure replacement for C. Consider the fact that C ha
by bluejekyll 5y ago
> THE language to replace C.
One thing I think people keep getting hung up on is this idea of there being a pure replacement for C. Consider the fact that C has already been displaced in many areas. Consider C++ as the first big one, it didn’t add memory safety over C, but for many it was more ergonomic and easier to reuse code across different systems (the STL is a big advancement here). That took a huge number of users away from C. Then you have Java that added memory safety and that pulled away even more folks.
What’s been left is a particular niche for C that is being being targeted by new features in C++, Rust, and possibly Zig.
The question really becomes what niches will each of these languages carve out from the existing C usage? Why would users adopt one over the other? There’s plenty of space for all of these languages to thrive, what I don’t think we’ll ever see is “the one true C replacement”, first because C itself will continue for a long time, but also because each of the existing C replacement languages are already are doing well. Will Zig capture the last C uses? I doubt it, but that’s nothing against Zig, it’s just the plain truth about how the computing world works. See the continued devotion to FORTRAN as an example.
- jolux 5y agoI respect the hell out of Andrew and what he’s accomplished with Zig, but to an extent I think it’s counterproductive to be creating new languages that aren’t memory safe. What niche does Zig fit? As far as I can tell, it seems to be people who find Rust cumbersome, and don’t think it’s worth the benefits in memory safety. I don’t personally understand why I would choose Zig over Rust. I think it’s long past time we closed the book on unsafe languages as a profession.
- ifreund 5y agoThis comment is a perfect example of what Andrew was talking about here: > Andrew: It’s funny how it just kind of changes course as the language gets taken more and more seriously. And now, all the comments are even starting to shift to kind of like the philosophy of memory safety and whether Zig is immoral. I'd suggest you go listen to the podcast or at least read the "Zig Is Immoral and Unsafe" section of the transcript as well as the following one.
- jolux 5y agoWell, I feel pretty strongly about this issue as someone who cares about security. It is a question of ethics to me. I mean, saying Rust is unsafe because it has the unsafe block is like saying Haskell isn’t a pure language because it has IO. Yes, but it totally misses the point. The language is designed to minimize and constrain usage of unsafe features. And, outside of unsafe blocks, you know your code is safe. This is an important guarantee.
- flumpcakes 5y ago> outside of unsafe blocks, you know your code is safe Only for some common memory mistakes. And ony if the compiler doesn't have a bug. This sounds like a nitpic, but let's be clear that Rust is not "safe" as if it was some global quality that covered all of the language.
- jolux 5y ago> Only for some common memory mistakes. Yes, I’m talking about memory safety, because memory bugs cause most vulnerabilities.
- bsg75 5y agoMorality and ethics seem odd to apply if a programming language should be developed, which seems to be the context Andrew was mentioning. Some use cases might apply (ex. medical devices). I wonder if this type of debate came up when C++ was introduced amongst C developers.
- nicetryguy 5y ago> Rust is "Safe" I'm tired of this meme. It's not true. Any Rust code that goes low level liberally uses unsafe{} blocks. There are also debugging and test modes in Zig that will sniff out leaks for you.
- bluejekyll 5y ago> Any Rust code that goes low level liberally uses unsafe{} blocks This isn't an accurate statement. Liberal use of unsafe is not common or best practice in Rust. My favorite educational series that shows how little unsafe is required to work in low-level spaces is Phil Opperman's, "Writing an OS in Rust": https://os.phil-opp.com/ https://os.phil-opp.com/ That being said, I don't think most people use "Rust is safe" in an particular way that's different from saying Java is safe. Rust in many ways offers similar (and stronger) safety guarantees than Java (one of the safest langauges to date). Is Java safe? We all know that bugs can be created in every language, it's really the different classes of bugs that each language offers some defense against that sets them apart from each other.
- AnIdiotOnTheNet 5y agoI think Andrew would contend that it is memory safe, it just defines that safety in a different way than Rust: > [...] So, the way I would describe it is that Rust has a kind of like vertical memory safety approach where on the top, it’s safe. And then, on the bottom, you hit the unsafe block, and it’s not safe, right? [...] Zig is more of I would say horizontal safety approach. So, there’s no unsafe blocks where it’s all contained in, but each feature of the language models safety in a different way. So, as an example, the pointer type in Zig actually can represent alignment. In Rust, if you want to mess with pointer alignment, you have to use an unsafe block and you’ve turned off safety for alignment. In Zig, you have pointer alignment in the type. So, it’s actually completely safe, and in Rust it’s not. And of course the reason it doesn't use anything like a borrow checker: > [...] Zig also wants to be optimal and optimal means you want to fully use the hardware that you have. So, my hardware lets me use virtual memory and it lets me use intrusive data structures. And it lets me write code in a certain way that’s the most efficient way to use all the CPU and all the memory. So, if my language doesn’t let me use all my hardware features, it’s not optimal. I can't help but agree. We should strive to allow optimal code to work, and we should also do our best to prevent the programmer from doing unsafe things unless they are explicit about what they're doing. Are programmers sometimes going to do the wrong thing anyway? Yes, of course. The same way that someone can get frustrated and wrap their code in unsafe, they can use @ptrToInt without thinking it through.
- TimSchumann 5y agoIn my (admittedly) very limited usage/understanding of Zig, this is a fairly accurate description of where the memory safety comes from.
- ksec 5y agoI think the horizontal vs vertical memory safety argument needs to be better marketed. Because right now Memory safety PL is quite literally trademarked by Rust in any discussions.
- dwohnitmok 5y agoI don't find the horizontal vs vertical nomenclature very helpful. The chart here spelled it out for me very clearly. https://scattered-thoughts.net/writing/how-safe-is-zig/ https://scattered-thoughts.net/writing/how-safe-is-zig/
- blacktriangle 5y agoThere's two things going on here. 1) We need to move to safer languages 2) Rust is the way, the truth, and the light of safe languages even though its brand new and barely tested out in production. The first is a defensible position, the second is why people can have a reflexively negative reaction to anybody pushing Rust.
- steveklabnik 5y ago> even though its brand new and barely tested out in production What would get you to change your mind on this? Like, Rust has been heavily tested in serious production for years at this point. 1.0 was six years ago. Where is the bar? How much usage counts? What is no longer "brand new"?
- blacktriangle 5y ago1) More time. Rust is what, 6ish years old now? And in those years its continued to evovle and grow. 2) More software. Particularly older software, watching Rust code bases evolve over time. 3) Most topical to this thread, watching how other approaches to safer programming shake out. Its hard to have confidence in a solution to a generic problem when you can only evaluate a single solution. For example I find Zig to be a potentially much better solution since it has a far smaller surface area. Somebody on HN said: Rust is what you get when C++ programmers try and fix memory safety, Zig is what you get when a C programmer tries to do it, and based on the Rust and Zig code I've seen this really rings true. Rust is on a great track, but it seems way way too early to declare victory and start claiming that everybody exploring the same safe programming space is functioning as an unethical professional. EDIT: As an aside I enjoyed your blog post on learning Ada, stream of consciousness and all. You ask what the bar is, the bar is Ada. Decades in the market, formal standard, multiple implementations. I wish somebody would dig into why we need Rust, Zig, or something else when Ada exists. Is it just because Ada syntax is unfamilar to todays programmers or is there something fundamentally unsound about Ada?
- steveklabnik 5y agoAll of this is still relative, what is "more"? is it four more years? Ten more years? Twenty? How much software is "more" software? I always find that C++ vs C comparison to be amusing, given I work with a bunch of C folks who don't like C++ but love Rust... not everyone likes languages for the same reasons. There's a grain of truth in sayings like this, but it's not the whole picture. (I am also not saying Rust is the only thing, or that Rust should "win" over Zig, whatever that means, or anything more broadly. My comment is purely about how Rust is too "new" and "untested", in a vacuum.) Thanks for the comment about the blog post. It was a fun one to write.
- noch 5y ago> I don’t personally understand why I would choose Zig over Rust. I think it’s long past time we closed the book on unsafe languages as a profession. You might be interested in looking at the CVE list for Rust programs before you conclude that safety (programming as a safe space?) is the highest principle we should aspire to. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Rust http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=Rust From a first principles basis: Time will probably reveal that languages that give us accurate insights into what the hardware is doing, and thus give us better control of hardware, will yield higher programmer productivity and software quality, in the long run.
- krupan 5y agoWhy aren't you using Ada then? Serious question. Those of us that have been around a while notice all this safety rhetoric around rust and immediately think of Ada.
- touisteur 5y agoAda is missing the borrowing/moving guarantees. Whenever I use dynamically allocated memory, I have to do manual memory management, with the 'unsafe' (it's called 'unchecked' deallocation for a reason) coming in then, and also even without dynamic allocation, the myriad problems coming with aliasing (pointers / 'access types'). You can handle the first one with scoped allocation ('controlled types') and the second one by 'being careful with pointers'... With the borrow checker those two kinds of problems mostly evaporate, or at least are statically handled by a harsh compiler. There's been some great progress (mostly from the amazing Claire Dross iirc) bringing ownership concepts to SPARK and I really hope the Ada community can focus on those concepts for a serious, ambitious next revision, a bit more dense than all the sugar we've seen for now. Ada has lots of safety features, and to be honest, in real-time embedded software, dynamic allocation/deallocation is a big no-no, and aliasing/pointers tend to be avoided whenever one can. I sure rant a lot at review when I see some new code with pointers instead of copying, if performance is not an issue.