Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig feels more practical than Rust for real-world CLI tools

dayvster.com

Post reply on HN
Print view View original

321–330 of 412 posts

Re: Zig feels more practical than Rust for real-world CLI tools

#321

Post by tialaramex »

mattwilsonn888 wrote: post #273
thinkharderdev wrote: post #203

Earlier quoted context omitted.

> As long as the audience accepts the framing that ergonomics doesn't matter because it can't be quantified, the hand-waving exemplified above will confound. I interpreted the parent to be saying that ergonomics IS (at least partly) subjective. The subjective aspect is "what you are used to". And once you get used to Rust its ergonomics are fine, something I agree with having used Rust for a few years now. > The Rust…

I think you are clearly good-faith. The issue is the underlying and unfair assumption that is so common in these debates: that the memory-unsafe language we're comparing against Rust is always C/C++, rather than a modern approach like Zig or Odin (which will share many arguments against C/C++). You can prove to yourself this happens by looking around this thread! The topic is Zig vs. Rust and just look at how many pr…

The ergonomics of Odin are ghastly, it's all special cases all the time.

For example, in Rust when we write `for n in 0..10 {` that 0..10 is a Range, we can make one of those, we can store one in a variable, Range is a type. In Odin `for i in 0..in Rust we can `for puppy in litter {` and litter - whatever type that is - just has to implement IntoIterator, the trait for things which know how to be iterated, and they iterate over whatever that iterator does. In Odin only specific built-in types are suitable, and they do... whatever seemed reasonable to Bill.

You can't provide this for your own type, it's a second class citizen and isn't given the same privileges as Odin's built-in types.

If you're Ginger Bill, Odin is great, it does exactly what you expected and it covers everything you care about but nothing more.

Re: Zig feels more practical than Rust for real-world CLI tools

#322

Post by johncolanduoni »

pron wrote: post #315
johncolanduoni wrote: post #262

Earlier quoted context omitted.

I’m not willing to go to bat for Oberon, but large swaths of software engineering are done with no tradeoff analysis of different technologies at all. Most engineers know one imperative programming language and maybe some SQL. If you ask them what to use, they will simply wax poetic about how the one language they know is the perfect fit for the use-case. Even for teams further toward the right of the bell curve, his…

If a language offered a significant competitive advantage, such an analysis wouldn't be necessary. Someone would capitalise on it, and others would follow. There are selective pressures in software. Contingencies play an outsized role only when the intrinsics don't.

My point is that for most of the software world, selective pressures are much weaker than things like switching costs and ecosystem effects. The activation energy for a new tech stack is massive - so it's very easy to get stuck in local maxima for a long time.

Re: Zig feels more practical than Rust for real-world CLI tools

#323

Post by ajross »

simonask wrote: post #306
ajross wrote: post #195

Earlier quoted context omitted.

> Seasoned Rust coders don’t spend time fighting the borrow checker - their code is already written in a way that just works. That hasn't been my experience at all. At best, the first version of code pops out quickly and cleanly because the author knows the appropriate idiom to choose. Refactoring rust code to handle changes in that allocation idiom is extremely expensive, even for the most seasoned developers. Case…

This is an interesting comment, because you point directly at the exact reason Rust’s approach is so productive. In the C/C++/Zig code, you would add the second concurrent access, and then start fixing things up and restructuring things - if you, the programmer, knew about the first access, and knew that the concurrent access is a problem. In countless cases, that work would not be done, and I cannot blame any of the…

> In the C/C++/Zig code, you would add the second concurrent access, and then start fixing things up and restructuring things

Well, sure, which in practice means throwing a lock around it.

I mean, I get it. There's a category of bugs that happen in real code. Rust chooses some categories of bugs (certainly not all of them) to construct walls around and forces code into idioms that can be provably correct for at least a subset[1] of the bug space. For the case of memory safety, that's a really pretty convincing case. Other areas are less clear; in particular I'm not a fan of Rust's idea of threadsafety and don't think it fits what actually performance-parallel code needs.

[1] You can 100% write racy code with Sync/Send! You can write racy code with boring filesystem access using 100% safe rust (or 1980's csh code, whatever), too. Race conditions are inherent to concurrency. Sync/Send just protect memory access, they do nothing to address semantic/state bugs.

Re: Zig feels more practical than Rust for real-world CLI tools

#324

Post by charcircuit »

mattwilsonn888 wrote: post #319
charcircuit wrote: post #259

Earlier quoted context omitted.

>Safety is less ergonomic. It's not safety that makes it less ergonomic, it's correctness.

Implying that correctness necessitates a lack of ergonomics is deeply flawed. The distinction between correctness and safety is that safety is willing to suffer false positives, in pursuit of correctness. Correctness is just correctness.

It's not flawed. Ergonomics are correlated with complexity. If you can remove edge cases by giving up on correctness you can remove complexity.

Re: Zig feels more practical than Rust for real-world CLI tools

#325

Post by johncolanduoni »

lerno wrote: post #307
quotemstr wrote: post #215

Earlier quoted context omitted.

> The words of every C programmer who created a CVE. Much of Zig's user base seems to be people new to systems programming. Coming from a managed code background, writing native code feels like being a powerful wizard casting fireball everywhere. After you write a few unsafe programs without anything going obviously wrong, you feel invincible. You start to think the people crowing about memory safety are doing it bec…

I can't speak for Zig users, but an interesting alternative to just new/delete or malloc/free and various garbage collection strategies is pervasive use of temp allocation using arenas, such as Jai and Odin's temp allocators (essentially frame allocators) and C3's stack-like temp allocator. Zig also favours using arenas, but more ad hoc. What happens in those cases is that you drop a whole lot of disorganized dynamic…

If you're allocating most things from a set of arenas alive for the same scope, Rust's borrow checker complexity almost entirely fades away. You'll have one lifetime for all inputs and outputs of your functions, so the inferred lifetimes will always be correct. If you have multiple arenas being allocated from with different scopes, you're asking for trouble with the Zig model while the Rust borrow checker will keep which data is from which arena straight.

Re: Zig feels more practical than Rust for real-world CLI tools

#326

Post by steveklabnik »

mattwilsonn888 wrote: post #316
shakow wrote: post #279

Earlier quoted context omitted.

> Rust has slower compile times That's true. > for the sake of safety, That's false though. All deep dives in the topic find that the core issue is the sheer amount of unoptimized IR that is thrown at LLVM, especially due to the pervasive monomorphization of everything.

Well it is arguably Rust's worst issue and it has remained it for most of its life. Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts? How pedantic should we about about it?

Yes. This is borne out by the numbers. It has nothing to do with being pedantic, it’s basic facts.

Re: Zig feels more practical than Rust for real-world CLI tools

#327

Post by Cloudef »

illuminator83 wrote: post #231
Cloudef wrote: post #76

Earlier quoted context omitted.

To be honest, the generated machine code / assembly is often more readable than the actual c++ code in c++ stdlibs. So I can sympathize with the "This printf is more readable than that libfmt stuff." comment :)

Oh, they were not talking about the implementation of these things. Just the the user side: printf("Error: File `%s` in batch %d failed.", file.c_str(), batch) vs fmt::print("Error: File `{}` in batch {} failed.", file, batch) One of which is objectively safer and more portable than the other. They didn't care. "I like what I've been doing for the last 20 years already better because it looks better.". "No Its not be…

Yeah, its frightingly common CI not doing static analysis checks on C/C++ code. The compiler defaults being really bad doesn't help either. The nice thing about zig is that it defaults to "safe" behaviour, and even if you use it as C/C++ compiler it has saner defaults and compiles with ubsan.

You can guide compiler to check printf style format strings using __attribute__((format)) btw, also checks you are not using a variable as a format string

Re: Zig feels more practical than Rust for real-world CLI tools

#328

Post by on_the_beach »

cheshire_cat wrote: post #237
quotemstr wrote: post #218

Earlier quoted context omitted.

> The tradeoff is between performance, safety and ergonomics. With GC languages you lose the first one. That's a myth that just won't die. How is it that people simultaneously believe 1) GC makes a language slow, and 2) Go is fast? Go's also isn't the only safe GC. There are plenty of good options out there. You are unlikely to encounter a performance issue using one of these languages that you could resolve only wit…

Go is fast compared to Python or Ruby. Go is not fast compared to C. I think people that talk about GC'd languages being slow are usually not building Rails or Django apps in their day to day.

Not a Go programmer I'm guessing.

Go can be made to run much faster than C.

Especially when the legacy C code is complex and thus single threaded, Go's fabulous multicore support means you can be exploiting parallelism and finishing jobs faster, with far less effort than it would take to do it in C.

If you measure performance per developer day invested in writing the Go, Go usually wins by a wide margin.

Re: Zig feels more practical than Rust for real-world CLI tools

#329

Post by rixed »

quotemstr wrote: post #252
rixed wrote: post #236

Earlier quoted context omitted.

> How is it that people simultaneously believe > 1) GC makes a language slow, and > 2) Go is fast? Easy one: either not the same people, or people holding self contradicting thoughts. GC are slow not only because of scanning the memory but also because of the boxing. In my experience, 2 to 3 times slower. Still a better tradeoff in the vast majority of cases over manual memory management. A GC is well worth the peace…

> also because of the boxing Not every GC boxes primitives. Most don't.

Sure. What about non primitives?

Re: Zig feels more practical than Rust for real-world CLI tools

#330

Post by quotemstr »

on_the_beach wrote: post #328
cheshire_cat wrote: post #237

Earlier quoted context omitted.

Go is fast compared to Python or Ruby. Go is not fast compared to C. I think people that talk about GC'd languages being slow are usually not building Rails or Django apps in their day to day.

Not a Go programmer I'm guessing. Go can be made to run much faster than C. Especially when the legacy C code is complex and thus single threaded, Go's fabulous multicore support means you can be exploiting parallelism and finishing jobs faster, with far less effort than it would take to do it in C. If you measure performance per developer day invested in writing the Go, Go usually wins by a wide margin.

> Go can be made to run much faster than C.

Not literally the case.

> If you measure performance per developer day invested in writing the Go, Go usually wins by a wide margin.

I can accept that performance/hour-spent is better in Go than C, but that's different from Go's performance ceiling being higher than C's. People often confuse ceilings with effort curves.

Post reply on HN