[deleted]
Using Rust at a startup: A cautionary tale
181–190 of 355 posts
Re: Using Rust at a startup: A cautionary tale
#182Earlier quoted context omitted.
This doesn't match my experience. It took some time to get up to speed, but at this point it's much faster for me to write something in Rust than in other languages that I'm proficient in that are ostensibly faster to develop in (e.g., JavaScript). Part of this depends on one's bar for quality. In Node.js I could write `JSON.parse(input).foo.bar` really quickly. In Rust, I'd probably write two struct definitions with…
Ok, for some perspective here, that 45 seconds longer is about 50-100 times how long it took to do the one liner in javascript. Extrapolate that to generally 50-100x development time for the development of an entire project and you're looking at weeks to months longer development time to solve the same problem. Rust is slower to develop in by a significant factor than js, python, ruby etc.
What I was trying to get at with the (silly) example is that the time-to-first-execution of a working program on good input might be much faster with something like JS, but the time to have a debugged version that fails gracefully (and clearly) on operational errors may not be. It’s okay to disagree, and it’s also okay to agree and still feel Rust makes the wrong tradeoffs. I just mention it because I think people sometimes overweight the time-to-first-run.
Re: Using Rust at a startup: A cautionary tale
#183[deleted]
Re: Using Rust at a startup: A cautionary tale
#184I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…
God I get tired of the if err criticism with Go. I truthfully don't even notice it when I write Go, I don't understand why folks get so bent out of shape over it.
[deleted]
Re: Using Rust at a startup: A cautionary tale
#185Earlier quoted context omitted.
> Rust still has option types and the cases where an Option could be None still need to be handled And rust has the `?` operator, as well as combinators like `map`, `and_then`, `unwrap_or_else`, etc. which IMO make the flow much easier to follow than say `if option.is_none() { return None }`. > Rust's default paradigm for memory management seems more significant of a language feature in my opinion and is what I can i…
`map` and its cousins make Rust error handling code easier to write . It doesn't make error handling easier to follow . And Rust introduces the problem of "thicket of different error types". And that's before we get to the sync/async boundary. There's a lot not to like about both Rust and Go's error handling. People need to stop pretending that either language has this answered perfectly. People complain about Go's w…
Having used exceptions, like in java and python, checking error return values like in go and to some extent c, and using ADTs to represent error conditions like in rust, haskell, and scala (scala has exceptions too, but it's arguably more idiomatic to use Option, Try, etc.), primarily in application code, I by far prefer using ADTs. IMO it is a good balance between explicitness and verbosity. And ensuring you handle errors is built in to the type system.
Re: Using Rust at a startup: A cautionary tale
#186Isn’t it about time for a language with a runtime with an HTTP server and SQL database? There’s literally millions of us writing basically the same code over and over again: listen on port 80, parse and transform text more times than necessary to make a SQL call to then parse and transform the returned rows into text more times than necessary to return some JSON or HTML. The wasted clock cycles and developer hours mo…
Isn't that the problem that the backend framework + orm combination aim to solve?
Like django, or flask+sqlalchemy
Re: Using Rust at a startup: A cautionary tale
#187I'm not sure I agree with the article's premises. Rust can be difficult, yes, but it can also heighten developer productivity above other languages. In Go, I'd have to worry about whether I checked for exceptions via `if err != nil` everywhere, while with Rust, I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type. Same for having algebraic data types or, well, generics in gen…
> I can depend on the compiler telling me if I haven't done so exhaustively, via the Result type
That's going to get tiresome after about half a day.
Exceptions or GTFO.
Re: Using Rust at a startup: A cautionary tale
#188Earlier quoted context omitted.
> Rust is considerably more productive [than Python] Can you expand on this, please?
Python is extremely easy to write, but hell to read. Rust code tends to be very easy to read. On a big project, you are going to be reading a lot more code than you are going to be writing.
I've read and written a huge amount of python and rust, also a fan of rust and don't find it particular difficult to read.
As long as there is proper linting, both should be readable.
That being said, python is about the simplest language there is to read.
Of course if you have many times nested and improperly indented list comprehensions- sure that gets confusing. But that should be fixed with proper linting (black on its own should do it)
Curious about the examples you've seen that were difficult to parse!
Re: Using Rust at a startup: A cautionary tale
#189Just once I wish I could force a Rust person to use either Ada, or even an Oberon-2 derivative that spits out C code and which compiles in a flash. Then compare the experience...
Speaking as a "Rust person" do you have any code samples or projects I could take a look at to compare? I've always heard good things about Ada but haven't tried it personally.
Re: Using Rust at a startup: A cautionary tale
#190> With Rust, though, one needs to learn entirely new ideas — things like lifetimes, ownership, and the borrow checker. This is really the main reason not to use Rust when you need to move fast: if you don't know the language yet, it will take you time to learn it. But that's true of any language. You probably shouldn't do your startup in Java, either, if your team isn't familiar with it. Yes, Rust's learning curve is…
[deleted]