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

341–350 of 412 posts

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

#341

Post by bryal »

khuey wrote: post #136
andrewl-hn wrote: post #75

Earlier quoted context omitted.

`Arc`s show up all over the place specifically in async code that targets Tokio runtime running in multithreaded mode. Mostly this is because `tokio::spawn` requires `Future`s to be `Send + 'static`, and this function is a building block of most libraries and frameworks built on top of Tokio. If you use Rust for web server backend code then yes, you see `Arc`s everywhere. Otherwise their use is pretty rare, even in l…

> `Arc`s show up all over the place specifically in async code that targets Tokio runtime running in multithreaded mode. Mostly this is because `tokio::spawn` requires `Future`s to be `Send + 'static`, and this function is a building block of most libraries and frameworks built on top of Tokio. To some extent this is unavoidable. Non-'static lifetimes correspond (roughly) to a location on the program stack. Since a F…

Non-tokio runtimes manage just fine without all of those bounds for local, single-threaded execution though.

https://docs.rs/smol/latest/smol/fn.block_on.html

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

#342

Post by simonask »

ajross wrote: post #323
simonask wrote: post #306

Earlier quoted context omitted.

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…

This is true out of the box - Rust isn't magical, and it can't fix all your bugs for you. But it does make its own tools available to you, an API designer. Lifetimes are available to you without ever making any actual references, and the Send/Sync traits are available to you without constructing any standard synchronization mechanism.

You can construct something like `PhantomData` to express invariants like "while this type exists, these other operations are unavailable". You can implement Send and/or Sync to say things like "under these specific conditions, this thing is thread safe". These are really powerful features of the type system, and no other mainstream language can really express such invariants at compile time.

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

#343

Post by pjmlp »

tptacek wrote: post #157
jasonpeacock wrote: post #108

Earlier quoted context omitted.

> produce memory safe software with a bit of discipline "a bit of discipline" is doing a lot of work here. "Just don't write (memory) bugs!" hasn't produced (memory) safe C, and they've been trying for 50yrs. The best practices have been to bolt on analyzers and strict "best practice" standards to enforce what should be part of the language. You're either writing in Rust, or you're writing in something else + using e…

I actively dislike Zig's memory safety story, but this isn't a real argument until you can start showing real vulnerabilities --- not models --- that exploit the gap in rigor between the two languages. Both Zig and Rust are a step function in safety past C; it is not a given that Rust is that from Zig, or that that next step matters in practice the way the one from C does.

Modula-2 was already a step function in safety past C, but people did not care because it wasn't given away alongside UNIX.

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

#344

Post by pjmlp »

mattwilsonn888 wrote: post #178
rowanG077 wrote: post #152

Earlier quoted context omitted.

It is a helmet. But at least it's a helmet in situations where you get into brain cracking accidents multiple times a day. In the end the helmet allows you to get back up and continue your journey compared to when you had no helmet.

We're talking about Zig not C. Same argument will apply to Odin. These modern approaches are not languages that result in constant memory-safety issues like you imply.

Modern as in 1978 and Modula-2 was just made available.

Or better yet, modern as 1961 Burroughs released ESPOL/NEWP and C was a decade away to be invented.

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

#345

Post by pjmlp »

shakow wrote: post #282
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 not fast though. It's plenty fast compared to commonly used languages such as JS, PHP or Python, but can easily be let in the dust by Java and C#, which arguably play in the same court. And AOT-compiled, no GC languages like C++, Rust or Zig just run circles around it.

Not quite true if using GCC Go as compiler, however they seem to have dropped development after Go got generics.

You are comparing quality of implementation, not languages.

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

#346

Post by pjmlp »

rixed wrote: post #329
quotemstr wrote: post #252

Earlier quoted context omitted.

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

Sure. What about non primitives?

CLU, Cedar, Modula-2+, Modula-3, Oberon, Oberon-2, Oberon-07, Active Oberon, Component Pascal, Eiffel, Sather, BETA, D, Nim, Swift, C#, F# are all examples of GC based languages with value types that can be used without any kind of boxing.

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

#347

Post by simonask »

lerno wrote: post #301

I find some of Rust dev reactions to this article pretty embarrassing. As if memory safety was some holy grail only provided by Rust. Here is a bunch of more memory safe languages that are more popular than Rust: Python, Java, JS ... should I continue? But wait, there's more. Can Rust verify that arbitrary in-data is valid, like having contracts statically checked at compile time? It can't, and so then by the same lo…

The point about "gibberish" is getting at a fundamental misunderstanding that people have about Undefined Behavior.

Rust's concept of "safety" really means "absence of Undefined Behavior". Lots of people don't seem to understand that C, C++, and Zig programs containing UB are gibberish - they are not C, C++, or Zig programs, but something else entirely. The key insight here is that in any language, UB invalidates the entire program. It no longer does what you think it does, your tests are all moot, and so on. But a lot of people seem to think that there is an acceptable amount of UB in any code base. There isn't.

UB is a concept that exists for every language, even languages like Python, Java, C#, JavaScript, but those languages make it very hard to encounter accidentally.

Before Rust, there was no way to guarantee the absence of UB without a significant runtime cost, so that's a very meaningful invention.

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

#348

Post by pjmlp »

simonask wrote: post #302
Arnavion wrote: post #122

Earlier quoted context omitted.

>Garbage collection generally refers to more complex systems that periodically identify and free unused objects in a less deterministic manner. No, this is a subset of garbage collection called tracing garbage collection. "Garbage collection" absolutely includes refcounting.

There’s just no good reason to conflate the two. Rust’s Arc and C++’s std::shared_ptr do not reclaim reference cycles, so you can call it “garbage collection” if you want, but the colloquial understanding is way more useful.

The coloquial term is like people arguing about coaching a footbal team without making it into the field.

Chapter 5, https://gchandbook.org/contents.html

Other CS quality references can be provided with similar table of contents.

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

#349

Post by pjmlp »

nmilo wrote: post #170

I don't know why anyone would write CLI tools in rust or zig. I/O is going to be your bottleneck way more often than GC, in fact I don't really get the GC hate outside of game dev, databases and other memory intensive applications. Why not use Go, Python, etc? People try to make a false dichotomy between memory safety vs. non-memory safety when really it's GC vs. no GC --- memory safety without it is going to be hard…

It is basically cargo cult, whole graphical workstations have been built with GC based languages 50 years ago.

- Interlisp => https://interlisp.org/

- Cedar => https://www.youtube.com/watch?v=z_dt7NG38V4

Imagine what we could have today with hardware that is mostly busy running Electron crap and CLI tools from the 1970s.

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

#350

Post by pjmlp »

astrange wrote: post #202
nmilo wrote: post #170

I don't know why anyone would write CLI tools in rust or zig. I/O is going to be your bottleneck way more often than GC, in fact I don't really get the GC hate outside of game dev, databases and other memory intensive applications. Why not use Go, Python, etc? People try to make a false dichotomy between memory safety vs. non-memory safety when really it's GC vs. no GC --- memory safety without it is going to be hard…

> in fact I don't really get the GC hate outside of game dev Most mobile games are implemented in a system with GC (Unity with il2cpp), and it's not even a /good/ GC, it's Boehm.

And if not, they are probably written in a mix of Koltin/Java/NDK, or Objective-C/Swift with ARC (chapter 5, https://gchandbook.org/contents.html).
Post reply on HN