Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thoughts on Go vs. Rust vs. Zig

sinclairtarget.com

Post reply on HN
Print view View original

251–260 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#251

Post by seanmcdirmid »

Mawr wrote: post #249
deathanatos wrote: post #162

> 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…

> Rust can also do arena allocations, Is there a language that can't? The author isn't saying it's literally impossible to batch allocate, just that the default happy path of programming in Rust & Go tends to produce a lot of allocations. It's a take more nuanced than the binary possible vs impossible .

Pretty hard to do arena allocation in Java without JVM primitive support.

Re: Thoughts on Go vs. Rust vs. Zig

#252

Post by bluGill »

the_duke wrote: post #189
kibwen wrote: post #177

Earlier quoted context omitted.

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…

To be fair, you can enforce this just by filling all the allocated memory with zero, so it's possible to fail at startup. Or, even simpler, just turn off over-commit. But if swap comes into the mix, or just if the OS decides it needs the memory later for something critical, you can still get killed.

I would be suprised if some os detects the page of zeros and removes that allocation until you need it. this seems like a common enough case as to make it worth it when memory is low. I'm not aware of any that do, but it wouldn't be that hard and so seems like someone would try it.

Re: Thoughts on Go vs. Rust vs. Zig

#253

Post by bluGill »

kibwen wrote: post #182
xyzzy_plugh wrote: post #169

Earlier quoted context omitted.

If we can produce a substantial volume of software that can cope with allocation failures then the idea of using something than overcommit as the default becomes feasible. It's not a stretch to imagine that a different namespace might want different semantics e.g. to allow a container to opt out of overcommit. It is hard to justify the effort required to enable this unless it'll be useful for more than a tiny handful…

> If we can produce a substantial volume of software that can cope with allocation failures then the idea of using something than overcommit as the default becomes feasible. Except this won't happen, because "cope with allocation failure" is not something that 99.9% of programs could even hope to do. Let's say that you're writing a program that allocates. You allocate, and check the result. It's a failure. What do yo…

Even when I have a cache - it is probably in a different code path / module and it would be a terrible architecture that let me access that code.

Re: Thoughts on Go vs. Rust vs. Zig

#254

Post by tptacek »

nu11ptr wrote: post #237
tptacek wrote: post #212

Earlier quoted context omitted.

I'm pretty familiar with the idiom here and I don't find error/result mapping fluent-style patterns all that easy to read or write. My experience is basically that you sort of come to understand "this goo at the end of the expression is just coercing the return value into whatever alternate goo the function signature dictates it needs", which is not at all the same thing as careful error handling. Again: I think Rust…

> you sort of come to understand "this goo at the end of the expression is just coercing the return value into whatever alternate goo the function signature dictates it needs", which is not at all the same thing as careful error handling. I think the problem is Rust does a great job at providing the basic mechanics of errors, but then stops a bit short. First, I didn't realize until relatively recently that any `Stri…

Right, for error handling, I'd rather have Rust's bones to build on than Go's. I prefer Go to Rust --- I would use Go in preference to Rust basically any time I could get away with it (acknowledging that I could not get away with it if I was building a browser or an LKM). But this part of Rust's type system is meaningfully better than Go's.

Which is why it's weird to me that the error handling culture of Rust seems to steer so directly towards where Go tries to get to!

Re: Thoughts on Go vs. Rust vs. Zig

#255

Post by throwawaymaths »

kibwen wrote: post #234
macintux wrote: post #201

Earlier quoted context omitted.

> the easiest concurrency model there is Erlang programmers might disagree with you there.

Erlang is great for distributed systems. But my bugbear is when people look at how distributed systems are inherently parallel, and then look at a would-be concurrent program and go, "I know, I'll make my program concurrent by making it into a distributed system". But distributed systems are hard. If your system isn't inherently distributed, then don't rush towards a model of concurrency that emulates a distributed s…

have you ever deployed an erlamg system?

the biggest bugbear for concurrent systems is mutable shared data. by inherently being distributable you basically "give up on that" so for concurrent erlang systems you ~mostly don't even try.

if for no other reason than that erlang is saner than go for concurrency

like goroutines aren't inherently cancellable, so you see go programmers build out the kludgey context to handle those situations and debugging can get very tricky

Re: Thoughts on Go vs. Rust vs. Zig

#256

Post by adastra22 »

dxxvi wrote: post #210
kibwen wrote: post #114

Earlier quoted context omitted.

Outside of single-initialization/lazy-initialization (which are provided via safe and trivial standard library APIs: https://doc.rust-lang.org/std/sync/struct.LazyLock.html ) almost no Rust code uses global mutable variables. It's exceedingly rare to see any sort of global mutable state, and it's one of the lovely things about reading Rust code in the wild when you've spent too much of your life staring at C code who…

> It's exceedingly rare to see any sort of global mutable state I know a bit of Rust, so you don't need to explain in details. How to use a local cache or db connection pool in Rust (both of them, IMO, are the right use case of global mutable state)?

You wrap it in a mutex and then it is allowed.

Global state is allowed. It just has to be thread safe.

Re: Thoughts on Go vs. Rust vs. Zig

#257

Post by samdoesnothing »

zozbot234 wrote: post #86
gwd wrote: post #55

Earlier quoted context omitted.

> For Go, I wouldn't say that the choice to avoid generics was either intentional or minimalist by nature. From what I recall, they were just struggling for a long time with a difficult decision, which trade-offs to make. Indeed, in 2009 Russ Cox laid out clearly the problem they had [1], summed up thus: > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow executio…

Ironically, the latest research by Google has now conclusively shown that Rust programmers aren't really any "slower" or less productive than Go programmers. That's especially true once you account for the entire software lifecycle, including production support and maintenance.

"research", it's a bunch of rust fans at google who are claiming it, without any real serious methodology.

Re: Thoughts on Go vs. Rust vs. Zig

#258

Post by timschmidt »

nu11ptr wrote: post #243
timschmidt wrote: post #231

Earlier quoted context omitted.

> Rust makes it easy to write correct software quickly, but it’s slower for writing incorrect software that still works for an MVP. I don't find that to be the case. It may be slower for a month or two while you learn how to work with the borrow checker, but after the adjustment period, the ideas flow just as quickly as any other language. Additionally, being able to tell at a glance what sort of data functions requi…

I disagree. I've been writing heavy Rust for 5 years, and there are many tasks for which what you say is true. The problem is Rust is a low level language, so there is often ceremony you have to go through, even if it doesn't give you value. Simple lifetimes aren't too bad, but between that and trait bounds on some one else traits that have 6 or 7 associated types, it can get hairy FAST. Then consider a design that w…

> The problem is Rust is a low level language so there is often ceremony you have to go through, even if it doesn't give you value.

As is C++ which I compared it to, where there is even more boilerplate for similar tasks. I spent so much time working with C++ just integrating disparate build systems in languages like Make and CMake which just evaporates to nothing in Rust. And that's before I even get to writing my code.

> I do agree that OFTEN you can get good velocity, but there IS a cost to any large scale program written in Rust.

I'm not saying there's no cost. I'm saying that in my experience (about 4 years into writing decently sized Rust projects now, 20+ years with C/C++) the cost is lower than C++. C++ is one of the worst offenders in this regard, as just about any other language is easier and faster to write software in, but also less capable for odd situations like embedded, so that's not a very high bar. The magical part is that Rust seems just as capable as C++ with a somewhat lower cost than C++. I find that cost with Rust often approaches languages like Python when I can just import a library and go. But Python doesn't let me dip down to the lower level when I need to, whereas C++ and Rust do. Of the languages which let me do that, Rust is faster for me to work in, no contest.

So it seems like we agree. Rust often approaches the productivity of other languages (and I'd say surpasses some), but doesn't hide the complexity from you when you need to deal with it.

Re: Thoughts on Go vs. Rust vs. Zig

#259

Post by pansa2 »

arccy wrote: post #220
pansa2 wrote: post #126

Earlier quoted context omitted.

In Python, it’s common to use exceptions for control flow. Even exiting a loop is done via an exception: `StopIteration`.

isn't break more normal

I’d say it’s more common for iterator-based loops to run to completion than to hit a `break` statement. The `StopIteration` exception is how the iterator signals that completion.

Re: Thoughts on Go vs. Rust vs. Zig

#260

Post by Mawr »

the_gipsy wrote: post #73
oncallthrow wrote: post #46

> Other features common in modern languages, like tagged unions or syntactic sugar for error-handling, have not been added to Go. > It seems the Go development team has a high bar for adding features to the language. The end result is a language that forces you to write a lot of boilerplate code to implement logic that could be more succinctly expressed in another language. Being able to implement logic more succinct…

"Context" here is just a string. Debugging means grepping that string in the codebase, and praying that it's unique. You can only come up with so many unique messages along a stack. You are also not forced to add context. Hell, you can easily leave errors unhandled, without compiler errors nor warnings, which even linters won't pick up, due to the asinine variable syntax rules.

I'm not impressed by the careless tossing around of the word "easily" in this thread.

It's quite ridiculous that you're claiming errors can be easily left unhandled while referring to what, a single unfortunate pattern of code that will only realistically happen due to copy-pasting and gets you code that looks obviously wrong? Sigh.

Post reply on HN