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

541–550 of 599 posts

Re: Thoughts on Go vs. Rust vs. Zig

#541

Post by ClayShentrup »

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…

it's the classic Rich hickey talk. simple made easy.

Re: Thoughts on Go vs. Rust vs. Zig

#542

Post by ClayShentrup »

aw1621107 wrote: post #484
sesm wrote: post #474

Earlier quoted context omitted.

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…

> There are other approaches to shared memory, like ML-style mutable pointers to immutable data (perfected in Clojure) and actors. Rust has nothing to do with them, and as far as I understand the core choices made by the language make implementing them very problematic. Would you mind elaborating on this? At least off the top of my head a mut Arc seems like it should suffice for a mutable pointer to immutable data, a…

mutable pointers to immutable data is the ticket.

Re: Thoughts on Go vs. Rust vs. Zig

#543

Post by 1313ed01 »

wtetzner wrote: post #208
1313ed01 wrote: post #83

Earlier quoted context omitted.

I would love to see a language that is to C what Rust is to C++. Something a more average human brain like mine can understand. Keep the no-gc memory safety things, but simplify everything else a thousand times. Not saying that should replace Rust. Both could exist side by side like C and C++.

I'm curious about what you'd want simplified. Remove traits? What other things are there to even simplify if you're going to keep the borrow checker?

I'm the last person to be able to answer that. There would be Chesterton's fences everywhere for one thing.

Better question is what to add to something like C. The bare minimum to make it perfectly safe. Then stop there.

Re: Thoughts on Go vs. Rust vs. Zig

#544

Post by hu3 »

zozbot234 wrote: post #86
gwd wrote: post #55

Earlier quoted context omitted.

> For Go, I wouldn't say that the choice to avoid generics was either intentional or minimalist by nature. From what I recall, they were just struggling for a long time with a difficult decision, which trade-offs to make. Indeed, in 2009 Russ Cox laid out clearly the problem they had [1], summed up thus: > The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow executio…

Ironically, the latest research by Google has now conclusively shown that Rust programmers aren't really any "slower" or less productive than Go programmers. That's especially true once you account for the entire software lifecycle, including production support and maintenance.

Could you point the research?

I only found a blog-like post with bold claims and no statistical significance.

Re: Thoughts on Go vs. Rust vs. Zig

#545

Post by hu3 »

raggi wrote: post #190
School-Cotton wrote: post #82

Earlier quoted context omitted.

> I pretty new to Rust and I’m wondering why global mutables are hard? They're not. fn main() { unsafe { COUNTER += 1; println!("COUNTER = {}", COUNTER); } unsafe { COUNTER += 10; println!("COUNTER = {}", COUNTER); } } Global mutable variables are as easy in Rust as in any other language. Unlike other languages, Rust also provides better things that you can use instead.

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()

Re: Thoughts on Go vs. Rust vs. Zig

#546

Post by hu3 »

nixpulvis wrote: post #275
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.

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

Re: Thoughts on Go vs. Rust vs. Zig

#547

Post by auxiliarymoose »

pornel wrote: post #459
auxiliarymoose wrote: post #300

Earlier quoted context omitted.

But how does one communicate and synchronize between tasks with structured concurrency? Consider a server handling transactional requests, which submit jobs and get results from various background workers, which broadcast change events to remote observers. This is straightforward to set up with channels in Go. But I haven't seen an example of this type of workload using structured concurrency.

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.

Re: Thoughts on Go vs. Rust vs. Zig

#548

Post by BitFlogger »

tucnak wrote: post #353
pornel wrote: post #287

Earlier quoted context omitted.

Even on Linux with overcommit you can have allocations fail, in practical scenarios. You can impose limits per process/cgroup. In server environments it doesn't make sense to run off swap (the perf hit can be so large that everything times out and it's indistinguishable from being offline), so you can set limits proportional to physical RAM, and see processes OOM before the whole system needs to resort to OOMKiller.…

I hear this claim on swap all the time, and honestly it doesn't sound convincing. Maybe ten or twenty years ago, but today? CAS latency for DIMM has been going UP, and so is NVMe bandwidth. Depending on memory access patterns, and whether it fits in the NVMe controller's cache (the recent Samsung 9100 model includes 4 GB of DDR4 for cache and prefetch) your application may work just fine.

Swap isn't just for when you run out of ram though.

Don't look at swap as more memory on slow / hdds. Look at it as a place the kernel can use if it needs a place to put something temporarily.

This can happen on large memory systems fairly easily when memory gets fragments and something asks for a chunk of memory than can't be allocated because there isn't a large enough contiguous block, so the allocation fails.

I always do a least a couple of GBs now for swap... I won't really miss the storage and that at least gives the kernel a place to re-org/compact memory and keep chugging along.

Re: Thoughts on Go vs. Rust vs. Zig

#549

Post by semiinfinitely »

kibwen wrote: post #29

> In Rust, creating a mutable global variable is so hard that there are long forum discussions on how to do it. In Zig, you can just create one, no problem. Well, no, creating a mutable global variable is trivial in Rust, it just requires either `unsafe` or using a smart pointer that provides synchronization. That's because Rust programs are re-entrant by default, because Rust provides compile-time thread-safety. If…

well no ackchyually

Re: Thoughts on Go vs. Rust vs. Zig

#550

Post by legobmw99 »

auxym wrote: post #225
rishabhaiover wrote: post #136

> it is like C in that you can fit the whole language in your head. This is exactly why I find Go to be an excellent language. Most of the times, Go is the right tool. Rust doesn't feel like a tool. Ceremonial yet safe and performant.

> it is like C in that you can fit the whole language in your head. Sure, you can fit all of C in your head, including all the obscure footguns that can lead to UB: https://gist.github.com/Earnestly/7c903f481ff9d29a3dd1 And other fun things like aliasing rules and type punning.

Yeah, I think people find C appealing because it feels like you can fit the whole language in your head. I’ve yet to meet someone who has actually accomplished this in practice
Post reply on HN