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

501–510 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#501

Post by xyzzy_plugh »

bluGill wrote: post #478
Dylan16807 wrote: post #342

Earlier quoted context omitted.

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.

What if for my program, 99.99% of OOM crashes are preventable by simply running a GC cycle?

Re: Thoughts on Go vs. Rust vs. Zig

#502

Post by ezst »

forgotpwd16 wrote: post #351
ezst wrote: post #348

Should really consider adding scala-native to the comparison : https://scala-native.org/en/latest/

There're many languages that can be added in such comparison. Why Scala Native (which looks nice sure) over more prominent C/C++ successors/alternatives such as D, Nim, V, Odin, Hare, etc?

I think if fits well in this comparison, because Scala-native:

- has the ergonomics, abstractions, expressiveness and conveniences of a high-level language with pointer-level semantics if/when needed (essentially covering the abstraction vs. cost spectrum of all those languages)

- can be used with or without GC (same)

- has the libraries and tooling to tackle massively concurrent/parallel workloads with ease (the niche that Go carved for itself)

- offers the same memory safety guarantees as Rust, and possibly more in the future with capture-checking (a more general concept than borrow-checking to guarantee resources scoping at compile-time)

Re: Thoughts on Go vs. Rust vs. Zig

#503

Post by ViewTrick1002 »

afiori wrote: post #469
ViewTrick1002 wrote: post #421

Earlier quoted context omitted.

And in that universe Rust is likely an inconsequential niche language.

If rust skipped async features I think it would not have damaged it much

Almost the entire early large scale adoption came from people writing async web services.

From 2023:

> In that regard, async/await has been phenomenally successful. Many of the most prominent sponsors of the Rust Foundation, especially those who pay developers, depend on async/await to write high performance network services in Rust as one of their primary use cases that justify their funding.

https://without.boats/blog/why-async-rust/

Re: Thoughts on Go vs. Rust vs. Zig

#504

Post by [deleted] »

sesm wrote: post #474
globalnode wrote: post #48

Earlier quoted context omitted.

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…

[deleted]

Re: Thoughts on Go vs. Rust vs. Zig

#506

Post by vips7L »

gf000 wrote: post #500
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.

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.

I started this thread criticizing Go. I think it’s a terribly verbose language that has ignored all language dev of the last half century. It’s why I continue to write Java.

However, I don’t think that shields Java from its inability to make the language better. We still don’t have checked nulls and at this rate, even though there’s a draft JEP, I am not sure we will get them within this decade. The community still blindly throws unchecked exceptions because checked exceptions have received no investment to make them easy to work with.

The point of this thread is that people do want that. They want a natively compiled language (by default), that has checked nulls, errors represented in the type system, and has a GC.

Re: Thoughts on Go vs. Rust vs. Zig

#507

Post by port11 »

hu3 wrote: post #460
michaelscott wrote: post #445

Earlier quoted context omitted.

After using Rust for many years now, I feel that a mutable global variable is the perfect example of a "you were so busy figuring out whether you could, you never stopped to consider whether you should". Moving back to a language that does this kind of thing all the time now, it seems like insanity to me wrt safety in execution

Global mutable state is like a rite of passage for devs. Novices start slapping global variables everywhere because it makes things easy and it works, until it doesn't and some behaviour breaks because... I don't even know what broke it. On a smaller scale, mutable date handling libraries also provide some memorable WTF debugging moments until one learns (hopefully) that adding 10 days to a date should probably retur…

Hey, don't tell that to front-end developers, we like our global stores accessible all over.

Re: Thoughts on Go vs. Rust vs. Zig

#508

Post by ModernMech »

echelon wrote: post #2

> Many people seem confused about why Zig should exist if Rust does already. It’s not just that Zig is trying to be simpler. I think this difference is the more important one. Zig wants you to excise even more object-oriented thinking from your code. I feel like Zig is for the C / C++ developers that really dislike Rust. There have been other efforts like Carbon, but this is the first that really modernizes the langu…

> This desire of wanting to write OO-style code makes me think that people who want OO-style code are the ones having a lot of struggle or frustration with Rust's ergonomics.

I believe this is actually a significant source of consternation. I teach Rust to students, and I find those without a C/C++ background take to it more naturally than those who have a lot of experience with those languages. People with a C/C++ background approach Rust like C/C++ and fight it the whole way, whereas people without that background approach Rust as Rust, and they have a better time with it.

Re: Thoughts on Go vs. Rust vs. Zig

#509

Post by iLemming »

port11 wrote: post #507
hu3 wrote: post #460

Earlier quoted context omitted.

Global mutable state is like a rite of passage for devs. Novices start slapping global variables everywhere because it makes things easy and it works, until it doesn't and some behaviour breaks because... I don't even know what broke it. On a smaller scale, mutable date handling libraries also provide some memorable WTF debugging moments until one learns (hopefully) that adding 10 days to a date should probably retur…

Hey, don't tell that to front-end developers, we like our global stores accessible all over.

It's because of the "status quo". Once you start using immutable-first language on the front-end, e.g., Clojurescript - your perspective changes.

Re: Thoughts on Go vs. Rust vs. Zig

#510

Post by mrsmrtss »

vips7L wrote: post #505
mrsmrtss wrote: post #493

Earlier quoted context omitted.

C# can also be compiled AOT.

With the same difficulties as Java.

But it's improving fast. They even made the new file-based apps target Native AOT by default (https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotn...).
Post reply on HN