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

551–560 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#551

Post by nixpulvis »

hu3 wrote: post #546
nixpulvis wrote: post #275

Earlier quoted context omitted.

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.

And yet all that PL research couldn't stop rust from bringing cloudflare down. And the compiler had nothing to say about it. "Carry on, thisi is perfectly fine rust code that might crash your app with a panic if left unchecked, no biggie. LGTM" - rust compiler

I'm so sick of hearing about how "Rust brought cloudflare down". No it did not. Unhandled error cases are possible in any language, and calling `unwrap` is literally the developer telling the compiler, trust me, it's not an error.

This lies completely on the developers.

Re: Thoughts on Go vs. Rust vs. Zig

#552

Post by pornel »

auxiliarymoose wrote: post #547
pornel wrote: post #459

Earlier quoted context omitted.

You do the same thing, if that's really the architecture you need. Channels communicating between persistent workers are fine when you need decoupled asynchronous operation like that. However, channels and detached coroutines are less appropriate in a bunch of other situations, like fork-join, data parallelism, cancellation of task trees, etc. You can still do it, but you're responsible for adding that structure, and…

You can accomplish fork-join, data parallelism, and cancellation of task trees in a with `errgroup` in Go (which provides a way to approach structured concurrency). So at least those are a subset of Go's concurrency model.

> So at least those are a subset of Go's concurrency model.

That's why the article about structured concurrency compared it to goto. Everything is a subset of goto. It can do everything that structured programming can do, and more! With goto you can implement your own conditions, switches, loops, and everything else.

The problem is not the lack of power, but lack of enforced structure. You can implement fork-join, but an idiomatic golang implementation won't stop you from forking and forgetting to join.

Another aspect of it is not really technical, but conventions that fell out of what the language offers. It's just way more common to DIY something custom from a couple of channels, even if it could be done with some pre-defined standard pattern. To me, this makes understanding behavior of golang programs harder, because instead of seeing something I already know, like list.par_iter().map().collect(), I need to recognize such behavior across a larger block of code, and think twice whether each channel-goroutine dance properly handles cancellations, thread pool limits, recursive dependencies, is everything is correctly read-only/atomic/locked, and so on.

Re: Thoughts on Go vs. Rust vs. Zig

#553

Post by hu3 »

nixpulvis wrote: post #551
hu3 wrote: post #546

Earlier quoted context omitted.

And yet all that PL research couldn't stop rust from bringing cloudflare down. And the compiler had nothing to say about it. "Carry on, thisi is perfectly fine rust code that might crash your app with a panic if left unchecked, no biggie. LGTM" - rust compiler

I'm so sick of hearing about how "Rust brought cloudflare down". No it did not. Unhandled error cases are possible in any language, and calling `unwrap` is literally the developer telling the compiler, trust me, it's not an error. This lies completely on the developers.

Yes it did.

At the very least, something that brings the application down when the dev assumption fails should be called a much more dangerous word than "unwrap".

So yes, the language has failed there.

"You're holding it wrong" doesn't uphold when one of the language's touted characteristics is having a bitchy compiler designed to save devs from their own stupidity.

Re: Thoughts on Go vs. Rust vs. Zig

#554

Post by raggi »

hu3 wrote: post #545
raggi wrote: post #190

Earlier quoted context omitted.

People always complain about unsafe, so I prefer to just show the safe version. use std::sync::Mutex; static LIST: Mutex > = Mutex::new(Vec::new()); fn main() -> Result > { LIST.lock()?.push("hello world".to_string()); println!("{}", LIST.lock()?[0]); Ok(()) }

This is completely different from the previous example. It doesn't increment anything for starters. The example would be more convoluted if it did the same thing. And strings in rust always delivers the WTFs I need o na Friday: "hello world".to_string()

    use std::sync::Mutex;
    fn main() -> Result> {
        static PEDANTRY: Mutex = Mutex::new(0);
        *PEDANTRY.lock()? += 1;
        println!("{}", PEDANTRY.lock()?);
        Ok(())
    }

Re: Thoughts on Go vs. Rust vs. Zig

#555

Post by bird0861 »

I've been asking around the last week about Go vs Elixir vs Zig, I'd love to get feedback here too. I only have time for one and I'm looking for something that can replace a lot of the stuff I do with Python. I don't have time to wait for Mojo.

Re: Thoughts on Go vs. Rust vs. Zig

#556

Post by vips7L »

gf000 wrote: post #537
vips7L wrote: post #506

Earlier quoted context omitted.

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

Well, it's far from trivial to introduce such a change if you don't want to throw away 3 decades of code/assumptions. Of course null safety would be very welcome, I'm with you on this. As for unchecked exceptions, that may be a bit of an "unreasonable ask". The only language that properly solves the problem are languages with effect types, which are an active research area. Every other language have either FP-like er…

Nah man. They could make checked exceptions less boiler platey. Simple things like Swift’s try! Or try?, and making the try construct an expression would go a long way to increase checked error usage and therefore correctness. We don’t even need to solve the lambda problem. We just need to make it easy to deal with checked exceptions. Right now you have a minimum 5 lines of boiler plate to escape them.

Re: Thoughts on Go vs. Rust vs. Zig

#557

Post by aw1621107 »

hu3 wrote: post #553
nixpulvis wrote: post #551

Earlier quoted context omitted.

I'm so sick of hearing about how "Rust brought cloudflare down". No it did not. Unhandled error cases are possible in any language, and calling `unwrap` is literally the developer telling the compiler, trust me, it's not an error. This lies completely on the developers.

Yes it did. At the very least, something that brings the application down when the dev assumption fails should be called a much more dangerous word than "unwrap". So yes, the language has failed there. "You're holding it wrong" doesn't uphold when one of the language's touted characteristics is having a bitchy compiler designed to save devs from their own stupidity.

> "You're holding it wrong" doesn't uphold when one of the language's touted characteristics is having a bitchy compiler designed to save devs from their own stupidity.

The thing is that Rust's promises are more tightly scoped to very specific types of (mis)behavior. I don't believe it has ever claimed to prevent any and all types of stupidity, let alone ones that have non-stupid uses.

Re: Thoughts on Go vs. Rust vs. Zig

#559

Post by jcgl »

diarrhea wrote: post #528
attractivechaos wrote: post #329

Earlier quoted context omitted.

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

A similar problem applies to Go, just inverted. Take iteration. The vast majority of use cases for iterating over containers are map, filter, reduce. Go doesn't have these functions. That's very simple! All Go developers are aligned here: just use a for loop. There's no room for "10% of concepts corners", there's just that 1 corner. But, for loops get tedious. So people will make helper functions. Generic ones today,…

> The result is that you have a zoo of iteration-related helper functions all throughout. You'll need to learn those when onboarding to a new code base as well.

This is overblown, imo. Now just generics exist, you just define Map(), Filter(), and Reduce() in your internal util package. So yes, a new dev needs to find the util package. But they need to do that anyway.

What’s more, these particular functions don’t spread into the type signatures of other functions. That means a new dev only has to go looking for them when they themselves want to use those functions.

Sure, it’s not entirely ideal maybe. But the tone and content of your comment makes it sound a zillion times worse than it is.

Re: Thoughts on Go vs. Rust vs. Zig

#560

Post by port11 »

iLemming wrote: post #509
port11 wrote: post #507

Earlier quoted context omitted.

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.

I know. I'm mostly gone from FE, the amount of cargo culting and “we do things that way because that's how it's always been” is toxic.
Post reply on HN