Thoughts on Go vs. Rust vs. Zig

Post by raggi » Sat, Dec 06, 2025, 8:22 PM UTC

zozbot234 wrote: post #443

raggi wrote: post #215

Earlier quoted context omitted.

> How so? Garbage collection has inherent performance overhead wrt. manual memory management, and Rust now addresses this by providing the desired guarantees of managed memory without the overhead of GC. I somewhat disagree, specifically on the implicit claim that all GC has overhead and alternatives do not. Rust does a decent job of giving you some ergonomics to get started, but it is still quite unergonomic to fix…

> I somewhat disagree, specifically on the implicit claim that all GC has overhead and alternatives do not. Not a claim I made. Obviously there are memory management styles (such as stack allocation, pure static memory or pluggable "arenas"/local allocators) that are even lower overhead than a generic heap allocator, and the Rust project does its best to try and support these styles wherever they might be relevant, e…

Post by raggi » Sat, Dec 06, 2025, 10:23 PM UTC

hu3 wrote: post #572

raggi wrote: post #554

Earlier quoted context omitted.

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

Still different. Yours only increments once. Doesn't pass basic QA. And declaring a static variable inside a function, even if in main, smells.

Post by School-Cotton » Sun, Dec 07, 2025, 5:31 PM UTC

raggi wrote: post #573

hu3 wrote: post #572

Earlier quoted context omitted.

Still different. Yours only increments once. Doesn't pass basic QA. And declaring a static variable inside a function, even if in main, smells.

OP you keep comparing to doesn't even declare the variable. I'm done with you.

  static mut COUNTER: u32 = 0;

  #![allow(static_mut_refs)]

Post by metaltyphoon » Sun, Dec 07, 2025, 6:55 PM UTC

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.

   echo ‘Console.WriteLine(“hello world”);’ >> app.cs
   dotnet publish app.cs

Post by weakfish » Tue, Dec 09, 2025, 12:20 AM UTC

masklinn wrote: post #518

weakfish wrote: post #514

Earlier quoted context omitted.

How is that an error if b is properly referenced? It’s perhaps a waste of memory but not wrong

Because `append` works in-place, Go slices are amortised, and the backing buffer is shared between `a` and `b`, so unless you never ever use a again it likely will have strange effects e.g. a := make([]int, 0, 5) a = append(a, 0, 0) b := append(a, 1) a = append(a, 0) fmt.Println(b) prints [0 0 0] because the following happens: a := make([]int, 0, 5) // a = [() _ _ _ _ _] // a has length 0 but the backing buffer has c…