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

591–599 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#591

Post by scotty79 »

riku_iki wrote: post #578
scotty79 wrote: post #462

Earlier quoted context omitted.

I don't know if that's just aged noob in me speaking but so far, while Rust has "zero cost abstractions", Zig feels like it has "Zero abstractions". Deallocating the wrong thing or the right thing too soon bit me in th ass so much already that I feel craving for destructors.

Rust is not zero cost abstractions, they make decision on case-by-case basis.

It's their tagline and it's how it feels. I cen freely abstract. Zig is kind of making me index into byte array all the time.

Re: Thoughts on Go vs. Rust vs. Zig

#592

Post by riku_iki »

scotty79 wrote: post #591
riku_iki wrote: post #578

Earlier quoted context omitted.

Rust is not zero cost abstractions, they make decision on case-by-case basis.

It's their tagline and it's how it feels. I cen freely abstract. Zig is kind of making me index into byte array all the time.

Rust may feel like this in general, but I seen multiple discussions when people spot cases where rust is much slower than C++, they start looking at them, and the finding is that Rust is not zero-cost abstraction, and induce penalty sometime, while C++ is always zero cost abstraction.

Re: Thoughts on Go vs. Rust vs. Zig

#593

Post by irishcoffee »

SkiFire13 wrote: post #442
irishcoffee wrote: post #146

Earlier quoted context omitted.

> The baseline floor of quality will be higher for a Rust program vs. a C program given equal development effort. Hmm, according to whom, exactly? > Second, the total possible footprint of entire classes of bugs is zero thanks to design features of Rust (the borrowck, sum types, data race prevention), except in a specifically delineated areas which often total zero in the vast majority of Rust programs. And yet someh…

> And yet somehow the internet went down because of a program written in rust that didn’t validate input. No, it _did validate_ the input, and since that was invalid it resulted in an error. People can yap about that unwrap all they want, but if the code just returned an error to the caller with `?` it would have resulted in a HTTP 500 error anyway.

So it validated in the input and failed in an unsafe way. Is that what you’re saying? Instead of rejecting the input and failing in a safe way.

My only point was, the language doesn’t matter. It could have been written in brainfuck.

I’m bitching about the rust evangelism, obviously. Neat language, protects against NPEs et. al. It isn’t a magic bullet and it never was.

Re: Thoughts on Go vs. Rust vs. Zig

#594

Post by ayubu »

tayo42 wrote: post #321
Yoric wrote: post #20

Earlier quoted context omitted.

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.

I thought ocaml programs were a little confusing about how they are structured. Also the use of Let wasn't intuitive. go and rust are both still pretty much c style

I think you’d need only a few hours to get used to the let style. Other syntaxes may feel more intuitive simply because we’ve seen more C-style code, but there’s nothing intrinsically “superior” about them. For me, the match syntax, the function signatures, the |> operator, and OCaml’s approach to shadowing are all very readable... often easier to grasp than the equivalent constructs in many other languages.

Re: Thoughts on Go vs. Rust vs. Zig

#595

Post by ayubu »

dmoy wrote: post #277
Yoric wrote: post #20

Earlier quoted context omitted.

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.

I agree that if you’re learning a language primarily to find a job, OCaml isn’t currently the strongest choice, aside from the positions that companies like Tarides offer. However, if your goal is to learn a language that will genuinely improve your programming skills, I’d say OCaml is one of the best options.

Re: Thoughts on Go vs. Rust vs. Zig

#596

Post by ayubu »

BenGosub wrote: post #377

Reading about the the complexity of Rust makes me appreciate more OCaml. OCaml also has a Hindley Milner type system and provides similar runtime guarantees, but it is simpler to write and it has a very, very fast compiler. Also, the generated code is reasonably fast.

…and the compiler is very fast. I’d say that OCaml is now a mature language with modest but steady growth in the standard library, while still introducing ambitious new features in the compiler—such as the effect system.

Re: Thoughts on Go vs. Rust vs. Zig

#597

Post by vips7L »

metaltyphoon wrote: post #577
vips7L wrote: post #485

Earlier quoted context omitted.

Those two aren’t natively compiled. They can be, but it’s not the norm, and it’s hard/time consuming. Java’s type system isn’t as strong as it could be either. It is still lacking proper compile time support for null and there’s been no investment in making error handling better. I’ve written it every day for 10 years and the type system definitely doesn’t help you write correct programs.

> Those two aren’t natively compiled Idk how up to date ou are in .NET but so you can have an idea how trivial it is in C#: echo ‘Console.WriteLine(“hello world”);’ >> app.cs dotnet publish app.cs That’s it. By default C# is natively compiling.

Trivial apps are easy. Non trivial apps, lots of reflection, etc make it really hard.

Re: Thoughts on Go vs. Rust vs. Zig

#598

Post by SkiFire13 »

irishcoffee wrote: post #593
SkiFire13 wrote: post #442

Earlier quoted context omitted.

> And yet somehow the internet went down because of a program written in rust that didn’t validate input. No, it _did validate_ the input, and since that was invalid it resulted in an error. People can yap about that unwrap all they want, but if the code just returned an error to the caller with `?` it would have resulted in a HTTP 500 error anyway.

So it validated in the input and failed in an unsafe way. Is that what you’re saying? Instead of rejecting the input and failing in a safe way. My only point was, the language doesn’t matter. It could have been written in brainfuck. I’m bitching about the rust evangelism, obviously. Neat language, protects against NPEs et. al. It isn’t a magic bullet and it never was.

> So it validated in the input and failed in an unsafe way. Is that what you’re saying? Instead of rejecting the input and failing in a safe way.

It rejected the input and "failed" in a loud way (showing an error) for the user, as opposed to not rejecting the invalid input and continuing anyway in a degraded/invalid state, which would instead have allowed users to continue browsing but would not have worked properly for some other purposes (e.g. it probably would not have continued blocking malicious/bad scraper requests). Neither is ideal, though of course depending on your priorities one might be better than the other.

> My only point was, the language doesn’t matter. It could have been written in brainfuck.

Yeah I definitely agree. My point was that the error was also somewhere else, since an internally-controlled input was invalid.

Re: Thoughts on Go vs. Rust vs. Zig

#599

Post by int_19h »

dlisboa wrote: post #173
int_19h wrote: post #161

Earlier quoted context omitted.

It's not unjust to blame the tool if it behaves contrary to well established expectation, even if that's documented - it's just poor ergonomics then.

Outside very simple programming techniques there is no such thing as well-established when it comes to PL. If one learns more than a handful of languages they’ll see multiple ways of doing the same thing. As an example all three of the languages in the article have different error handling techniques, none of which are actually the most popular choice. Built in data structures in particular, each language does them s…

Working with dynamically sized arrays is not one of those things. To my knowledge, Go is the only high-level language that implements them like that; everybody else has a proper abstraction.
Post reply on HN