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

371–380 of 412 posts

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

#371

Post by davemp »

HackerThemAll wrote: post #299

> whereas Zig has good developer ergonomics and allows me to produce memory safe software with a bit of discipline C also allows to produce memory safe software with a bit of discipline. This "bit of discipline" is the issue here which developers are lacking.

There are levels here, Zig addresses:

- out of bounds access (70% of CVEs)

- nullptr dereferences

- type safety issues

That’s massively better than C. Preventing use after free errors requires much less discipline than never missing a boundary or bungling a signed/unsigned conversion.

Zig also has a knock your socks off incredible cross platform build system, empowers some really nice optimizations/ergonomics with comptime, has orders of magnitude faster build times that C++/rust.

Zig is still < v1.0 so standard library could use some work and there are other warts, but I think it will be a great choice for performance oriented programs in the future.

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

#372

Post by pjmlp »

shakow wrote: post #359
pjmlp wrote: post #358

Earlier quoted context omitted.

At the same time, comparing without acknowledging that it is an implemenation issue, it is also not being fully honest. For example, comparing languages with LLVM based implementations, usually if the machine code isn't the same, reveals that they aren't pushing the same LLVM IR down the pipe, and has little value for what the grammar actually looks like.

> comparing without acknowledging that it is an implemenation issue Because that's implicit at this point – I'm not going to prefix with “because Earth geometry is approximately Euclidian at our scale” every time I'm telling a tourist to go straight ahead for 300m to their bus station. Just like when people say “C++ is fast”, of course they refer to clang/g++/msvc, not some educational university compiler.

I seriously doubt it, given how many discussions go on HN or similar sites, revealing a complete lack of knowledge in compiler design.

Of course the authors of many of such comments aren't to blame, they only know what they know, hence why https://xkcd.com/386/

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

#373

Post by dev_l1x_be »

estebank wrote: post #198
dev_l1x_be wrote: post #189

Earlier quoted context omitted.

Maybe I am holding it wrong. Here is one piece of the problem: while let Some(page) = object_stream.next().await { match page { // ListObjectsV2Output Ok(p) => { if let Some(contents) = p.contents { all_objects.extend(contents); } } // SdkError Err(err) => { let raw_response = &err.raw_response(); let service_error = &err.as_service_error(); error!("ListObjectsV2Error: {:?} {:?}", &service_error, &raw_response); retu…

Out of curiosity, why are you borrowing that many times? The following should work: while let Some(page) = object_stream.next().await { match page { // ListObjectsV2Output Ok(p) => { if let Some(contents) = p.contents { all_objects.extend(contents); } } // SdkError Err(err) => { let raw_response = err.raw_response(); let service_error = err.as_service_error(); error!("ListObjectsV2Error: {:?} {:?}", service_error, ra…

Excellent! Thank you!

My problem is that I should have something like

(http_status, reason) where http_status is a String or u16, reason is a enum with SomeError(String) structure. So essentially having a flat meaningful structure instead of this what we currently have. I do not have any mental model about the error structure of the AWS libs or don't even know where to start to create that mental model. As a result I just try to turn everything to a string and return it altogether hoping that the real issue is there somwhere in that structure.

I think the AWS library error handling is way to complex for what it does and one way we could improve that if Rust had a great example of a binary (bin) project that has lets say 2 layers of functions and showing how to organize your error effectively.

Now do this for a lib project. Without this you end up with this hot mess. At least this is how I see it. If you have a suggestion how should I return errors from a util.rs that has s3_list_objects() to my http handler than I would love to hear what you have to say.

Thanks for your suggestions anyway! I am going to re-implement my error handling and see if it gives us more clarity with impl.

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

#374

Post by rixed »

pjmlp wrote: post #346
rixed wrote: post #329

Earlier quoted context omitted.

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.

Impressive erudition and interresting list of nice languages, some of which I'd never heard about, thank you. Yes indeed not all GCed languages suffer from mandatory boxing. I've been both picky and wrong, which is not a nice place to find oneself in :)

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

#375

Post by rixed »

zanellato19 wrote: post #249
rixed wrote: post #230

Earlier quoted context omitted.

> "Just don't write (memory) bugs!" hasn't produced (memory) safe C Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs. Sure, it's easier to write a robust program in almost every other language. But to state that nobody ever produced a memory safe C program is just wrong. Maybe it was j…

>Yes it did, of course. Maybe it takes years of practice, the assistance of tools (there are many, most very good), but it's always been possible to write memory safe large C programs. Can you provide examples for it? Because it honestly doesn't seem like it has ever been done.

I don't understand where you stand. Surely, you don't mean that all C programs have memory bugs. But on my side, I'm not claiming that discipline makes C a memory safe language either. This discussion has taken a weird turn.

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

#376

Post by junon »

player1234 wrote: post #367
junon wrote: post #361

Earlier quoted context omitted.

Writing rust fulltime for my personal projects, I have to disagree that Rust isn't ergonomic. In fact, I find it more ergonomic than any other language I ever work with. I'm consistently more productive with it than even scripting languages. Getting tired of this quip being asserted as fact. Ergonomics are subjective; memory safety is not.

[dead]

How did you measure the assertion that Rust is not ergonomic? Please share your results and methodology.

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

#378

Post by bluGill »

Aurornis wrote: post #200
bluGill wrote: post #126

Earlier quoted context omitted.

Reference counting has always been a way to garbage collect. Those who like garbage collection have always looked down on it because it cannot handle circular references and is typically slower than the mark and sweep garbage collectors they prefer. If you need a referecne counted garbage collector for more than a tiny minotiry of your code, then Rust was probably the wrong choice of language - use something that has…

Reference counting can be used as an input to the garbage collector. However, the difference between Arc and a Garbage Collector is that the Arc does the cleanup at a deterministic point (when the last Arc is dropped) whereas a Garbage Collector is a separate thing that comes along and collects garbage later. > If you need a referecne counted garbage collector for more than a tiny minotiry of your code The purpose of…

> whereas a Garbage Collector is a separate thing that comes along and collects garbage later.

That is the most common implementation, but that is still just an implementation detail. Garbage collectors can run deterministically which is what reference counting does.

> There is no reason to avoid Rust if you have an architecture that requires shared ownership of something.

Rust can be used for anything. However the goals are still something good for system programming. Systems programming implies some compromises which makes Rust not as good a choice for other types of programming. Nothing wrong with using it anyway (and often you have a mix and the overhead of multiple languages makes it worth using one even when another would be better for a small part of the problem)

> I think a lot of new Rust developers are taught that Arc shouldn't be abused, but they internalize it as "Arc is bad and must be avoided", which isn't true.

Arc has a place. However most places where you use it a little design work could eliminate the need. If you don't understand what I'm talking about then "Arch is bad and must be avoided" is better than putting Arc everywhere even though that would work and is less effort in the short run (and for non-systems programming it might even be a good design)

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

#379

Post by YmiYugy »

Zig is pretty neat. Compiles quickly, integrates nicely with C and its sdtlib was designed with explicit allocators in mind. It's a perfectly fine choice for building small CLIs, but many of the criticisms of rust just don't land right of me. Let's go through some slightly exaggerated interpretations of them. 1. Relying on the compiler for memory management makes you a bad programmer: Every skill has its applications, but having a compiler that ensures memory safely (for the most part) changes what is required of a good programmer and being able to safely manage memory by hand is less important. 2. The borrow checker is all or nothing: If you use unsafe or turn your memory bugs into logic bugs by using indexes you do miss out on safety guarantees of the borrow checker, but a) Rust has other compelling features, e.g. pattern matching, parametricity, b) Zig/C safety doesn't hold up better when doing things that require unsafe in Rust, c) the unsafe use and index wrangling can be encapsulated. The rest of your code can use the borrow checker just fine. 3. But safety is more than memory safety: Of course there is. I think this is a bit of a straw man argument, because I don't think that's a common claim the rust community let alone the foundation makes. 4. Rust strongly encourages you to structure your code around the compiler: I think this claim is valid, but I want to dispute that this is such a bad thing. You are probably a log smarter than the compiler. So you need to dumb it down, so the compiler will understand. Code that requires less brain power to understand is usually good. I've had some experiences where the borrow checker guided me to find a nicer structure for my code. The learning curve however is real. It takes a lot of time to build the intuition around the borrow checker and not run head first into it all the time. IMHO for small CLI tools it's fine to clone your way out of a dead end, even if it seems ugly.

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

#380

Post by nextaccountic »

aw1621107 wrote: post #156
mattwilsonn888 wrote: post #104

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. "This chair is guaranteed not to collapse out from under you. It might be a little less comfortable and a little heavier, but most athletic people get used to that and don't even notice!" Let's quote the article: > I’d say as it currently stands Rust has poor deve…

> it's a universal tradeoff, that is: Safety is less ergonomic. I'm not sure that that tradeoff is quite so universal. GC'd languages (or even GC'd implementations like Fil-C) are equally or even more memory-safe than Rust but aren't necessarily any less ergonomic. If anything, it's not an uncommon position that GC'd languages are more ergonomic since they don't forbid some useful patterns that are difficult or impos…

GCed languages aren't (usually) more memory safe than safe Rust because they (usually) lack the equivalent to the Send and Sync traits and thus will not prevent unsynchronized access to the same from multiple threads, including data races. Some languages might define data races to not be UB (at least Java and OCaml do this, but Go famously doesn't), but even in those languages data races may produce garbage data due to tearing (writing to a large struct needs to be done in many steps, and without proper synchronization two concurrent updates may interleave leaving data structures in an inconsistent state)

Guaranteed thread safety is huge. I hope more high level, GC languages use Rust's approach of defining an interface for types that can be safely sent and/or shared across threads

Post reply on HN