Live data from Hacker News

Assorted Thoughts on Zig and Rust

scattered-thoughts.net

201–210 of 307 posts

Re: Assorted Thoughts on Zig and Rust

#201

Earlier quoted context omitted.

If takes twice time to write? Of course, I too believe statically verifying is important for mission critical software. But it comes with a cognitive overhead.

It takes some time to get up to speed with Rust, but I don't think it takes particularly longer to write a correct program in Rust than it does in other languages. I often find myself reaching for Rust rather than Python now, even for small things.

The same is true for C++, and early reaction was similar: hey, we don't need high-level languages anymore! But after a few decades with C++ we've found that the burden manifests not when writing the program but when maintaining a large codebase over many years in a team whose members change over time.

Re: Assorted Thoughts on Zig and Rust

#202
post #177
post #70

Earlier quoted context omitted.

My impression was completely the opposite. I was very excited about Rust at first, especially the ownership system, but after a while I saw that it was a cleaned-up C++ with most of C++'s problems (one of the most complex programming languages in software history; very slow feedback loop). Zig, on the other hand, seems revolutionary and a complete rethinking, from the ground-up, of what low-level programming should b…

I really don't see how Rust has most of C++'s problems. Slow compiler, sure, though things are changing. Most complex languages in history? Only if you squint at it from 10000 feet and ignore what the complexity is doing. C++ has approximately eighteen different partially-overlapping categories of variable initialization, many of which are legacy-but-still-used! [0] And some of those categories have changed their bou…

> There is even undefined behavior if you mess up namespacing! (Undiagnosed ODR violations are every experienced C++ programmer's nightmare.)

so, uh, how does Rust define behaviour if you export a same-name symbol from two rust dlls and load it from some executable ?

Re: Assorted Thoughts on Zig and Rust

#203

I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.

It's almost just C without the warts; I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code. The dependency on LLVM rules out a lot of embedded use cases, because some chipsets require forks of LLVM, or worse, proprietary C compilers or forks of GCC or something else, to run. Would be nice to have a language that just works everywhere.

Re: Assorted Thoughts on Zig and Rust

#204
post #194

Very interesting set of observations. As a C and C++ programmer, I am feeling more and more excited about Zig. One thing that feels missing from Zig though is encapsulation. I don't believe that you can declare struct fields private, such that they can only be accessed by methods. This seems really important to me, not only as a technical means of enforcing invariants, or hiding internal-only implementation details t…

If you want to communicate intent, put an underscore in the field name, like it's being done in Python. `field` is "you are invited to read/write this directly", `_field` is "please don't read/write this."

As Raymond Hettinger once remarked, Python is a language for consenting adults.

Re: Assorted Thoughts on Zig and Rust

#205
post #196
post #89

Earlier quoted context omitted.

Those are nice taglines, but while Rust is a safer C++ in the sense that it is a language that espouses C++'s design philosophy and has a similar feel to it, Zig is something new altogether. The only thing that makes it more similar to C than to C++ is that C is an extremely simple language, as is Zig, while C++ is an extremely complex language. But other than that, Zig is a low-level language that is its own family,…

> in the sense that it is a language that espouses C++'s design philosophy Could you elaborate on this?

They're low-level languages -- with all the attention to low-level detail all low-level languages require -- that aim to appear like high-level code on the page. All the same details are still there, and you must confront them when changing the code, but they don't appear as text when you look at the code.

Re: Assorted Thoughts on Zig and Rust

#206
post #197
post #177

Earlier quoted context omitted.

I really don't see how Rust has most of C++'s problems. Slow compiler, sure, though things are changing. Most complex languages in history? Only if you squint at it from 10000 feet and ignore what the complexity is doing. C++ has approximately eighteen different partially-overlapping categories of variable initialization, many of which are legacy-but-still-used! [0] And some of those categories have changed their bou…

You're comparing 35-year-old C++ with 10-year-old Rust (and that doesn't even capture the story, because after two years C++ had something like 5x the market penetration Rust has after ten). But even now Rust, I think, together with C++, Ada, and Scala, easily ranks among the top five or so most complex programming languages in software history. It's definitely a matter of personal taste, but to me , Rust seems a mon…

Four of the five pieces of accidental complexity I listed were present in C++98, so I'm not sure what the relative ages have to do with this. (You've also not mentioned any accidental complexity in Rust...) Instead, I attribute it to hindsight and differences in priorities- C++ today is still introducing new features with the same level of unforced complexity (e.g. compare C++ lambda capture clauses and coroutines, to Rust closures and async fn), while additions to Rust instead tend to "fill in" inconsistencies to remove edge cases and exceptions.

I'm also not trying to convince you to drop Zig and settle for Rust! You can use either or both or neither, I don't mind! Rather, my point is that Rust's direction relative to C++ is the same one you praise Zig for- it provides the same control with drastically more economical application of fewer language features. Just because Zig goes further (again, at great cost to things like tooling, error checking, and messages) doesn't mean Rust didn't make a lot of progress.

Re: Assorted Thoughts on Zig and Rust

#207
post #177

Earlier quoted context omitted.

I really don't see how Rust has most of C++'s problems. Slow compiler, sure, though things are changing. Most complex languages in history? Only if you squint at it from 10000 feet and ignore what the complexity is doing. C++ has approximately eighteen different partially-overlapping categories of variable initialization, many of which are legacy-but-still-used! [0] And some of those categories have changed their bou…

> There is even undefined behavior if you mess up namespacing! (Undiagnosed ODR violations are every experienced C++ programmer's nightmare.) so, uh, how does Rust define behaviour if you export a same-name symbol from two rust dlls and load it from some executable ?

It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library.

The only way to get matching names is to ask for them explicitly, via FFI.

Re: Assorted Thoughts on Zig and Rust

#208

I think Zig's biggest advantage is that it's just C without the warts, or footguns as is said in the Zig world. The comptime feature is probably the most exciting thing I've seen in a while. I've looked at Rust and feel it's more of a competitor to C++, Java and C#. Whereas Zig is C done right.

It's almost just C without the warts; I wish someone would make a language that was both as good as Zig or Rust, and could be compiled to C code. The dependency on LLVM rules out a lot of embedded use cases, because some chipsets require forks of LLVM, or worse, proprietary C compilers or forks of GCC or something else, to run. Would be nice to have a language that just works everywhere.

I feel like the onus should be on chip makers to write LLVM backends because proprietary C compilers and GCC forks almost universally suck. I understand why they don't, but it's just disappointing on both ends of the pipeline. That said, ARM is great, and you can target most ARM chips with LLVM.

There's also the downside that transpiling to C locks you into an ABI, which limits what compiler developers can do towards the end of the compilation passes.

Re: Assorted Thoughts on Zig and Rust

#209
post #206
post #197

Earlier quoted context omitted.

You're comparing 35-year-old C++ with 10-year-old Rust (and that doesn't even capture the story, because after two years C++ had something like 5x the market penetration Rust has after ten). But even now Rust, I think, together with C++, Ada, and Scala, easily ranks among the top five or so most complex programming languages in software history. It's definitely a matter of personal taste, but to me , Rust seems a mon…

Four of the five pieces of accidental complexity I listed were present in C++98, so I'm not sure what the relative ages have to do with this. (You've also not mentioned any accidental complexity in Rust...) Instead, I attribute it to hindsight and differences in priorities- C++ today is still introducing new features with the same level of unforced complexity (e.g. compare C++ lambda capture clauses and coroutines, t…

Sorry, I don't see it that way (and I don't entirely agree with your characterisation of what new Rust changes do, certainly not all of them). I think that both Rust and C++ are fundamentally built around a design concept that I find distasteful and wrong-headed for low-level programming -- https://news.ycombinator.com/item?id=24840818; I guess you can call it too much implicitness aimed to make the language appear something it isn't when printed on the page. Rust does it somewhat more elegantly than C++ and perhaps has other justifications for it (like sound guarantees) -- which is why I prefer it to C++, although not enough to justify a large investment until it has a significant market share -- but it espouses the same foundational design aesthetics. I think that whether people like or dislike Rust mostly has to do with whether they find that aesthetic appealing. I'm sure many people do and many people don't.

BTW, I haven't "adopted" Zig that I would need to drop it for anything (it's not even 1.0 yet). I'm still with C++ for the time being. But I'm deeply impressed by Zig's revolutionary design and complete rethinking of low-level programming that I'm keeping a watchful and hopeful eye on it.

Re: Assorted Thoughts on Zig and Rust

#210
post #132

Earlier quoted context omitted.

I've been enjoying D as "C done right". I find it a pleasure to use.

D is much more "C++ done right" (and then some). C and Zig are very barebones, close-to-the-metal language. D has garbage collection, classes, templates, exceptions, built-in dynamic arrays and hash tables, and on and on and on. The "Features Overview" page makes me go cross-eyed [1]. Yes, you can turn many of these things off or ignore them and just use D as a better C, but the same could be said of C++ (for some de…

But native code is native code, there isn't a magical layer underneath that would make Zig closer to the metal than D, unless perhaps the voluntary Undefined Behaviour zig is willing to take such as those for loops.
Post reply on HN