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

331–340 of 412 posts

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

#331

Post by bionhoward »

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…

Rust feels easy for me, could it be we’re just used to what we use more?

Anyway, it’s all pretty easy, what’s the use arguing which of multiple easy things is easiest?

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

#332

Post by mackeye »

seabrookmx wrote: post #173
GardenLetter27 wrote: post #161

Nope, rust-analyzer is incredible whereas the Zig LSP felt worse than Go. I agree the borrow checker can be a pain though, I wish there were something like Rust with a great GC. Go has loads of other bad design decisions (err != nil, etc.) and Cargo is fantastic.

Syntactically speaking, Gleam fits the bill. It's very new/immature though and isn't in the same performance bracket since it runs on the BEAM.

how is its startup time? ive wanted to learn it or ocaml for a while and might take the plunge

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

#333

Post by pjmlp »

lerno wrote: post #304
pjmlp wrote: post #160

Earlier quoted context omitted.

Ideally neither Zig nor Rust would matter. Languages like Modula-3 or Oberon would have taken over the world of systems programming. Unfortunately there are too many non-believers for systems programming languages with automatic resource management to take off as they should. Despite everything, kudos to Apple for pushing Swift no matter what, as it seems to be only way for adoption.

Unfortunately Swift is a mess of a language, trying to put as many language features in there as possible. While still not getting close to being a good replacement for Objective-C. AND it's the slowest language to compile among languages with a substantial adoption. It's just pig-headedness by Apple, nothing more.

I agree with the toolchain problems, the rest we don't need another Go flavour, with its boilerplate and anti language research culture.

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

#334

Post by seabrookmx »

mackeye wrote: post #332
seabrookmx wrote: post #173

Earlier quoted context omitted.

Syntactically speaking, Gleam fits the bill. It's very new/immature though and isn't in the same performance bracket since it runs on the BEAM.

how is its startup time? ive wanted to learn it or ocaml for a while and might take the plunge

I only wrote some toy programs in it, and it didn't jump out to me as an issue. I don't have any real data for you though, sorry!

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

#335

Post by oconnor663 »

anon-3988 wrote: post #112
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…

I would argue that good C or C++ code is actually just Rust code with extra steps. So in this sense, Rust gets you to the "desired result" much easier compared to using C or C++ because no one is there to enforce anything and make you do it. You can argue that using C or C++ can get you to 80% of the way but most people don't actively think "okay, how do I REALLY mess up this program?" and fix all the various invaria…

I think "writing Rust in C++" so to speak means at least two distinctly different things, which are both important. The first thing is that, as an individual programmer, you're being disciplined with memory and thinking about who owns what. The second thing is that as a group of programmers (over time), you all agree about who owns what. There are a lot of ways to learn the first thing, but I'm not sure there are a lot of ways to accomplish the second thing in a large system.

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

#336

Post by oconnor663 »

9rx wrote: post #82
kibwen wrote: post #67

Earlier quoted context omitted.

> _seasoned_ Rust developers just sprinkle `Arc` all over the place No, this couldn't be further from the truth.

If they aren't sprinkling `Arc` all over, what are they seasoning with instead?

Indexes: https://jacko.io/object_soup.html

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

#337

Post by purplesyringa »

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?

It's not about static contracts at all, it's about keeping performance of high-level APIs high. It's all just about templates and generics, as far as I'm aware -- the same problem that plagues C++, except that it's worse in Rust because it's more ergonomic to expose templates in public library APIs in Rust than C++. Well, and also the trait solver might be quite slow, but again, it has nothing to do with memory safety.

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

#338

Post by shakow »

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?

> Are you really going to try and convince people that this is completely incidental and not a result of pursuing its robust static contracts?

I am, because that's what all the people that explored the question converged on.

Now if you have other evidences to bring to the debate, feel free to – otherwise, please stop spreading FUD and/or incompetence.

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

#339

Post by Voultapher »

Karrot_Kream wrote: post #298
hannofcart wrote: post #264

Earlier quoted context omitted.

Haven't written C in a while but I think this program has an integer overflow error when you input 2 really large integers such that the sum is more than a 32 bit signed integer. Also I believe in entering null values will lead to undefined behaviour.

Memory safe doesn't mean protection from integer overflow unless you use that integer to index into some array. I'm not sure how you'd enter NULL given scanf.

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 memory safe.

For example if the program runs in a context where stdin can't be read scanf will return error codes and leave the memory uninitialized.

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

#340

Post by aw1621107 »

mattwilsonn888 wrote: post #318
aw1621107 wrote: post #310

Earlier quoted context omitted.

> Under the assumption that you are maximizing both. I'm not sure that changes anything about my comment? GC'd languages can give you safety and* ergonomics, no need to trade off one for the other. Obviously doing so requires tradeoffs of their own, but such additional criteria were not mentioned in the comment I originally replied to. > I often hear complaints that Rust's semantics actually haven't maximized ergonom…

Your earlier point that languages exist that are safer than Rust but not less ergonomic is irrelevant - that's the point I made. One can fail, or artificially make a language less ergonomic and that doesn't mean that fixing that somehow has an effect on the safety tradeoff. So obviously it is when safety and ergonomics are each already maximized that pushing one or the other results in a tradeoff. It's like saying re…

> that's the point I made.

That's not the way I read your original comment. When you said "it's a universal tradeoff, that is: Safety is less ergonomic", to me the implication is that gaining safety must result in losing ergonomics and vice versa. The existence of languages that are as safe/safer than Rust and more ergonomic than Rust would seem to be a natural counterexample since they have gained safety over Zig/C/C++ and haven't (necessarily, depending on the exact language) sacrificed ergonomics to do so.

> One can fail, or artificially make a language less ergonomic and that doesn't mean that fixing that somehow has an effect on the safety tradeoff.

To be honest that case didn't even cross my mind when I wrote my original comment. I was assuming we were working at the appropriate Pareto frontier.

> So obviously it is when safety and ergonomics are each already maximized that pushing one or the other results in a tradeoff.

Assuming no other relevant axes are available, sure.

> Anyways I was holding performance constant in all of this because the underlying assumption of Rust and Zig and Odin and C is that performance will make no sacrifices.

Sure. Might have been nice to include that assumption in your original comment, but even then I'm not sure it's too wise to ignore the performance axis completely due to the existence of safe implementations of otherwise "unsafe" languages (e.g., Zig's ReleaseSafe, GCs for C like Fil-C, etc.) that trade off performance for safety instead of ergonomics.

Post reply on HN