It's obvious that Rust is the best.
Thoughts on Go vs. Rust vs. Zig
401–410 of 599 posts
Re: Thoughts on Go vs. Rust vs. Zig
#402> Many people seem confused about why Zig should exist if Rust does already. It’s not just that Zig is trying to be simpler. I think this difference is the more important one. Zig wants you to excise even more object-oriented thinking from your code. I feel like Zig is for the C / C++ developers that really dislike Rust. There have been other efforts like Carbon, but this is the first that really modernizes the langu…
> I feel like Zig is for the C / C++ developers that really dislike Rust. Also my feeling. Writing this as a former C++ developer who really likes Rust :)
C++ developers are monstruosities
Re: Thoughts on Go vs. Rust vs. Zig
#403For a lot of stuff what I really want is golang but with better generics and result/error/enum handling like rust.
I thought the recent error proposal was quite interesting even if it didn't go through: https://github.com/golang/go/issues/71528 My hope is they will see these repeated pain points and find something that fits the error/result/enum issues people have. (Generics will be harder, I think)
I was a big fan of the original check handle proposal: https://go.googlesource.com/proposal/+/master/design/go2draf...
I see the desire to avoid mucking with control flow so much but something about check/handle just seemed so elegant to me in semi-complex error flows. I might be the only one who would have preferred that over accepting generics.
I can't remember at this point because there were so many similar proposals but I think there was a further iteration of check/handle that I liked better possibly but i'm obviously not invested anymore.
Re: Thoughts on Go vs. Rust vs. Zig
#404Earlier quoted context omitted.
Are you familiar with Zig's error handling? It's arguably more Go-like than the Rust approach.
No, Zig's error handling is decent - you either return an error or a value and you have some syntactic sugar to handle it. It's pretty cool, especially given the language's low-level domain. Meanwhile Go's is just multiple value-returns with no checks whatsoever and you can return both a valid value and an error.
But sometimes it is useful to return both a value and a non-nil error. There might be partial results that you can still do things with despite hitting an error. Or the result value might be information that is useful with or without an error (like how Go's ubiquitous io.Writer interface returns the number of bytes written along with any error encountered).
I appreciate that Go tends to avoid making limiting assumptions about what I might want to do with it (such as assuming I don't want to return a value whenever I return a non-nil error). I like that Go has simple, flexible primitives that I can assemble how I want.
Re: Thoughts on Go vs. Rust vs. Zig
#405The 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…
I don't know Zig. The article says "Many people seem confused about why Zig should exist if Rust does already." But I'd ask instead why does Zig exist when C does already? It's just a "better" C? But has the drawback that makes C problematic for development, manual memory management? I think you are better off using a language with a garbage collector, unless your usage really needs manual management, and then you ca…
I think the whole idea is to remove some pain points of C while not introducing additional annoyances people writing low level code don't want.
Re: Thoughts on Go vs. Rust vs. Zig
#406Earlier quoted context omitted.
I imagine people who care about this sort of thing are happy to disable overcommit, and/or run Zig on embedded or specialized systems where it doesn't exist.
There are far more people running/writing Zig on/for systems with overcommit than not. Most of the hype around Zig come from people not in the embedded world.
> Most of the hype around Zig come from people not in the embedded world.
Yet another similarity with Rust.
Re: Thoughts on Go vs. Rust vs. Zig
#407So easy to get stuck doing nothing but contemplate what language you should use for your next project.
Re: Thoughts on Go vs. Rust vs. Zig
#408Earlier quoted context omitted.
Every language i am not deeply familiar with is disgusting. But for real the ratings for me stem from how much arcane symbology i must newly memorize. I found rust to be up there but digestible. The thought of c++ makes me want to puke but not over the syntax.
template concept non_zero = (V != 0); template concept arithmetic = std::is_arithmetic_v ; template requires non_zero struct complicated { template using nested_alias = std::tuple ..., std::conditional_t 0 && ...), T, std::nullptr_t> >; template static constexpr auto process() { return [] (std::index_sequence ) { return nested_alias {}; }(std::make_index_sequence {}); } }; I most definitely agree.
The difference is that nobody really writes application code like that, it's a tool for writing libraries and creating abstractions. If all of the ugliness of async Rust was contained inside Tokio, I would have zero problems with it, but it just infects everything it touches
Re: Thoughts on Go vs. Rust vs. Zig
#409Earlier quoted context omitted.
Lately rust is my primary language, and I couldn't agree more with this. I've taken to using typescript for prototyping - since its fast (enough), and its trivial to run both on the server (via bun) or in a browser. The type system is similar enough to rust that swapping back and forth is pretty easy. And there's a great package ecosystem. I'll get something working, iterate on the design, maybe go through a few rewr…
I'm in a similar place, but my stack is Python->Go With Python I can easily iterate on solutions, observe them as they change, use the REPL to debug things and in general just write bad code just to get it working. I do try to add type annotations etc and not go full "yolo Javascript everything is an object" -style :) But in the end running Python code on someone else's computer is a pain in the ass, so when I'm done…
Is there a good resource on how to get better at python prototyping?
The typing system makes it somewhat slow for me and I am faster prototyping in Go then in Python, despite that I am writing more Python code. And yes I use type annotations everywhere, ideally even using pydantic.
I tend to use it a lot for data analytics and exploration but I do this now in nushell which holds up very well for this kind of tasks.
Re: Thoughts on Go vs. Rust vs. Zig
#410Earlier quoted context omitted.
> languages where "trivial" things "just require" rapidly become "not so trivial" in the aggregate Sure. And in C and Zig, it's "trivial" to make a global mutable variable, it "just requires" you to flawlessly uphold memory access invariants manually across all possible concurrent states of your program. Stop beating around the bush. Rust is just easier than nearly any other language for writing concurrent programs,…
This is a miscommunication between the values of “shipping” which optimizes for fastest time to delivery and “correctness” which optimizes for the quality of the code. Rust makes it easy to write correct software quickly, but it’s slower for writing incorrect software that still works for an MVP. You can get away with writing incorrect concurrent programs in other languages… for a while. And sometimes that’s what bus…
> Rust makes it easy to write correct software quickly, but it’s slower for writing incorrect software that still works for an MVP
YMMV on that, but IMHO the bigger part of that is the ecosystem , especially for back-end. And by that metric, you should never use anything else than JS for prototyping.
Go will also be faster than Rust to prototype backend stuff with because most of what you need is in the standard library. But not by a large margin and you'll lose that benefit by the time you get to production.
I think most people vastly overestimate the friction added by the borrow checker once you get up to speed.