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

401–410 of 412 posts

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

#401

Post by vrmiguel »

scoopdewoop wrote: post #260
AlotOfReading wrote: post #212

Earlier quoted context omitted.

The thing I wish we would remember, as developers, is that not all programs need to be so "safe". "Safety" is just a shorthand for "my program means what I say". Unsafety is semantic gibberish. There's lots of reasons to write artistically gibberish code, just as there is with natural language (e.g. Lewis Carroll). Most programs aren't going for code as art though. They're trying to accomplish something definite thro…

> If we could wave a magic wand and make all code safe with no downsides, who among us wouldn't? Anybody would, but Rust is not that wand, and there is no wand. Code needs to _exist_ in order to matter. Time is finite, my free-time is even more limited. Most of my code is garbage collected, and runs great, but if I needed it to be really fast, I would use Zig. I don't need to be told what software is for or how to ac…

> The attitude of Rust being bug-free is _insaaaane_.

Funny, because that's not anywhere close to what the comment you're replying to states.

They said `"Safety" is just a shorthand for "my program means what I say"`. That's a reasonable explanation: the code you wrote is not working exactly as you intended, due to some sort of unknown behavior.

The "bug" you're talking about would be the program doing exactly what you implemented, but what you implemented is wrong. The difference is so obvious that it's hard to think that you're engaging in a good faith argument.

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

#402

Post by timschmidt »

vanderZwan wrote: post #363
tptacek wrote: post #300

Earlier quoted context omitted.

The point of memory-safe languages is to foreclose on a set of particularly nasty bugs, regardless of how frayed engineer morale is.

I'm pretty sure that in an overworked environment the engineers would reach for Rust's unsafe mode pretty quickly because they're too tired to make sense of the borrow checker.

I'm no expert, but I've been hacking in Rust for several years now, and the only unsafe I've written was required as part of building a safe interface over some hardware peripherals. Exactly as intended.

The borrow checker is something new Rust devs struggle with for a couple months, as they learn, then the rules are internalized and the code gets written just like any other language. I think new devs only struggle with the borrow checker because everyone has internalized the C memory model for the last 50 years. In another 50, everyone will be unlearning Rust for whatever replaces it.

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

#403

Post by atonse »

12_throw_away wrote: post #268
hadlock wrote: post #224

Earlier quoted context omitted.

I wrote a physics-accurate flight sim in rust that takes in to account the curvature of the earth and local gravitational fluctuations, it has two tests, one is to fly SFO-Sacramento-Seattle about a 5 hour "flight" at 60 frames per second, the longer one is to fly SFO to Tokyo about 22 hours; it has never once crashed or had a memory leak, it has always worked flawlessly. In 7 years of writing rust I've only ever had…

> I wrote a physics-accurate flight sim in rust Off-topic - that sounds amazing, is this commercial or hobby software? Any way I could learn more about it?

Yeah seriously, I was also intrigued by it!

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

#404

Post by timschmidt »

yen223 wrote: post #254
danudey wrote: post #167

Earlier quoted context omitted.

I have also mostly only dabbled with Rust, and I've come to the conclusion that it is a fantastic language for a lot of things but it is very unforgiving. The optimal way to write Python is to have your code properly structured, but you can just puke a bunch of syntax into a .py file and it'll still run. You can experiment with a file that consists entirely of "print('Hello World')" and go from there. Import a json f…

Someone (Rich Hickey?) described this as a piano that doesn't make a sound until you play the piece perfectly, and that analogy has stuck with me since.

Much preferred over pianos which are making unwanted sounds, unexpected sounds, loud crashing sounds, sounds initiated by sheet music which exploits a flaw in the piano's construction, and can therefore not be depended upon to sound appropriately during important events like concerts.

That said, I'm all the time noodling new small programs in Rust. Cargo and crates.io makes this far simpler than with C/C++ where I have to write some code in another language entirely like [C]Make to get the thing to build. And I find that the borrow checker and rustc's helpful errors create a sort of ladder where all I have to do to get a working program is fix the errors the compiler identifies. And it often tells he how. Once the errors are fixed one by one, which is easy enough, and the software builds, my experience is that I get the expected program behavior about 95% of the time. I cannot say the same for other languages.

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

#405

Post by spoiler »

mattwilsonn888 wrote: post #104
simonask wrote: post #21

The benefit of Zig seems to be that it allows you to keep thinking like a C programmer. That may be great, but to a certain extent it’s also just a question of habit. Seasoned Rust coders don’t spend time fighting the borrow checker - their code is already written in a way that just works. Once you’ve been using Rust for a while, you don’t have to “restructure” your code to please the borrow checker, because you’ve a…

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…

I find Rust more ergonomic than something like C or C++, or even Go.

I feel unburdened while using Rust, which is not something I can say about a lot of other dev environments.

As for Zig... I tried to get into it, and I can't remember the specifics, but they felt like "poor" taste in language design (I have a similar opinion of Go). I say taste because I think some thighs weren't necessarily bad, but I just couldn't convince myself to like them. I realise this is a very minority opinion, and I know great engineers who love Zig.

Zig's just not my thing I guess. Same way Rust isn't someone else's thing.

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

#406

Post by swiftcoder »

ChadNauseam wrote: post #98
swiftcoder wrote: post #45

Earlier quoted context omitted.

I don't think there are any Arcs in my codebase (apart from a couple of regrettable ones needed to interface with Javascript callbacks in WASM - this is more a WASM problem than a rust problem).

haha, I was about to leave the exact same comment. how are you finding wasm? I’ve been feeling like rust+react is my new favorite tech stack

I love it, but I'm mainly using it for webgl/webgpu stuff, so relatively little interaction with the DOM - I feel like DOM interaction is still kind of painful through rust/wasm

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

#407

Post by Voultapher »

Karrot_Kream wrote: post #397
Voultapher wrote: post #339

Earlier quoted context omitted.

I'm not sure how showing that gp can't even write a dozen lines of memory safe C proves that doing so for the exponentially harder 100+k LoC projects is feasible. The program contains potential use of uninitialized memory UB, because scanf error return is not checked and num1 and num2 are not default initialized. And a + b can invoke signed integer overflow UB. A program with more than zero UB cannot be considered me…

> num1 and num2 are not default initialized num1 and num2 are declared on the stack and not the heap. The lifetimes of the variables are scoped to the function and so they are initialized. Their actual values are implementation-specific ("undefined behavior") but there is no uninitialized memory. > And a + b can invoke signed integer overflow UB. A program with more than zero UB cannot be considered memory safe. No,…

Regarding initialization, if one wants portable code that works for more than one machine+compiler version, it's advisable to program against the C++ virtual machine specified in the standard. This virtual machine does not contain a stack or heap.

Generally your comment strikes me as assuming that UB is some kind of error. In practice UB is more a promise the programmer made to never do certain things, allowing the compiler to assume that these things never happen.

How UB manifests is undefined. A program that has more than zero UB cannot be assumed to be memory safe because we can't make any general assumptions about its behavior because. UB is not specified to be localized it can manifest in any way, rendering all assumptions about the program moot. In practice when focusing on specific compilers and machines we can make reasonable localized assumptions, but these are always subject to change with every new compiler version.

Memory safety is certainly critical when it comes to exploits, but even in a setting without adversaries it's absolutely crucial for reliability and portability.

> In fact Rust also silently allows signed integer overflow.

Silently for release builds, and panic in debug builds. The behavior is implementation defined and not undefined, in practice this is a subtle but crucial difference.

Take this example https://cpp.godbolt.org/z/58hnsM3Ge the only kind of UB AFAIKT is signed integer overflow, and yet we get an out-of-bounds access. If instead the behavior was implementation defined the check for overflow would not have been elided.

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

#408

Post by naikrovek »

capitol_ wrote: post #85
naikrovek wrote: post #31

Earlier quoted context omitted.

are you saying that such understanding isn't enough or that every C programmer who said that didn't understand those things? C and Zig aren't the same. I would wager that syntax differences between languages can help you see things in one language that are much harder to see in another. I'm not saying that Zig or C are good or bad for this, or that one is better than the other in terms of the ease of seeing memory pr…

Just understanding the rules are not enough, you also need to be consistently good so that you never make a mistake that gets into production. On both your average days and your bad days. Over the 40 to 50 years that your carer lasts. I guess those kind of developers exist, but I know that I'm not one of them.

I am pretty confident that a language with syntax that allows you to feel that freedom that C gives you AND is safe to write software with (without garbage collection) is possible, we just need to come up with a reasonable syntax that has both of those features. It won't look like C or Go or any of that, I don't think.

I am not a computer scientist (I have no degree in CS) but it sure seems like it would be possible to determine statically if a reference could be misused in code as written without requiring that you be the Rust Borrow Checker, if the language was designed with those kinds of things from the beginning.

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

#409

Post by godshatter »

NielsAndersen67 wrote: post #274

I have been writing Rust code for 3.5 years. I never fight the borrow checker. The ownership rules are a blessing, when ever the compiler yells at me, then I know I am doing something that would have caused a seg fault i. C. It took a little while to get used to Rusts syntax, but once I got it, it was the best programming language I have ever used. It is just so beautiful how it enables multi threading and ensures th…

I'm a C programmer who has tried to move to other languages, but I keep coming back to C for a few different reasons. It's a small language and I can keep it in my head along with much of the standard library and that's very useful. I've learned where to step to avoid most of the UB pitfalls and I've learned to simplify memory management as much as possible to avoid lifetime and ownership pitfalls. I do realize that this doesn't get rid of bugs completely, though.

Also, I started programming on a TRS-80 color computer with cassette tape storage and it still feels crazy to just do stuff and it allocates somewher and you have little control over what happens and some other process runs in the background that tries to clean up after you. I bounce off of languages (for hobby projects) with such a large list of features and with executable sizes that are so huge. I can't help it.

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

#410

Post by [deleted] »

12_throw_away wrote: post #268
hadlock wrote: post #224

Earlier quoted context omitted.

I wrote a physics-accurate flight sim in rust that takes in to account the curvature of the earth and local gravitational fluctuations, it has two tests, one is to fly SFO-Sacramento-Seattle about a 5 hour "flight" at 60 frames per second, the longer one is to fly SFO to Tokyo about 22 hours; it has never once crashed or had a memory leak, it has always worked flawlessly. In 7 years of writing rust I've only ever had…

> I wrote a physics-accurate flight sim in rust Off-topic - that sounds amazing, is this commercial or hobby software? Any way I could learn more about it?

[deleted]
Post reply on HN