Live data from Hacker News

Was Rust Worth It?

jsoverson.medium.com

601–610 of 736 posts

Re: Was Rust Worth It?

#601
post #494

Earlier quoted context omitted.

It doesn't. The ecosystem is very immature and even the official tooling is very unstable. It has a bunch of interesting design ideas but at this point it's more of an experimental language than a production ready one by most metrics. (And unless it finds some kind of corporate backing, this is unlikely to ever change).

We shipped a few web apps backed by zig. It is absolutely in production.

Just because you put it in production does not mean it's production ready.

Re: Was Rust Worth It?

#602
post #372

Earlier quoted context omitted.

Depending on what seamlessly means, Rust can also interop with C libraries. I wrapped a bunch of them.

Truly seamless because the zig compiler is also a C compiler, so the type information and calling convention works across languages at a level above any other I've encountered.

It's also an unfinished language. I agree Zig is promising, but it's not confidence inspiring when the creator is still making videos debugging the compiler.

Re: Was Rust Worth It?

#603
post #487

Earlier quoted context omitted.

I agree. I feel far more productive in C and C++ than in Rust at that point. Rust feels like totally missing the sweet spot for me. It's way too pedantic about low level stuff for writing higher level applications, but way too complicated for embedded or writing an OS. In the former case I would rather take a C++, Java, Haskell, OCaml or even Go, and maybe sprinkle some C, and in the latter case C in macroassembly mo…

The problem with C and to C++ is that it’s 2023 and the CVE list is still loaded with basic memory errors. These come from everywhere too: small companies and open source all the way up to Apple, Microsoft, and Google. We as a profession have proven that we can’t write unsafe code at scale and avoid these problems. You might be able to in hand whittled code you write but what happens when other people work on it, it…

These are two issues, which a theoretically orthogonal but in practice not so much. These are known as soundness and completeness. A good talk on topic [1]

Rust will reject a lot of sound programs, and that's a huge performance hit. You are hitting the incompleteness wall with multiple mutable borrowing, closures in structures are a huge source of pain as well. And usually the answer from the community is "use handlers instead of pointers", but this gives you, surprise surprise, manual resource management alike that in C, and the compiler won't help much.

Of course this is all subjective but for me the ergonomics of Rust is far too bad. It's a good step in right direction along with ATS, but I really hope we could do better than this.

[1] https://www.youtube.com/watch?v=iSmkqocn0oQ

Re: Was Rust Worth It?

#604

> I am a massive proponent of test-driven development. I got used to testing in languages like Java and JavaScript. I started writing tests in Rust as I would in any other language but found that I was writing tests couldn’t fail. Once you get to the point where your tests can run – that is, where your Rust code compiles – Rust has accounted for so many errors that many common test cases become irrelevant. I wonder w…

When writing in loosely typed languages, some folks aim for 100% line coverage, to make it more feasible to refactor down the line. Which then of course ends up being a lot of tests for fairly basic stuff that the type system could help you with...

line coverage but also branch coverage. Every safe navigation operator used in "defensive" coding, ex. `foo?.bar` is actually another branch that needs to be covered if that's the metric people are using. All of those tests are unnecessary in a language where the type is known at compile-time.

Re: Was Rust Worth It?

#605
post #585

Earlier quoted context omitted.

That's the entire point we're making. Rust's type system forces you to deal with the problem early on and saves time towards the end. It's not like that's impossible with Python with addons like mypy. But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python.

> Rust's type system forces you to deal with the problem early on and saves time towards the end. It's not like that's impossible with Python with addons like mypy. Definitely not - mypy's pretty good these days, and lots of people use it. > But Rust's type system goes beyond just data types - lifetimes are also a part of the type system. I don't know how you can tack that on to Python. Well, Python's objects are gen…

[deleted]

Re: Was Rust Worth It?

#606
post #462

Earlier quoted context omitted.

How do you do anything dynamic/cyclic? Like, graphs that need to be updated in runtime?

My experience is that most programs dealing with ordinary problems don't need such complicated data structures. In cases you do, Rust has a few options: 1. Use Rust's runtime safety checks, using Rc, Weak, RefCell, etc. It will be as ergonomic as GC'ed languages (no productivity loss). While this has a runtime performance penalty, it will still be mostly comparable to other languages. This works for most use cases. 2…

1. Option 1 quickly degrades into unrefactorable mess of TypedArenas, nested Rc>, lifetime annotations everywhere, and the like. It is unmanageable, which is why even libraries like PetGraph do not use it.

2. No, I don't need every last bit of performance. C++ performance is OK. Or any other sane language like Nim, Crystal, etc. I need async, though, which is yet another hell in Rust.

3. This absolutely can't be done with standard library. There are libraries like PetGraph, which solve this particular problem (by some very unobvious approaches and bits of unsafe code), but there are many problems like it which don't have any libraries for it yet.

I do have hard problems. I want a language which makes hard problems easy, and impossible problems hard. Rust is definitely _not_ such a language, and it makes me like 5 times less productive, and sucks all joy out of programming.

Re: Was Rust Worth It?

#607

Earlier quoted context omitted.

How do you do anything dynamic/cyclic? Like, graphs that need to be updated in runtime?

Use one of the many libraries that have safe abstractions over unsafe code? I don't know why people think you need to roll your own? I guess that's just what people do in c/c++, doesn't seem very productive... https://docs.rs/petgraph/latest/petgraph/

There are definitely no less libraries for C++. I am a scientific software engineer, and occasionally I do develop new things. And Rust makes writing new system-level software way harder, which I don't understand, as it is a system-level language.

Re: Was Rust Worth It?

#608

Earlier quoted context omitted.

80% of crates have no unsafe code in them.

I'm interested in what went into this number. I checked the six most recently published crates on crates.io (blablabla, nutp, tord, g2d, testpublishtesttest, hellochi, at the time of writing). Three of those (blablabla, testpublishtesttest, and hellochi) did some variation on printing `hello world`. g2d seems like an interesting graphics library. tord provides a data structure for transitive relations, which is also…

Instead of looking at the crates themselves, you might want to check your (or others') Rust application with https://github.com/rust-secure-code/cargo-geiger to get a sense of effective prevalence. I also dispute that the presence of unsafe somewhere in the dependency tree is an issue in itself, but that's a different discussion that many more had in other sub-threads.

Re: Was Rust Worth It?

#609
post #326

Earlier quoted context omitted.

80% of crates have no unsafe code in them.

I wonder what the ratio of utilization of that 80% is compared to the 20% that do have `unsafe` all over the place.

Note that a crate having any unsafe and having unsafe all over the place are two different things.

Re: Was Rust Worth It?

#610

The clippy bit is a little confusing: > It also looks like (soon) you’ll finally be able to configure global lints for a project. Until now, you had to hack your solution to keep lints consistent for projects. In Wick, we use a script to automatically update inline lint configurations for a few dozen crates. It's trivial to configure global lints per crate . The author's problem comes down to having multiple crates p…

I believe procedural macros always need to be defined in a separate crate, so at least all projects that use procedural macros will have multiple crates

Still, that's two global configurations to manage, where the original wording was easy to misunderstand as "you have to override linter warnings at every single line where they occur"
Post reply on HN