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

491–500 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#491

Post by tayo42 »

Orygin wrote: post #451
tayo42 wrote: post #357

Earlier quoted context omitted.

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 disagree, adding context to errors provide exactly what is needed to debug the issue. If you don't have enough context it's your fault, and context will contain more useful info than a stack trace (like the user id which triggered the issue, or whatever is needed). Stack traces are reserved for crashes where you didn't handle the issue properly, so you get technical info of what broke and where, but no info on what…

It's one piece of information, but logging at the error location does that still. And if you have a function that's called in multiple places how do you know the path that got you into that place. If it wasn't useful we wouldn't try to recreate them with wrapped errors

Re: Thoughts on Go vs. Rust vs. Zig

#492

Post by mrsmrtss »

sylens wrote: post #454
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.

Closest is probably C# but its still primarily an OOP driven language

I would say, C# supports more functional programming than Go. Go is more imperative than a functional language.

Re: Thoughts on Go vs. Rust vs. Zig

#494

Post by speed_spread »

irishcoffee wrote: post #148
mh2266 wrote: post #133

Earlier quoted context omitted.

This just skips the: > First, if you aren't writing device drivers/kernels or something very low level there is a high probability your program will have zero unsafe usages in it. from the original comment. Meanwhile all C code is implicitly “unsafe”. Rust at least makes it explicit! But even if you ignore memory safety issues bypassed by unsafe, Rust forces you to handle errors, it doesn’t let you blow up on null po…

Isn’t rust proffered up as a systems language? One that begged to be accepted into the Linux kernel? Don’t device drivers live in the Linux kernel tree? So, unsafe code is generally approved in device driver code? Why not just use C at that point?

Because writing proper kernel C code requires decades of experience to navigate the implicit conventions and pitfalls of the existing codebase. The human pipeline producing these engineers is drying up because nobody's interested in learning that stuff by going through years of patch rejection from maintainers that have been at it since the beginning.

Rust's rigid type system, compiler checks and insistence on explicitness forces a _culture change_ in the organization. In time, this means that normal developers will regain a chance to contribute to the kernel with much less chance of breaking stuff. Rust not only makes compiled binary more robust but also makes the codebase more accessible.

Re: Thoughts on Go vs. Rust vs. Zig

#495

Post by data-ottawa »

smallstepforman wrote: post #330
10000truths wrote: post #77

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

Linux has overcommit so failing malloc hasnt been a thing for over a decade. Zig is late to the party since it strong arms devs to cater to a scenerio which no longer exists.

I had a teacher who said "a good programmer looks both ways before crossing a one way street"

Re: Thoughts on Go vs. Rust vs. Zig

#496

Post by kibwen »

forrestthewoods wrote: post #418
themafia wrote: post #385

Earlier quoted context omitted.

> They are pure pure pure evil. They are to be used with caution. If your execution environment is simple enough they can be quite useful and effective. Engineering shouldn't be a religion. > I can not count how many times I have been pulled in to debug some gnarly crash and the result was, inevitably, a mutable global variable. I've never once had that happen. What types of code are you working on that this occurs s…

> If your execution environment is simple enough they can be quite useful and effective Saud by many an engineer whose code was running in systems that were in fact not that simple! What is irksome is that globals are actually just kinda straight worse. Like the code that doesn't use a singleton and simply passes a god damn pointer turns out to be the simpler and easier thing to do. > What types of code are you worki…

> All I want in life is a pure C API. It is simple and elegant and delightful and you can wrap it to run in any programming environment in existence.

Sure thing boss, here's that header file populated exclusively by preprocessor macros that you asked for.

Re: Thoughts on Go vs. Rust vs. Zig

#497

Post by kibwen »

Joker_vD wrote: post #455
kibwen wrote: post #222

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

> it "just requires" you to flawlessly uphold memory access invariants manually across all possible concurrent states of your program. Which, for certain kinds of programs, is trivially simple for e.g. "set value once during early initialization, then only read it". No, it's not thread-local. And even for "okay, maybe atomically update it once in a blue moon from one specific place in code" scenario is pretty easy to…

Sure, and those use cases are just as easily supported by Rust, in a more principled manner that directly encodes the intent and resists misuse by people modifying the code later.

Re: Thoughts on Go vs. Rust vs. Zig

#498

Post by kibwen »

jpfromlondon wrote: post #456
kibwen wrote: post #222

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

>it "just requires" you to flawlessly uphold memory access invariants manually across all possible concurrent states of your program. The difference is it doesn't prevent you so it doesn't "just require"

Sure, it only "just requires" it if you actually care about your program working properly in the presence of concurrency. To reiterate, this is as true in Rust as it is in C or Zig, it's just that also Rust allows you to do better than the "YOLO" approach to concurrency in a way that most languages could only dream of.

Seriously, I'm begging people to try writing a program that uses ordinary threads in Rust via `std::thread::scope`, it's eye-opening how lovely thread-based concurrency is when you have modern tools at your disposal.

Re: Thoughts on Go vs. Rust vs. Zig

#499

Post by ux266478 »

mirashii wrote: post #292
ux266478 wrote: post #196

Earlier quoted context omitted.

> Code that invokes UB is incorrect, full stop. That's not true at all, who taught you that? Think of it like this, signed integer over/underflow is UB. All addition operations over ints are potentially invoking UB. int add (int a, int b) { return a + b; } So this is incorrect code by that metric, that's clearly absurd. Compilers explicitly provide you the means to disable optimizations in a granular way over undefin…

> -fno-strict-aliasing doesn't suddenly make pointer aliasing defined behavior. No, it just protects you from a valid but unexpected optimization to your incorrect code. It's even spelled out clearly in the docs: https://www.gnu.org/software/c-intro-and-ref/manual/html_nod... "Code that misbehaves when optimized following these rules is, by definition, incorrect C code." > We have compiler behavior for incorrect code…

Those are the docs for a compiler, not the language standard.

Re: Thoughts on Go vs. Rust vs. Zig

#500

Post by gf000 »

vips7L wrote: post #485
metaltyphoon wrote: post #483

Earlier quoted context omitted.

Out of all those only Java and Kotlin captured significant market like OP mentioned

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.

Compared to what? Because compared to go which has not one but 2 nulls, and an even more anemic type system it is surely much better.

> the type system definitely doesn’t help you write correct programs.

It surely helps significantly. You are just looking for even more from the type system, but that's another (fair) statement to make.

Post reply on HN