If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…
I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe a…
I love building a startup in Rust but wouldn't pick it again
311–320 of 496 posts
Re: I love building a startup in Rust but wouldn't pick it again
#312Earlier quoted context omitted.
Not the fault of Rust compiler per se but in my case the errors that mismatching trait impls from async libraries yield can be downright suicide-inducing. I recognize this is not entirely on rustc though.
esteban of course gave you an excellent response already, but just another bit of like, context here: while it may not be on rustc, the developers want to go beyond the norm here. rustc understands if you write async/await syntax like JavaScript, and then directly proposes that you switch to the Rust syntax: pub async fn foo() -> i32 { unimplemented(); } pub async fn bar() { let f = await foo(); } gives error: incorr…
I'll definitely do so going forward.
The problem is with that is the impostor syndrome: I legitimately can't tell if I am an idiot and skipped some basic Rust training, or the error messages are truly confusing and unproductive.
But your messages help. I'll just write those down and send them to GitHub's issue list.
Re: I love building a startup in Rust but wouldn't pick it again
#313I like this quote from 'The art of Unix Programming' published in 2003 "While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly const…
Re: I love building a startup in Rust but wouldn't pick it again
#314If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…
> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess o…
[0]: https://www.usenix.org/system/files/1311_05-08_mickens.pdf
Re: I love building a startup in Rust but wouldn't pick it again
#315That is, the free money, in credits, that allows you to not worry about performance for a while.
The obvious problem being... "What happens when the free money runs out?"
It's not addressed, but the implied answer seems to be "Well, by then it'll be six months later, and..."
And? And what? It's still a problem! It didn't go away.
The money deflected the perf concerns for some time, maybe a year - but then it's back, bigger and badder than ever.
Rust solves that by not requiring that outlay ever, by being more efficient.
Seems like a very poor reason to not choose Rust, to me.
Re: I love building a startup in Rust but wouldn't pick it again
#316I don't agree. I think the author is conflating two things: 1. learning Rust, and 2. using Rust. If you take away "Rust made us slow because our team had to learn how to use it and thus we had slow iterations and it's harder to find hires with Rust knowledge" from the equation, then you aren't left with much argument against using Rust early. The iteration time issue with Rust is solved by experience. We use Rust and…
Well Python code will on average will be more correct than Rust code. I'm not sure why you feel Rust code would be more correct than Python code but it certainly isn't true.
The reasons are types and rusts multi threading guarantees, which become even more helpful when doing refactorings
Re: I love building a startup in Rust but wouldn't pick it again
#317If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…
Re: I love building a startup in Rust but wouldn't pick it again
#318If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…
> If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. I've been saying that for a while. If you're building web backends, Rust is not a good choice. Go is so much easier. The green thread system gets rid of the thread/async distinction, garbage collection means you don't have to obsess o…
You may be underestimating the amount of need there is for performant code though. Its everywhere.
Re: I love building a startup in Rust but wouldn't pick it again
#319If you're thinking about building something in Rust, a good question to ask is, "what would I use if Rust didn't exist?" If your answer is something like Go or Node.js, then Rust is probably not the right choice. If your answer is C or C++ or something similar, then Rust is very likely the right choice. Obv, there are always exceptions here, but this helps you work through things a bit more objectively. Rust can be a…
I love Rust but I am still looking for the perfect blend of the two camps. One the one hand, Go/Node/Python/etc doesn't scratch my itch for the strong type system (sum types/tagged enums mostly) and on the other hand even though I like prototyping in Rust I really miss things like a REPL, more terse syntax, and a bit more expressiveness. I think OCaml is closer to my ideal but the ecosystem isn't quite there. Maybe a…
Re: I love building a startup in Rust but wouldn't pick it again
#320I like this quote from 'The art of Unix Programming' published in 2003 "While it still makes sense to write system programs and time-critical kernels of applications in C or C++, the world has changed a great deal since these languages came to prominence in the 1980s. In 2003, processors are a thousand times faster, memories are a thousand times larger, and disks are a factor of ten thousand larger, for roughly const…
In a benchmark of how many fortune responses are returned by various web frameworks[0], nodejs returned 80k odd fortunes per second. The fastest c++ framework compared here returned 616k odd fortunes per second. Assuming that my application scales by the same amount (big assumption, yes), I could cut AWS costs by 7.7 times (!!!) by using the C++ implementation. I'm pretty sure that maintaining a C++ codebase is less…