Live data from Hacker News

Why Rust?

rerun.io

31–40 of 294 posts

Re: Why Rust?

#31

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years. C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. Rust code, on the other hand, often doesn't l…

> Too bad most of the Rust jobs right now seem to be in crypto.

What is the problem with that?

Re: Why Rust?

#32
post #12

> Rust's enums and exhaustive match statement are just amazing ADTs + pattern matching are the killer feature set that makes the more popular functional languages so damn pleasant to use, and they're starting to spread to more and more languages. I suspect that, 50 years from now, we'll look back and see them as the key paradigm shift of this era.

Pity that it took people 50 years to discover them.

Re: Why Rust?

#33

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years. C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. Rust code, on the other hand, often doesn't l…

> C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through.

I wonder why, doing Windows programming with OWL in 1993 was quite delightful, or Mac with AppToolbox/PowerPlant,...

Yes there is always C stuff coming throught the cracks, but I see similar aproaches with Rust code making use of unsafe when there are safe alternatives.

Re: Why Rust?

#34
post #4

Earlier quoted context omitted.

> dynamic lifetimes What do you mean ? If you refer to heap allocations, then you can use Box, Arc, Rc. They are not a "garbage collector" nor do they incur performance hits other than a regular heap allocation.

Reference counting is much slower than 'garbage collection'.

Technically yes, but if you only use it when you need it, it's often not a performance concideration.

And for systems programming, the often overlooked truth is that people care far less about perfect performance than they do about control - ref counting doesn't give up control to a mysterious oracle running in the background which may or may not wreck your performance in hard to predict ways, it just pays a known cost at the time you use it based on how you're using it. (that's not to say performance is irrelevant, but it's not always the top concern, and with control you can always rewrite slow code as needed).

The obvious question is "why can't we have an optional modern garbage collector built into a systems language?", and it's a good question (I remember reading there was one in rust for a while during early development, but it got removed), I think the main reason is that high quality garbage collectors are incredibly complicated, with many trade offs, and a gc that combines well with the rest of a language and various alternative memory tracking solutions is harder than most. The projects that really want one can always implement their own and choose their own tradeoffs, so there's not many use-cases where a generic language-provided one would justify the complexity of implementing it within the language.

Re: Why Rust?

#35
post #31

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years. C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. Rust code, on the other hand, often doesn't l…

> Too bad most of the Rust jobs right now seem to be in crypto. What is the problem with that?

I imagine if you're not a cryptographer, you don't have a chance getting those jobs.

Re: Why Rust?

#36
As someone who's not the biggest fan of Rust because of its complexity. There is a big reason to use it today. If you need to use something that has safety guarantees where it's possible to achieve acceptable performance in certain classes of programs where languages like golang, nim or crystal have trouble achieving then I just don't see any other options out there certainly not one with as many libraries available as rust.

Maybe I can use a combination like c and lua to get the right trade offs between safety and performance in the necessary parts of my program but I'm not that confident that I can reach either safety or acceptable performance doing that.

Maybe, I could use C and some kind of static analyzer to find all of my memory bugs. Again, I'm not confident I would succeed there. I might also need a fuzzer to do it. At this point I'm trading a complicated language for a easy fast language with extra complicated operations that may or may not give me the outcome of memory safety.

Re: Why Rust?

#37
post #31

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years. C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. Rust code, on the other hand, often doesn't l…

> Too bad most of the Rust jobs right now seem to be in crypto. What is the problem with that?

It's a bubble, 99/100 crypto companies are going to crash and burn, or already have. If you manage to land on the 1/100 that actually does something useful and survives, well, better odds than the lottery I suppose.

Re: Why Rust?

#38
post #3

> Safety and speed One thing I can't seem to find a quick answer to from the Rust crowed is how does Rust handle dynamic lifetimes? It seems like it does not; it simply prevents you from referring to objects that have a dynamic lifetime not known at compile time. You either have to use 'unsafe' or use the 'handles' pattern where you have what amounts to a custom allocator but the compiler does not know that it's an a…

I think you've covered all the major options:

- Use Rc (or Arc if you need to be thread-safe)

- Use a Vec, slotmap, or a similar data-structure and store handles (indexes). This doesn't entirely prevent use-after-free bugs. But it does tend to make them panics rather than silent errors.

- Use unsafe (and ideally create your own higher-level safe abstraction)

In theory, there should also be 4:

- Use a GC library

But I haven't seen a good implementation of this yet.

---

If you're missing something, it's perhaps that most lifetimes aren't dynamic. So you get all the benefits of Rust's ownership in the 80% case. And in the 20% case you don't get any particular benefits, but you still have all the same options available to you as in other languages.

Re: Why Rust?

#39
post #6

Earlier quoted context omitted.

They seem pretty universal to me. For example, the tedious error handling in Go that is mentioned is a turn-off to a lot of developers. Safety and speed are both things most languages strive for, and if Rust is not THE fastest or THE safest language, it’s on the efficient frontier of the two.

Quoted post unavailable.

In which way is that incorrect? How can you, when reading Python code, know whether it may error?

Or is your point that Rust code can panic too, without it being clear from reading the code?

Re: Why Rust?

#40
post #31

I've started working in Rust too and I too find it a tremendous breath of fresh air. It's the first time I've been excited about a new programming language in many years. C++ promised to be a language that was both high performance and very expressive but I always found it very difficult to work at a high level of abstraction in C++. The sharp details always stab through. Rust code, on the other hand, often doesn't l…

> Too bad most of the Rust jobs right now seem to be in crypto. What is the problem with that?

Potential criminal liability and resume stench. Would you hire ex scammer/ponzi to maintain your backend? I wouldn't.
Post reply on HN