This was discussed 10 days ago (287 points, 332 comments) - https://news.ycombinator.com/item?id=33714007
dang - scribe.rip is an alternative front end to medium.com. That's why this wasn't caught by the dupe detection.
Using Rust at a startup: A cautionary tale
51–60 of 134 posts
Re: Using Rust at a startup: A cautionary tale
#52Earlier quoted context omitted.
I'm not sure that it's that cut and dry. Rust provides good tools for building high level abstractions and the developer tooling is comparable to something like typescript. Depending on the team, rust can be a perfectly reasonable choice for a CRUD application. I have a lot of experience writing microservices and batch jobs using C++. At first this seems outrageous, but with a reasonable set of high level utility lib…
Doesn’t Kotlin or Swift offer those things? I agree Rust is a great language (and has many great things besides its safety protections) but I do think that putting it everywhere when it isn’t necessary is dangerous. If one doesn’t exist already, someone should make a rust-like language with garbage collection. EDIT: Thanks to reading other comments, I remembered Elixir, which offers a lot of the concurrency safety of…
Rust is an interesting mix. OCaml gets pretty close and type inference offers better ergonomics. The fearless concurrency story is still much better in Rust than OCaml.
Re: Using Rust at a startup: A cautionary tale
#53Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…
> I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). We're having a great time with Actix + sqlx. It feels like Go, but with less typing (physical). With an IDE like Clion + Rust Plugin, the code writes itself. It feels like writing Java or Golang. Every time someone says "oh no, borrow checker" for *single thread scoped CRUD apps* , I know they're not eve…
> With an IDE like Clion + Rust Plugin, the code writes itself.
If there is any point to emphasize, it is this one. Writing Rust without a nicely tuned IDE is almost as slow as writing it using pen and paper.
Because abstractions are “zero-cost” in Rust and the type system is expressive, there are generally many more types involved and a lot of converting between them.
The IDE is very helpful in seeing what types are where, navigating to their definition, viewing their documentation, etc
Re: Using Rust at a startup: A cautionary tale
#54Earlier quoted context omitted.
This is the kind of attitude that will send Rust the way of C++. Features cost, even optional features. No programming language can or should try to be everything to everyone: to attempt it is to serve no one very well at all, because you split the focus of the language development between too many use cases and you complicate the language so thoroughly that onboarding a new programmer becomes an exercise in re-educa…
Not only that, but the borrow checker also handles safety concerns. Rust's concurrency safety story ("fearless concurrency") is literally built on the back of ownership and borrowing.
Oh, wow, yes. I confess I skimmed the part about green threads.
I think OP doesn't understand that runtime features like GC and green threads have a cost, and Rust is designed around a making it safe to avoid that cost. Most of Rust's features don't make sense in the context of a managed runtime—what you would be left with is basically a subset of OCaml with C-style syntax and optional mutability.
Re: Using Rust at a startup: A cautionary tale
#55If you are writing CPP, rust is a godsend. Many pitfalls/code review debates/wtf moments simply don’t happen in the language. There are huge cpp code bases in the wild which need help. However rust string handling is barely a step above c’s, there are a variety of datastructures c engineers dislike simply because of the memory management constraints. Getting 2x better performance than Java is a marginal gain for many…
I've found Rust is also far better than weakly typed and dynamically typed languages as well.
> However rust string handling is barely a step above c’s
How so? Personally I've found it very good.
Re: Using Rust at a startup: A cautionary tale
#56Rust has brought so many great ideas into the programming mainstream. It is a shame that it has also attracted such a community around it that seems to project all sorts of hopes and wishes into the language. I don't get how someone could think making a CRUD app in Rust could ever be a good idea (beyond hobby projects). That is just not playing to the strengths of the languages at all. If you CAN use a language with…
My 2c: Rust + Actix + Diesel + Tera is the ultimate CRUD app stack, especially now that there is the excellent zero2prod[1] book to refer to for people who have not built a significant CRUD app before.
When you're writing a CRUD app the only errors you should have to worry about are logic errors. The above mentioned Rust stack is the only one that I've been able to achieve that experience with in my whole career.
Re: Using Rust at a startup: A cautionary tale
#57Earlier quoted context omitted.
I'm not sure that it's that cut and dry. Rust provides good tools for building high level abstractions and the developer tooling is comparable to something like typescript. Depending on the team, rust can be a perfectly reasonable choice for a CRUD application. I have a lot of experience writing microservices and batch jobs using C++. At first this seems outrageous, but with a reasonable set of high level utility lib…
Doesn’t Kotlin or Swift offer those things? I agree Rust is a great language (and has many great things besides its safety protections) but I do think that putting it everywhere when it isn’t necessary is dangerous. If one doesn’t exist already, someone should make a rust-like language with garbage collection. EDIT: Thanks to reading other comments, I remembered Elixir, which offers a lot of the concurrency safety of…
Kotlin is probably also a good choice (but it ties you do the JVM, which does come with some operational headaches of it's own). Swift would be a fantastic language for this kind of work, but unfortunately it's library ecosystem isn't on nearly the same level as Rust's for backend web.
Re: Using Rust at a startup: A cautionary tale
#58Earlier quoted context omitted.
Not only that, but the borrow checker also handles safety concerns. Rust's concurrency safety story ("fearless concurrency") is literally built on the back of ownership and borrowing.
Oh, wow, yes. I confess I skimmed the part about green threads. I think OP doesn't understand that runtime features like GC and green threads have a cost, and Rust is designed around a making it safe to avoid that cost. Most of Rust's features don't make sense in the context of a managed runtime—what you would be left with is basically a subset of OCaml with C-style syntax and optional mutability.
Green threads have been totally superseded by current async support in Rust. That's why they're no longer part of the language itself.
Re: Using Rust at a startup: A cautionary tale
#59Earlier quoted context omitted.
IMO if you would forget about borrow checker, Rust is awesome language by itself. I'm not sure if it's even possible, but I think that if GC were introduced to Rust as an optional part, it would make Rust suitable for CRUD apps. Like all low-level libraries are written with borrow checker and you can write your code with borrow-checker or GC, your choice. So you'll still get superior performance compared to any other…
This is the kind of attitude that will send Rust the way of C++. Features cost, even optional features. No programming language can or should try to be everything to everyone: to attempt it is to serve no one very well at all, because you split the focus of the language development between too many use cases and you complicate the language so thoroughly that onboarding a new programmer becomes an exercise in re-educa…
Ironically very early prerelease versions of Rust had a GC (and also Go-style fibers).
I think, however, a lot of people would love to see other GC languages take up the safety promises that Rust provides (especially concurrency).
Re: Using Rust at a startup: A cautionary tale
#60One note about hiring: if you want to hire like super experienced, senior developers who can architect your rust codebase and tell you definitively how to write Rust, you’re probably out of luck. There just aren’t that many people. You can get senior developers and you can get developers with Rust experience but the intersection of the two is very sparse. As a result, expect some churn in your codebase. Your team wil…
Any senior developer with C/C++ experience will probably be pretty comfortable with Rust and its ecosystem. It's not an overly complicated language.
I was very familiar with C before starting to do professional work in Rust, and ran into a similar trap as the grandparent comment describes. Since then I've gained professional experience in C++ as well. Without specific Rust experience, I wholly disagree that "any senior developer with C/C++ experience" will have a good sense of optimal Rust project architecture out of the gate. A reasonably good starting point, sure. But it's a different enough language that you can't just reduce architecture concerns to "it's not overly complicated."