Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust is for Professionals

gregoryszorc.com

Post reply on HN
Print view View original

61–70 of 157 posts

Re: Rust is for Professionals

#61

Post by gte525u »

kzhukov wrote: post #41
skohan wrote: post #17

Rust is currently my favorite language for personal projects. It's got a very good value proposition in terms of giving some high level features along with low level control and performance, great compatibility story, and the tooling and community is absolutely great. However , as the manager of a technical team, I would not choose it for professional projects. The learning curve is very steep, and to reap the benefi…

> safety-critical applications Nope, Rust is also not suitable for these tasks since it doesn't have a certified toolchain (e.g. ISO26262 for automotive or DO-178 for aerospace). > embedded Current LLVM-based compiler lacks support for some platforms (e.g. Xtensa for some ESP32 MCUs).

Certified toolchains only factor into play in DAL A for DO178. Either that or manually inspecting the compiler output and tracing it to the source.

Re: Rust is for Professionals

#62

Post by ajross »

sanxiyn wrote: post #46
ajross wrote: post #29

Earlier quoted context omitted.

That's where I always end up when I start playing with Rust too. At this point I genuinely think I've given up on belief that the "borrow checker" paradigm is ever really going to be broadly successful (vs. "screw it, just do it in "). Problems with well-constrained allocation paradigms do really well in rust. Problems with reading/parsing/storing messy data structures from external data just really, really hurt . I…

No, borrow checker's formal rules are rather simple. Here it is: It is an error to access a place, when an access conflicts with a loan, and the loan is live.

You're describing the desired behavior of the compiler, but not what it actually implements.

In fact there are an infinite number of correct Rust programs which will never access memory incorrectly but which will still be rejected by the compiler, for the simple reason that Rust's authors, talented though they may be, have made no progress at all at solving the Halting Problem.

What Rust actually accepts is a subset of correct programs. And this subset is somewhat informally defined as "whatever the compiler could manage to prove". Real code hits against this limit occasionally, and when it does there's really no option other than "join the Rust team" or "try voodoo".

Re: Rust is for Professionals

#63

Post by sylvain_kerkour »

skohan wrote: post #17

Rust is currently my favorite language for personal projects. It's got a very good value proposition in terms of giving some high level features along with low level control and performance, great compatibility story, and the tooling and community is absolutely great. However , as the manager of a technical team, I would not choose it for professional projects. The learning curve is very steep, and to reap the benefi…

As an indie developer, switching from Go to Rust for web APIs was extremely satisfying. At first there was a productivity loss, but after a few months the productivity was better than Go thanks to Rust's functional features which make it extremely pleasant to write business logic, and the type system catching bugs during development instead of production.

You can read more about the experience here: https://kerkour.com/blog/rust-for-web-development-2-years-la...

The only thing I'm missing is Go's awesome TLS support (with autocert & co).

That being said, I understand your point regarding hiring: a friend of mine totally refuses to learn Rust because the syntax looks not good to him.

Re: Rust is for Professionals

#64

Post by rhn_mk1 »

mnd999 wrote: post #20

I skimmed it, but I think what the author is getting at is that rust demands rigour. The kind of rigour required when failure is a problem and this tends to be the kind of code people get paid to write. I guess the reverse is also true, if you’re writing the kind of code where failure doesn’t matter (e.g. spikes, experimentation, just messing about) perhaps rust isn’t the best choice.

Perhaps there are better choices than Rust when failure doesn't matter, but Rust is still good at some of those.

As an example, the rigour of strong typing helps set some experiments on the right track.

Re: Rust is for Professionals

#65

Post by estebank »

ahelwer wrote: post #39
sanxiyn wrote: post #26

Earlier quoted context omitted.

You can't learn Rust by StackOverflow, that just doesn't work. It is well known, I repeat this everytime I see it happening, and they never listen. It's deeply frustrating.

I mean yeah, that's why I went and read a bunch of the book. But I still run into lots of issues. Like what the hell is a borrow cow and when would I want to use it? And how do I fix the "temporary value dropped when borrowed" error in a series of maps on options?

If you don't mind sharing snippets for the diagnostics you couldn't figure out, I would love to see them in case we can mechanically suggest the appropriate code, but in general a well placed .clone(), .cloned() or .collect() will be what you want. Likely what's happening is you're iterating over a sequence (you can think of options as a sequence of only one iteration as well), but that iterator is over borrows of the sequence's data, instead of owned values. If you try to return that outside of its enclosing function, you will see that error.

As for a "borrow cow", you probably want to read https://doc.rust-lang.org/std/borrow/enum.Cow.html and https://deterministic.space/secret-life-of-cows.html. For what you are doing, it is an optimization to avoid unnecessary clones that is absolutely not required: make your code work with String and worry about Cow later.

Re: Rust is for Professionals

#66

Post by skohan »

pantulis wrote: post #44

"(...) Rust feels more like Python than C. (...)" This feels like a very powerful assertion. Does the rest of the HN audience agree with this? If this is true, how long did it take?

I'm a bit confused by this take. With Rust you're constantly thinking low level details, like which type of reference something is. I would place it closer to C than Python, but closer to C++ than either.

Re: Rust is for Professionals

#67

Post by mnd999 »

skohan wrote: post #51
mnd999 wrote: post #20

I skimmed it, but I think what the author is getting at is that rust demands rigour. The kind of rigour required when failure is a problem and this tends to be the kind of code people get paid to write. I guess the reverse is also true, if you’re writing the kind of code where failure doesn’t matter (e.g. spikes, experimentation, just messing about) perhaps rust isn’t the best choice.

I think it's a little bit of a trap to fall into to believe that since Rust: 1. provides some unique benefits in terms of safety, and 2. is hard to program and requires rigor that all that rigor is "worth it", and that it makes you a better programmer to put up with it. Don't get me wrong, Rust's tradeoffs are valuable for some use-cases, but there are many, many use-cases where a GC'd language will work just fine, a…

Completely, I don’t see rust as a replacement for Scala, Java, Go (and especially) Javascript which tend to be what I use at work. It’s certainly possible, but I don’t think it would add much.

Re: Rust is for Professionals

#69

Post by Koshkin »

dman wrote: post #40
CJefferson wrote: post #16

Earlier quoted context omitted.

While this can be painful, my basic suggestion -- clone more. The temptation is to never clone, butin C++ people run copy constructors all the time without thinking about it (as they are called automatically).

People do think about this all the time in C++ and it is very common to get code review comments about avoiding copies if you overlook such things.

Yup, and I wish the compiler would give a warning on a use of a copy constructor...

Re: Rust is for Professionals

#70

Post by rhn_mk1 »

pantulis wrote: post #44

"(...) Rust feels more like Python than C. (...)" This feels like a very powerful assertion. Does the rest of the HN audience agree with this? If this is true, how long did it take?

For me, this feeling comes from how Rust APIs are typically built. They embed enough information about allowed usage that shooting yourself in the foot is not trivially possible (unlike C).

I guess one could say APIs expose functionality on the level somewhat similar to C++, with builtin strings, vectors, and other high level data structures that are namespaced and are also objects. Whether that is more C-like or Python-like is for the reader to answer.

Post reply on HN