why did you decide on Rust over something like Go?
Rust provides a much richer set of tools and abstractions that make it more expressive than Go. It also generally results in higher runtime performance, though Go is also very fast. Go wins in compile time, and i suppose ease of learning, but for me personally not much else.
How hard has it been to do web development in Rust?
Not inherently more difficult than web development with any other language, but...
What has been your biggest problems slowing you down?
The ecosystem is small and immature. This results in sparse documentation, and a wealth of small beta-level interesting libraries but few stable choices. Really, at this point, there's only actix-web at 1.0, and that happened a matter of weeks ago. It also represented a huge breaking API change from the previous release. So, all this will likely improve with time, but leaves much to be desired for a lot of use cases.
What has made using Rust better?
I find the language itself, including rustc and Cargo, to be a superior environment for writing correct code. This correctness extends to web applications, it's quicker to cover all the edges of an application and be satisfied you've done so thoroughly at compile time.
Do you find time to get to MVP/Production much slower than in other languages like Go, Python, or JavaScript?
Not generally. Initial spin-up is slower, but bug-hunting down to usable is not because you're writing fewer bugs in the first place. Depends on your familiarity with Rust and other languages, but i don't think it's really inherently slower.
All in all it's an excellent choice for side projects and probably a decent option for serious work depending on your specific case, but with major caveats.
The ecosystem is small and immature. This results in sparse documentation, and a wealth of small beta-level interesting libraries but few stable choices.
It is a bit awkward because Rust as a language is seen as safe and fast, yet most libraries out there will put a big warning saying something like "This works most of the time, but it might break or we might make some big changes at anytime." But i know this will get better with time.
By "Break" they mean stop compiling, not stop working or crash at runtime. But also note that as long as you sensibly specify your dependencies, that will not affect you until you want to upgrade that dependency. Almost everyone is correctly following semver, so breaking changes won't occur on a minor point release.
Is it too cynical to suggest that when you get a mature, pretty complete and stable tool set (e.g. Rails) then it stops becoming fashionably cutting edge, and the kool kidz want to use something else instead?
Hmm, interesting. I could see that being a factor...but is Rails no longer considered "Kool"? I didn't realize it had already fallen from grace, at least around me it's a widely used tech, seems to be going strong.
I'm pretty sure that it has matured to the stage where its only use is as a productive tool for creating useful products. I don't think that that feels like fun to everyone.
Rust provides a much richer set of tools and abstractions that make it more expressive than Go. It also generally results in higher runtime performance, though Go is also very fast. Go wins in compile time, and i suppose ease of learning, but for me personally not much else.
Not inherently more difficult than web development with any other language, but...
The ecosystem is small and immature. This results in sparse documentation, and a wealth of small beta-level interesting libraries but few stable choices. Really, at this point, there's only actix-web at 1.0, and that happened a matter of weeks ago. It also represented a huge breaking API change from the previous release. So, all this will likely improve with time, but leaves much to be desired for a lot of use cases.
I find the language itself, including rustc and Cargo, to be a superior environment for writing correct code. This correctness extends to web applications, it's quicker to cover all the edges of an application and be satisfied you've done so thoroughly at compile time.
Not generally. Initial spin-up is slower, but bug-hunting down to usable is not because you're writing fewer bugs in the first place. Depends on your familiarity with Rust and other languages, but i don't think it's really inherently slower.
All in all it's an excellent choice for side projects and probably a decent option for serious work depending on your specific case, but with major caveats.
It is a bit awkward because Rust as a language is seen as safe and fast, yet most libraries out there will put a big warning saying something like "This works most of the time, but it might break or we might make some big changes at anytime." But i know this will get better with time.
By "Break" they mean stop compiling, not stop working or crash at runtime. But also note that as long as you sensibly specify your dependencies, that will not affect you until you want to upgrade that dependency. Almost everyone is correctly following semver, so breaking changes won't occur on a minor point release.
Is it too cynical to suggest that when you get a mature, pretty complete and stable tool set (e.g. Rails) then it stops becoming fashionably cutting edge, and the kool kidz want to use something else instead?
Hmm, interesting. I could see that being a factor...but is Rails no longer considered "Kool"? I didn't realize it had already fallen from grace, at least around me it's a widely used tech, seems to be going strong.
I'm pretty sure that it has matured to the stage where its only use is as a productive tool for creating useful products. I don't think that that feels like fun to everyone.
OK, a bit cynical.
Well, safe and fast at the language level is a different concern than at the library level.
It's more à concern around the breaking changes that might occurs rather than safety.