[dead]
Thoughts on Go vs. Rust vs. Zig
191–200 of 599 posts
Re: Thoughts on Go vs. Rust vs. Zig
#192The reason I really like Zig is because there's finally a language that makes it easy to gracefully handle memory exhaustion at the application level. No more praying that your program isn't unceremoniously killed just for asking for more memory - all allocations are assumed fallible and failures must be handled explicitly. Stack space is not treated like magic - the compiler can reason about its maximum size by exam…
> Stack space is not treated like magic - the compiler can reason about its maximum size by examining the call graph, so you can pre-allocate stack space to ensure that stack overflows are guaranteed never to happen.
How does that work in the presence of recursion or calls through function pointers?
Re: Thoughts on Go vs. Rust vs. Zig
#193Earlier quoted context omitted.
I will never understand people bashing other languages for their syntax and readability and then saying that they prefer Rust. Async Rust is the ugliest and least readable language I've ever seen and I've done a lot of heavily templated C++
Concur, but non-async rust is a different matter!
Yeah, I like rust but I hate async. I wish it had never been added to the language, because it has so thoroughly infected the crate ecosystem when most programs just do not need async.
Re: Thoughts on Go vs. Rust vs. Zig
#194Earlier quoted context omitted.
yeah but which is faster and easier for a person to look at and understand. Go's intentionally verbose so that more complicated things are easier to understand.
let mut file = File::create("foo.txt").context("failed to create file")?; Of all the things I find hard to understand in Rust, this isn't one of them.
What's the "?" doing? Why doesn't it compile without it? It's there to shortcut using match and handling errors and using unwrap, which makes sense if you know Rust, but the verbosity of go is its strength, not a weakness. My belief is that it makes things easier to reason about outside of the trivial example here.
Re: Thoughts on Go vs. Rust vs. Zig
#195I really hate the anti-RAII sentiments and arguments. I remember the Zig community lead going off about RAII before and making claims like "linux would never do this" ( https://github.com/torvalds/linux/blob/master/include/linux/... ). There are bad cases of RAII APIs for sure, but it's not all bad. Andrew posted himself a while back about feeling bad for go devs who never get to debug by seeing 0xaa memory segments,…
Have you tried Swift? It has the sort of pragmatic-but-safe-by-default approach you’re talking about.
Not enough to say yes in earnest. I help maintain some swift at work, but I put my face in the code base quite rarely. I've not authored anything significant in the language myself. What I have seen is some code where there are multiple different event/mutex/thread models all jumbled up, and I was simultaneously glad to see that was possible in a potentially clean way alongside at least the macos/ios runtime, but the code in question was also a confused mess around it and had a number of fairly serious and real concurrency issues with UB and data races that had gone uncaught and seemingly therefore not pointed out by the compiler or tools. I'd be curious to see a SOTA project with reasonable complexity.
Re: Thoughts on Go vs. Rust vs. Zig
#196Earlier quoted context omitted.
I think it's common to be taught that UB is very bad when you're new, partly to simplify your debugging experience, partly to help you understand and mentally demarcate the boundaries of what the language allows and doesn't allow, and partly because there are many Standards-Purists who genuinely avoid UB. But from my own experience, UB just means "consult your compiler to see what it does here because this question i…
> But from my own experience, UB just means "consult your compiler to see what it does here because this question is beyond our pay grade." People are taught it’s very bad because otherwise they do exactly this, which is the problem. What does your compiler do here may change from invocation to invocation, due to seemingly unrelated flags, small perturbations in unrelated code, or many other things. This approach enc…
> Code that invokes UB is incorrect, full stop.
That's not true at all, who taught you that? Think of it like this, signed integer over/underflow is UB. All addition operations over ints are potentially invoking UB.
int add (int a, int b) { return a + b; }
Compilers explicitly provide you the means to disable optimizations in a granular way over undefined behavior precisely because a lot of useful behavior is undefined, but compilation units are sometimes too complex to reason about how the compiler will mangle it. -fno-strict-aliasing doesn't suddenly make pointer aliasing defined behavior.
We have compiler behavior for incorrect code, and it's refusing to compile the code in the first place. Do you think it just a quirky oversight that UB triggers a warning at most? The entire point of compilers having free reign over UB was so they could implement platform-specific optimizations in its place. UB isn't arbitrary.
Re: Thoughts on Go vs. Rust vs. Zig
#197Earlier quoted context omitted.
I understand, but you have to see how you would be considered one of the Standards-Purists that I was talking about, right? If Microsoft makes a guarantee in their documentation about some behavior of UB C code, and this guarantee is dated to about 14 years ago, and I see many credible people on the internet confirming that this behavior does happen and still happens, and these comments are scattered throughout those…
> If Microsoft makes a guarantee in their documentation about some behavior of UB C code But do they? Where? More likely, you mean that a particular compiler may say "while the standard says this is UB, it is not UB in this compiler". That's something wholly different, because you're no longer invoking UB.
Yes, that is still undefined behavior. Behavior being defined or not is a standards-level distinction, not a compiler one.
Re: Thoughts on Go vs. Rust vs. Zig
#198> I’m not the first person to pick on this particular Github comment, but it perfectly illustrates the conceptual density of Rust: But you only need about 5% of the concepts in that comment to be productive in Rust. I don't think I've ever needed to know about #[fundamental] in about 12 years or so of Rust… > In both Go and Rust, allocating an object on the heap is as easy as returning a pointer to a struct from a fu…
>> In Go and Rust and so many other languages, you tend to allocate little bits of memory at a time for each object in your object graph. Your program has thousands of little hidden malloc()s and free()s, and therefore thousands of different lifetimes.
> Rust can also do arena allocations, and there is an allocator concept in Rust, too. There's just a default allocator, too.
Thank you. I've seen this repeated so many times. Casey Muratori did a video on batch allocations that was extremely informative, but also stupidly gatekeepy [1]. I think a lot of people who want to see themselves as super devs have latched onto this point without even understanding it. They talk like RAII makes it impossible to batch anything.
Last year the Zig Software Foundation wrote about Asahi Lina's comments around Rust and basically implied she was unknowingly introducing these hidden allocations, citing this exact Casey Muratori video. And it was weird. A bunch of people pointed out the inaccuracies in the post, including Lina [2]. That combined with Andrew saying Go is for people without taste (not that I like Go myself), I'm not digging Zig's vibe of dunking on other companies and languages to sell their own.
[1] https://www.youtube.com/watch?v=xt1KNDmOYqA [2] https://lobste.rs/s/hxerht/raii_rust_linux_drama
Re: Thoughts on Go vs. Rust vs. Zig
#199I really hate the anti-RAII sentiments and arguments. I remember the Zig community lead going off about RAII before and making claims like "linux would never do this" ( https://github.com/torvalds/linux/blob/master/include/linux/... ). There are bad cases of RAII APIs for sure, but it's not all bad. Andrew posted himself a while back about feeling bad for go devs who never get to debug by seeing 0xaa memory segments,…
> So RAII isn't the big evil monster, and we need to stop talking about RAII, globals, etc, in these ways. I disagree and place RAII as the dividing line on programming language complexity and is THE "Big Evil Monster(tm)". Once your compiled language gains RAII, a cascading and interlocking set of language features now need to accrete around it to make it ... not excruciatingly painful. This practically defines the…
Can you give some examples of " ... not excruciatingly painful" and why you think they're inherent to RAII?
Re: Thoughts on Go vs. Rust vs. Zig
#200Earlier quoted context omitted.
Sure, but you can do the next best thing, which is to control precisely when and where those allocations occur. Even if the possibility of crashing is unavoidable, there is still huge operational benefit in making it predictable. Simplest example is to allocate and pin all your resources on startup. If it crashes, it does so immediately and with a clear error message, so the solution is as straightforward as "pass bi…
No, this is still misunderstanding. Overcommit means that the act of memory allocation will not report failure, even when the system is out of memory. Instead, failure will come at an arbitrary point later, when the program actually attempts to use the aforementioned memory that the system falsely claimed had been allocated. Allocating all at once on startup doesn't help, because the program can still fail later when…
Which is why I said "allocate and pin". POSIX systems have mlock()/mlockall() to prefault allocated memory and prevent it from being paged out.