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

471–480 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#471

Post by zozbot234 »

pornel wrote: post #465
tucnak wrote: post #353

Earlier quoted context omitted.

I hear this claim on swap all the time, and honestly it doesn't sound convincing. Maybe ten or twenty years ago, but today? CAS latency for DIMM has been going UP, and so is NVMe bandwidth. Depending on memory access patterns, and whether it fits in the NVMe controller's cache (the recent Samsung 9100 model includes 4 GB of DDR4 for cache and prefetch) your application may work just fine.

Swap can be fine on desktops where usage patterns vary a lot, and there are a bunch of idle apps to swap out. It might be fine on a server with light loads or a memory leak that just gets written out somewhere. What I had in mind was servers scaled to run near maximum capacity of the hardware. When the load exceeds what the server can handle in RAM and starts shoving requests' working memory into swap, you typically…

It's almost never the case that memory is uniformly accessed, except for highly artificial loads such as doing inference on a large ML model. If you can stash the "cold" parts of your RAM working set into swap, that's a win and lets you serve more requests out of the same hardware compared to working with no swap. Of course there will always be a load that exceeds what the hardware can provide, but that's true regardless of how much swap you use.

Re: Thoughts on Go vs. Rust vs. Zig

#472

Post by 9rx »

tayo42 wrote: post #318
9rx wrote: post #272

Earlier quoted context omitted.

> That makes even less sense becasue go errors provide even less info other then a chain of messages. That doesn't make sense. Go errors provide exactly whatever information is relevant to the error. The error type is an interface for good reason. The only limiting bound on the information that can be provided is by what the computer can hold at the hardware level. > They might as well be lists of strings. If a strin…

Chill with being condescending if you want a discussion. The error type in go is literally just a string type error interface { Error() string } That's the whole thing. So i dont know what your talking about then. The wrapped error is a list of error types. Which all include a string for display. Displaying an error is how you get that information to the user. If you implement your own error, and check it with some r…

> The error type in go is literally just a string

No, like I said before, it's literally an interface. Hell, your next line even proves it. If it were a string, it would be defined as:

    type error string
But as you've pointed out yourself, that's not its definition at all.

> So i dont know what your talking about then.

I guess that's what happens when you don't even have a basic understanding of programming. Errors are intended to be complex types; to capture all the relevant information that pertains to the error. https://go.dev/play/p/MhQY_6eT1Ir At very least a sentinel value. If your error is just a string, you're doing something horribly wrong — or, charitably, trying to shoehorn Go into scripting tasks. But in that case you'd use Go's exception handlers, which bundles the stack trace and all alongside the string, so... However, if your workload is script in nature, why not just use Python? That's what it was designed for. Different tools for different jobs.

Re: Thoughts on Go vs. Rust vs. Zig

#473

Post by YmiYugy »

Mawr wrote: post #288
YmiYugy wrote: post #105

Earlier quoted context omitted.

What is the context that the Go code adds here? When File::create or os.Create fails the errors they return already contain the information what and why something failed. So what information does "failed to create file: " add?

Whatever context you deem appropriate at the time of writing that message. Don't overfocus on the example. It could be the request ID, the customer's name — anything that's relevant to that particular call.

Well if there is useful context Rust let's you add it. You can easily wrap the io error in something specific to your application or just use anyhow with .context("...")? which is what most people do in application code.

Re: Thoughts on Go vs. Rust vs. Zig

#474

Post by sesm »

globalnode wrote: post #48
kibwen wrote: post #29

> In Rust, creating a mutable global variable is so hard that there are long forum discussions on how to do it. In Zig, you can just create one, no problem. Well, no, creating a mutable global variable is trivial in Rust, it just requires either `unsafe` or using a smart pointer that provides synchronization. That's because Rust programs are re-entrant by default, because Rust provides compile-time thread-safety. If…

so does the rust compiler check for race conditions between threads at compile time? if so then i can see the allure of rust over c, some of those sync issues are devilish. and what about situations where you might have two variables closely related that need to be locked as a pair whenever accessed.

No, it does not.

Rust approach to shared memory is in-place mutation guarded by locks. This approach is old and well-know, and has known problems: deadlocks, lock contention, etc. Rust specifically encourages coarse-granular locks by design, so lock contention problem is very pressing.

There are other approaches to shared memory, like ML-style mutable pointers to immutable data (perfected in Clojure) and actors. Rust has nothing to do with them, and as far as I understand the core choices made by the language make implementing them very problematic.

Re: Thoughts on Go vs. Rust vs. Zig

#476

Post by srameshc »

I started using Rust out of a need , it's tough and I thought I can learn any language easily. But I think from my short experience , Rust teaches how to be a good and thoughtful programmer. My reason to continue learning Rust.

Re: Thoughts on Go vs. Rust vs. Zig

#477

Post by kibwen »

attractivechaos wrote: post #329
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…

> But you only need about 5% of the concepts in that comment to be productive in Rust. The similar argument against C++ is applicable here: another programmer may be using 10% (or a different 5%) of the concepts. You will have to learn that fraction when working with him/her. This may also happen when you read the source code of some random projects. C programmers seldom have this problem. Complexity matters.

No, this is overly simplistic. The features in the quoted comment are largely things that nobody other than stdlib developers need to understand. There is no bespoke subset-dialect of Rust where people are tossing around the `fundamental` attribute--it is strictly an obscure detail that not even an expert Rust programmer would be expected to have even heard of.

Re: Thoughts on Go vs. Rust vs. Zig

#478

Post by bluGill »

Dylan16807 wrote: post #342
bluGill wrote: post #253

Earlier quoted context omitted.

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.

A way to access an "emergency button" function is a significantly smaller sin than arbitrary crashes.

I question that. I would expect in most cases that even if you manage to free up some memory you only have a little bit longer to run before something else uses all the memory and you are back to the original out of memory problem but no place to free up more. Not to mention those caches you just cleared should exist for a good reason and so your program is running slower in the mean time.

Re: Thoughts on Go vs. Rust vs. Zig

#479

Post by 9rx »

tayo42 wrote: post #357
hombre_fatal wrote: post #337

Earlier quoted context omitted.

They should have made the point about knowing where errors will happen. The cherry on top is that you always have a place to add context, but it's not the main point. In the Python example, anything can fail anywhere. Exceptions can be thrown from deep inside libraries inside libraries and there's no good way to write code that exhaustively handles errors ahead of time. Instead you get whack-a-mole at runtime. In Go,…

I don't disagree that exceptions in python aren't perfect and rust is probably closest of them all to getting it right (though still could be improved). I'm just saying stack traces with exceptions provide a lot of useful debugging info. IMO they're more useful then the trail of wrapped error strings in go. exceptions vs returned errors i think is a different discussion then what im getting at here.

> I'm just saying stack traces with exceptions provide a lot of useful debugging info.

The Go team actually did a study on exactly that; including stack traces with errors. Like you, they initially thought it would be useful (hence the study), but in the end, when the data was in, they discovered nobody ever actually used them. Meaningful errors proved to be far more useful.

Science demands replication, so if your study disagrees, let's see it. But in the absence of that, the Go study is the best we've got and it completely contradicts what you are telling us. Making random claims up on the spot based on arbitrary feelings isn't indicative of anything.

That said, I think we can all agree there is a limited place for that type of thing (although in that place you shouldn't use Go at all — there are many other languages much better suited to that type of problem space), but in that place if you had to use Go for some strange reason you'd use panic and recover which already includes the stack trace for you. The functionality is already there exactly as you desire when you do need to bend Go beyond what it is intended for.

Re: Thoughts on Go vs. Rust vs. Zig

#480

Post by kibwen »

forrestthewoods wrote: post #345
smallstepforman wrote: post #326

Earlier quoted context omitted.

You need to be pragmatic and practical. Extra large codebases have controllers/managers that must be accessible by many modules. A single global vs dozens of local references to said “global” makes code less practical.

One of my favorite talks of all-time is the GDC talk on Overwatch's killcam system. This is the thing that when you die in a multiplayer shooter you get to see the last ~4 seconds of gameplay from the perspective of your killer. https://www.youtube.com/watch?v=A5KW5d15J7I The way Blizzard implemented this is super super clever. They created an entirely duplicate "replay world". When you die the server very quickly "b…

If we're getting philosophical, we can identify a hierarchy of globals:

1. Read-only (`const`s in Rust). These are fine, no objections.

2. Automatic-lazily-initialized write-once, read-only thereafter (`LazyLock` in Rust). These are also basically fine.

3. Manually-initialized write-once, read-only thereafter (`OnceLock` in Rust). These are also basically fine, but slightly more annoying because you need to be sure to manually cover all possible initialization pathways.

4. Write-only. This is where loggers are, and these are also basically fine.

5. Arbitrary read/write. This is the root of all evil, and what we classically mean when we say "global mutable state".

Post reply on HN