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

271–280 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#271

Post by nu11ptr »

tptacek wrote: post #254
nu11ptr wrote: post #237

Earlier quoted context omitted.

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

Interesting. It is semi-rare that I meet someone who knows both Rust and Go and prefers Go. Is it the velocity you get from coding in it?

I have a love/hate relationship with Go. I like that it lets me code ideas very fast, but my resulting product just feels brittle. In Rust I feel like my code is rock solid (with the exception of logic, which needs as much testing as any other lang) often without even testing, just by the comfort I get from lack of nil, pattern matching, etc.

Re: Thoughts on Go vs. Rust vs. Zig

#272

Post by 9rx »

tayo42 wrote: post #218
9rx wrote: post #183

Earlier quoted context omitted.

It's enough information if you are happy to have a fragile API, but why would you purposefully make life difficult not only for yourself, but the developers who have their code break every time you decide to change something that should only be an internal implementation detail? Look, if you're just writing a script that doesn't care about failure — where when something goes wrong you can exit and let the end user de…

That makes even less sense becasue go errors provide even less info other then a chain of messages. They might as well be lists of strings. You can maybe reassbmle a call stack your self if all of the error handlers are vigalente about wrapping

> 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 string is all your error is, you're doing something horribly wrong.

Or, at very least, are trying to shoehorn Go into scripting tasks, of which it is not ideally suited for. That's what Python is for! Python was decidedly intended for scripting. Different tools for different jobs.

Go was never designed to be a scripting language. But should you, for some odd reason, find a reason to use in that that capacity, you should at least being using its exception handlers (panic/recover) to find some semblance of scripting sensibility. The features are there to use.

Which does seem to be the source of your confusion. You still seem hung up on thinking that we're talking about scripting. But clearly that's not true. Like before, if we were, we'd be looking at using Go's exception handlers like a scripting language, not the patterns it uses for systems. These are very different types of software with very different needs. You cannot reasonably conflate them.

Re: Thoughts on Go vs. Rust vs. Zig

#273

Post by zephen »

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

The point is that the use of exceptions is built into the language, so, for example, if you write "for something in somegeneratorfunction():" then somegeneratorfunction will signal to the for loop that it is finished by raising this exception.

Re: Thoughts on Go vs. Rust vs. Zig

#274

Post by sheepscreek »

> I’m not the first person to pick on this particular Github comment, but it perfectly illustrates the conceptual density of Rust

Eh, that's not typical Rust project code though. It is Rust code inside the std lib. std libs of most languages including Python are a masterclass in dark arts. Rust is no exception.

Re: Thoughts on Go vs. Rust vs. Zig

#275

Post by nixpulvis »

vegabook wrote: post #80

The last paragraph captures the essence that all the PL theory arguments do not. "Zig has a fun, subversive feel to it". It gives you a better tool than C to apply your amazing human skills, freely, whereas both Rust and Go are fundamentally sceptical about you.

I for one welcome the use of type systems and PL research to guide me in expressing my programs in correct ways and telling me when I'm wrong based on solid principals. If you want to segfault for fun, there's a time and a place for that, but it's not in my production code.

Re: Thoughts on Go vs. Rust vs. Zig

#276

Post by [deleted] »

Capricorn2481 wrote: post #198
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…

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

[deleted]

Re: Thoughts on Go vs. Rust vs. Zig

#277

Post by dmoy »

Yoric wrote: post #20
dmoy wrote: post #4

For a lot of stuff what I really want is golang but with better generics and result/error/enum handling like rust.

Have you tried OCaml? With the latest versions, it also has an insanely powerful concurrency model. As far as I understand (I haven't looked at the benchmarks myself), it's also performance-competitive with Go.

Yea, there's not much for large scale production ocaml though, do it would be a tough sell at my work. It's one of those things where like.... if I got an offer to work at jane street I might take it solely for the purpose of ocaml lol.

Re: Thoughts on Go vs. Rust vs. Zig

#278

Post by rowanG077 »

kibwen wrote: post #222
ajross wrote: post #214

Earlier quoted context omitted.

> [...] is trivial in Rust [...] it just requires [...] This is a tombstone-quality statement. It's the same framing people tossed around about C++ and Perl and Haskell (also Prolog back in the day). And it's true, insofar as it goes. But languages where "trivial" things "just require" rapidly become "not so trivial" in the aggregate. And Rust has jumped that particular shark. It will never be trivial, period.

> 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 really it to me. It's like saying, "look people it's so much easier to develop and build an airplane when you don't have to adhere to any rules". Which of course is true. But I don't want to fly in any of those airplanes, even if they are designed and build by the best and brightest on earth.

Re: Thoughts on Go vs. Rust vs. Zig

#279

Post by timschmidt »

nu11ptr wrote: post #267
timschmidt wrote: post #258

Earlier quoted context omitted.

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

> 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. I was responding to "as any other language". Compared to C++, yes, I can see how iteration would faster. Compared to C#/Go/Python/etc., no, Rust is a bit slower to iterate for some things due to need to provi…

> Rust is a bit slower to iterate for some things due to need to provide low level details sometimes.

Sometimes specific tasks in Rust require a little extra effort - like interacting with the file picker from WASM required me to write an async function. In embedded sometimes I need to specify an allocator or executor. Sometimes I need to wrap state that's used throughout the app in an Arc(Mutex()) or the like. But I find that there are things like that in all languages around the edges. Sometimes when I'm working in Python I have to dip into C/C++ to address an issue in a library linked by the runtime. Rust has never forced me to use a different language to get a task done.

I don't find the need to specify types to be a particular burden. If anything it speeds up my development by making it clearer throughout the code what I'm operating on. The only unsafe I've ever had to write was for interacting with a GL shader, and for binding to a C library, just the sort of thing it's meant for, and not really possible in those other languages without turning to C/C++. I've always managed to use existing datastructures or composites thereof, so that helps. But that's all you get in languages like C#/Go/Python/etc. as well.

The big change for me was just learning how to think about and structure my code around data lifetimes, and then I got the wonderful experience other folks talk about where as soon as the code compiles I'm about 95% certain it works in the way I expect it to. And the compiler helps me to get there.

Re: Thoughts on Go vs. Rust vs. Zig

#280

Post by disappoint »

lowbloodsugar wrote: post #246
etse wrote: post #87

Earlier quoted context omitted.

That seems unusual. I would assume trivial means the default approach works for most cases. Perhaps mutable global variables are not a common use case. Unsafe might make it easier, but it’s not obvious and probably undesired. I don’t know Rust, but I’ve heard pockets of unsafe code in a code base can make it hard to trust in Rust’s guarantees. The compromise feels like the language didn’t actually solve anything.

So I've got a crate I built that has a type that uses unsafe. Couple of things I've learned. First, yes, my library uses unsafe, but anyone who uses it doesn't have to deal with that at all. It behaves like a normal implementation of its type, it just uses half the memory. Outside of developing this one crate, I've never used unsafe. Second, unsafe means the author is responsible for making it safe. Safe in rust mean…

[flagged]
Post reply on HN