5 ms·

HTMX is great for rapid prototyping, but Rust has never struck me as suitable for rapid prototyping. There are some nice abstractions here than reduce the amoun

HTMX is great for rapid prototyping, but Rust has never struck me as suitable for rapid prototyping. There are some nice abstractions here than reduce the amount of code for sure, but that's only one aspect of rapid prototyping. Rust still has a high learning curve, compiles relatively slowly, and still takes a lot more code to achieve things than the equivalent Python or even JavaScript/TypeScript. Shuttle looks pretty cool as a platform, but it seems that it has decided that because Rust is a good language for a platform (makes sense!) that it must be good for usage on the platform. I really don't think I agree with this. In my experience, Django + Heroku (or the Heroku competitor du jour) is a convincing rapid prototyping setup for larger sites. And things like RunKit or Glitch are a convincing setup for smaller builds. I'm not sure whether Shuttle adds anything over these options unless the requirement is to use Rust.

civilitty 3y ago
> HTMX is great for rapid prototyping, but Rust has never struck me as suitable for rapid prototyping. There are some nice abstractions here than reduce the amount of code for sure, but that's only one aspect of rapid prototyping. Rust still has a high learning curve, compiles relatively slowly, and still takes a lot more code to achieve things than the equivalent Python or even JavaScript/TypeScript. In order to support the borrow checker, Rust has a richer type system that allows programmers to encode far more of the business domain than most other languages. Short of logic bugs, the vast majority of my Rust code is in the "if it compiles, it works" bucket which makes it great for rapid prototyping despite the slow compile times. I have to spend a lot less time and mental bandwidth on testing and defensive coding and Rust's version of the public/private distinction o makes it great for wrapping the data model behind types that can only be used correctly - like making sure a user id can only come from a User model type instantiated by the database code and not an arbitrary integer. My favorite part though is that web frameworks like Rocket make it really easy to manage all of the magic going on behind the scenes using trait definitions, in contrast to mega-frameworks like Django. (Rocket was created by the Flask author iirc)
- stmblast 3y ago
  The first framework I used was Rocket! I'm sad that the development pace for it has slowed down extremely significantly though.
- chromatin 3y ago
  > (Rocket was created by the Flask author iirc) unrelated individuals (Flask, Armin Ronacher; Rocket, Sergio Benitez) you're right though that Armin is writing Rust these days though!
- throw10920 3y ago
  Rust's richer type system provides relatively little value over other contemporary type systems like those of Python, TypeScript, and C#, while not providing anything remotely resembling an "interactive" development experience (no REPL, incredibly slow compilation, not hotpatching), and imposing the extremely burdensome and completely unnecessary burden of manual lifetime management. Until these flaws are fixed, Rust is utterly unsuitable for rapid prototyping.
openquery 3y ago
> it seems that it has decided that because Rust is a good language for a platform (makes sense!) that it must be good for usage on the platform. This isn't true - or at least it wasn't our thought process when starting to build Shuttle. Yes Rust made a ton of sense as the language with which to build the platform, but the point of Shuttle was always about providing a great developer experience to the end user. _That's_ why we chose Rust for the 'front end' of the platform. Our position was that the amazing type system combined with generics, metaprogramming (macros) and excellent compiler errors would enable us to build something truly special when it comes to how devs build on Shuttle.
- danpalmer 3y ago
  That's fair about it not being your thought process, but do you think your familiarity with Rust may have affected how you assessed the suitability? Your view on Rust matches my views on what makes Rust a great language, but I don't feel like they make Rust a fast to develop language. - Type systems are great, but pay off more as a codebase grows. Rapid prototyping skews towards small codebases. Type systems do have a non-trivial cost, and that has outsized impact on smaller codebases. - Generics are nice, but small codebases have less need for them. - Metaprogramming and macros are nice and allow building new abstractions, but smaller codebases need fewer abstractions. They also add to the learning curve, as they come with their own learning process. - Compiler error messages are indeed helpful in moving faster, but while Python's error messages aren't great, I hit fewer of them because the language is more flexible, more things "just work" and fewer things are errors. Same for JS, etc. Correctness and safety are great, and I think Rust gets these much faster than other languages, but memory safety is a big benefit of Rust that is entirely unnecessary for almost all rapid prototyping. Speed is also a benefit, but is again rarely needed for prototyping and early stage projects. I'd love to understand more why you feel that Rust is faster, and not just for Rust developers.
  - theossuary 3y ago
    I also have done rapid prototyping in Python and Rust, and have started only using Rust for such projects. - Tooling and packaging are just better. I find myself fighting Python sometimes when setting up testing with pytest, or packaging with poetry/pdm. This overhead is eliminated with Cargo. - I like to write small PoCs for complicated data models, to show how they interact before integrating the concepts into a larger system. I use to do this in Python, but switched to Rust. Python's poor typehinting makes it very hard to know when the concept I'm implementing actually doesn't work. Instead I have to write tons of unit tests to validate it, which ends up taking much longer than using the typesystem as a form of unit testing, and then writing a few logic validating tests. - Large refactorings are much easier in Rust. This is absolutely critical for rapid prototyping, because it's common to rip out large systems. The typesystem tends to point me to every area of the codebase I need to worry about. I've started considering it a code smell if related functionality isn't evident through the type system. - At least in my experience, it's easier to organically grow a codebase. I feel comfortable using a ton of `unwrap`s and `todo!`s in my codebase, because it's easy to grep for them and retrofit proper error handling. I can change a function's type to include a `Result` and the typesystem will direct me to every location I need to update to properly implement error handling. Most languages I work with I feel I must do everything roughly correctly from the beginning. Rust makes me comfortable hacking stuff together, because there's a clean way to slowly remove the tech debt. Hopefully that gives you some idea why Rust can actually be an amazing prototyping language. It can be hard to see when you're still learning the language, but once you have, you rarely run into weird lifetime compiler errors. It really is a language that teaches the programmer.
jokethrowaway 3y ago
It really boils down to personal preference. I never considered Django (or anything python related, eg. FastAPI) to be something good for prototyping because the package manager is a nightmare, deployment is clunky, I often hit pain points or limits in Django. Node.js before the whole require/import mess was neat and simple. All the libraries were working nicely, no problems with npm. Nowadays it's a hit or miss experience. I'm using bun these days to prototype and if you restrict yourself to bun stuff you're good and fast and zero hassle. Rust, contrarily to JS (or TS, the land of any) or Python, has serious safety belts. This means for prototyping it won't be as fast, but you'll sleep well at night. In my experience, if you're not a beginner you'll be able to be fast and iterate quickly with Rust as well, albeit it's not the same. On the other side, once you're done with your prototype I feel way more confident in my Rust prototypes, compared to my JS ones. So, does it really slow you down? The Shuttle boilerplate is nice, but it doesn't really add that much, the equivalent setup in Axum is not that much of a bother (I tend to use a axum + sqlx template I built for new projects). Shuttle the platform is nice, albeit I remember being annoyed by the limits of the free plan (I know, I know, I am cheapskate but I don't want all that nice marketing money go to waste), I generally deploy on fly.io or some more cost effective VPS.
littlestymaar 3y ago
> but Rust has never struck me as suitable for rapid prototyping Having Rust a lot, and coming from JavaScript, I'd say it depend at what stage of prototyping you want to stop: If you want to make a one-shot implementation of a quick demo without ever iterating on, then, yes, Rust is going to slow you down. If your prototyping effort involves lots of iterations because you're learning in the process (learning about the use-case, the market and so on), then Rust quickly pays of compared to JavaScript or say Python because refactoring is straightforward and you're almost never going to break things in the process. Most of the benefit comes from static typing alone, but Rust type system allows you to express things in a more robust way than C# or Java for instance, leading to an even more streamlined iteration cycle (but it's not a game changer either). But the place where I've found Rust to shine, with no match whatsoever, is going from the stable prototype to the production ready stuff: in addition to the ability to get the best achievable performance on your hardware, I find the error handling to be the killer feature in that scenario: when prototyping, you use unwrap everywhere without paying attention (and it basically behaves as in a language exceptions where you don't catch them) but then you just ctrl-F `unwrap` and you can deal exhaustively with all possible error scenario with very limited effort. Ensuring after the fact that every possible exception gets handled properly is a much harder task.
- stmblast 3y ago
  Totally agree with this. I can spin up a generic Axum backend service within probably about half an hour to an hour that contains most of the things I need (auth, CRUD, similar things) once I know what I need, configuration and business logic depending. I think the key phrasing is primarily "when you're familiar with Rust" - if you're not familiar, then it will definitely be a slog. Certain things that would require you to manually implement a complex trait (for example, Send + Sync + 'static plus whatever else) would probably slow you down though, but presumably by that time you probably already know what you're doing.
  - BWStearns 3y ago
    Do you have a goto library for auth in Axum? Maybe I just don’t implement it often enough but auth in Axum usually takes me an hour at least even if I’ve implemented it somewhat recently.
connicpu 3y ago
Not every project has to be suitable for every team of developers. Rust has a good number of people that both like it and are also deeply familiar with it, so it makes sense someone would build something that caters to them. Rust can be great for rapid prototyping when everyone on the project is already a Rust expert.
- phero_cnstrcts 3y ago
  So is rapid if you’re rapid.
aldanor 3y ago
Rust has: - serde; this beats both cpp and Python in terms of not spending a second of dev time on implementing serialisation deserialisation unless you're doing something funky. I would argue that this is one of the cases where it's much harder to handle it in Python than in rust - other proc-macros allowing you to quickly map your structs to sql or whatever else - lsp that works with zero configuration and beats many languages (again, cpp and Python included) because of rust's strictness, and rust-analyser is an absolute pleasure to work with - cargo tooling and zero-pain dependency management; high quality of packages in general Once you get past the initial learning curve and get comfortable with the language, these factors (and quite a few more not directly related to the language itself) eventually become more and more important for prototyping. (all subjective of course)
- culebron21 3y ago
  Which crate does map structures into SQL?
  - saintfiends 3y ago
    sqlx [1] can definitely do this. [1] https://docs.rs/sqlx/latest/sqlx/ https://docs.rs/sqlx/latest/sqlx/
- riku_iki 3y ago
  > serde they have very many formats implemented. Which format is zero penalty, so I can use it and not write my own logic?
  - aldanor 3y ago
    > they have very many formats implemented It's not "they", it's whoever wants to implement serde support for their own thing, can do it (so, many 3rd party crates have a "serde" feature that can be toggled on/off). > Which format is zero penalty This one is tough to answer unless you provide details re: what's your in-process data format, what's your target serialization format and whether it's binary or not, what's the objective function (serialization speed, deserialization speed, storage efficiency), and what exactly you mean by 'zero penalty' (which penalty?). // note that there's also alternative frameworks worth mentioning like rkyv and borsh-rs, each optimizing their own objective function
tomjakubowski 3y ago
When I wrote C++ full time I frequently prototyped algorithms in Rust. Prototyping in C++ is awful: it's so easy to accidentally trigger UB and then you're wasting time debugging some memory corruption instead of exploring your problem. Rust is close enough to C++ that you can get a good idea of equivalent C++ performance, and it isn't too hard to translate the prototype when you're finished. An exception being porting Serde (de)serialization over.

civilitty 3y ago

> HTMX is great for rapid prototyping, but Rust has never struck me as suitable for rapid prototyping. There are some nice abstractions here than reduce the amount of code for sure, but that's only one aspect of rapid prototyping. Rust still has a high learning curve, compiles relatively slowly, and still takes a lot more code to achieve things than the equivalent Python or even JavaScript/TypeScript. In order to support the borrow checker, Rust has a richer type system that allows programmers to encode far more of the business domain than most other languages. Short of logic bugs, the vast majority of my Rust code is in the "if it compiles, it works" bucket which makes it great for rapid prototyping despite the slow compile times. I have to spend a lot less time and mental bandwidth on testing and defensive coding and Rust's version of the public/private distinction o makes it great for wrapping the data model behind types that can only be used correctly - like making sure a user id can only come from a User model type instantiated by the database code and not an arbitrary integer. My favorite part though is that web frameworks like Rocket make it really easy to manage all of the magic going on behind the scenes using trait definitions, in contrast to mega-frameworks like Django. (Rocket was created by the Flask author iirc)

stmblast 3y ago
The first framework I used was Rocket! I'm sad that the development pace for it has slowed down extremely significantly though.
chromatin 3y ago
> (Rocket was created by the Flask author iirc) unrelated individuals (Flask, Armin Ronacher; Rocket, Sergio Benitez) you're right though that Armin is writing Rust these days though!
throw10920 3y ago
Rust's richer type system provides relatively little value over other contemporary type systems like those of Python, TypeScript, and C#, while not providing anything remotely resembling an "interactive" development experience (no REPL, incredibly slow compilation, not hotpatching), and imposing the extremely burdensome and completely unnecessary burden of manual lifetime management. Until these flaws are fixed, Rust is utterly unsuitable for rapid prototyping.

openquery 3y ago

> it seems that it has decided that because Rust is a good language for a platform (makes sense!) that it must be good for usage on the platform. This isn't true - or at least it wasn't our thought process when starting to build Shuttle. Yes Rust made a ton of sense as the language with which to build the platform, but the point of Shuttle was always about providing a great developer experience to the end user. _That's_ why we chose Rust for the 'front end' of the platform. Our position was that the amazing type system combined with generics, metaprogramming (macros) and excellent compiler errors would enable us to build something truly special when it comes to how devs build on Shuttle.

danpalmer 3y ago
That's fair about it not being your thought process, but do you think your familiarity with Rust may have affected how you assessed the suitability? Your view on Rust matches my views on what makes Rust a great language, but I don't feel like they make Rust a fast to develop language. - Type systems are great, but pay off more as a codebase grows. Rapid prototyping skews towards small codebases. Type systems do have a non-trivial cost, and that has outsized impact on smaller codebases. - Generics are nice, but small codebases have less need for them. - Metaprogramming and macros are nice and allow building new abstractions, but smaller codebases need fewer abstractions. They also add to the learning curve, as they come with their own learning process. - Compiler error messages are indeed helpful in moving faster, but while Python's error messages aren't great, I hit fewer of them because the language is more flexible, more things "just work" and fewer things are errors. Same for JS, etc. Correctness and safety are great, and I think Rust gets these much faster than other languages, but memory safety is a big benefit of Rust that is entirely unnecessary for almost all rapid prototyping. Speed is also a benefit, but is again rarely needed for prototyping and early stage projects. I'd love to understand more why you feel that Rust is faster, and not just for Rust developers.
- theossuary 3y ago
  I also have done rapid prototyping in Python and Rust, and have started only using Rust for such projects. - Tooling and packaging are just better. I find myself fighting Python sometimes when setting up testing with pytest, or packaging with poetry/pdm. This overhead is eliminated with Cargo. - I like to write small PoCs for complicated data models, to show how they interact before integrating the concepts into a larger system. I use to do this in Python, but switched to Rust. Python's poor typehinting makes it very hard to know when the concept I'm implementing actually doesn't work. Instead I have to write tons of unit tests to validate it, which ends up taking much longer than using the typesystem as a form of unit testing, and then writing a few logic validating tests. - Large refactorings are much easier in Rust. This is absolutely critical for rapid prototyping, because it's common to rip out large systems. The typesystem tends to point me to every area of the codebase I need to worry about. I've started considering it a code smell if related functionality isn't evident through the type system. - At least in my experience, it's easier to organically grow a codebase. I feel comfortable using a ton of `unwrap`s and `todo!`s in my codebase, because it's easy to grep for them and retrofit proper error handling. I can change a function's type to include a `Result` and the typesystem will direct me to every location I need to update to properly implement error handling. Most languages I work with I feel I must do everything roughly correctly from the beginning. Rust makes me comfortable hacking stuff together, because there's a clean way to slowly remove the tech debt. Hopefully that gives you some idea why Rust can actually be an amazing prototyping language. It can be hard to see when you're still learning the language, but once you have, you rarely run into weird lifetime compiler errors. It really is a language that teaches the programmer.

jokethrowaway 3y ago

It really boils down to personal preference. I never considered Django (or anything python related, eg. FastAPI) to be something good for prototyping because the package manager is a nightmare, deployment is clunky, I often hit pain points or limits in Django. Node.js before the whole require/import mess was neat and simple. All the libraries were working nicely, no problems with npm. Nowadays it's a hit or miss experience. I'm using bun these days to prototype and if you restrict yourself to bun stuff you're good and fast and zero hassle. Rust, contrarily to JS (or TS, the land of any) or Python, has serious safety belts. This means for prototyping it won't be as fast, but you'll sleep well at night. In my experience, if you're not a beginner you'll be able to be fast and iterate quickly with Rust as well, albeit it's not the same. On the other side, once you're done with your prototype I feel way more confident in my Rust prototypes, compared to my JS ones. So, does it really slow you down? The Shuttle boilerplate is nice, but it doesn't really add that much, the equivalent setup in Axum is not that much of a bother (I tend to use a axum + sqlx template I built for new projects). Shuttle the platform is nice, albeit I remember being annoyed by the limits of the free plan (I know, I know, I am cheapskate but I don't want all that nice marketing money go to waste), I generally deploy on fly.io or some more cost effective VPS.

littlestymaar 3y ago

> but Rust has never struck me as suitable for rapid prototyping Having Rust a lot, and coming from JavaScript, I'd say it depend at what stage of prototyping you want to stop: If you want to make a one-shot implementation of a quick demo without ever iterating on, then, yes, Rust is going to slow you down. If your prototyping effort involves lots of iterations because you're learning in the process (learning about the use-case, the market and so on), then Rust quickly pays of compared to JavaScript or say Python because refactoring is straightforward and you're almost never going to break things in the process. Most of the benefit comes from static typing alone, but Rust type system allows you to express things in a more robust way than C# or Java for instance, leading to an even more streamlined iteration cycle (but it's not a game changer either). But the place where I've found Rust to shine, with no match whatsoever, is going from the stable prototype to the production ready stuff: in addition to the ability to get the best achievable performance on your hardware, I find the error handling to be the killer feature in that scenario: when prototyping, you use unwrap everywhere without paying attention (and it basically behaves as in a language exceptions where you don't catch them) but then you just ctrl-F `unwrap` and you can deal exhaustively with all possible error scenario with very limited effort. Ensuring after the fact that every possible exception gets handled properly is a much harder task.

stmblast 3y ago
Totally agree with this. I can spin up a generic Axum backend service within probably about half an hour to an hour that contains most of the things I need (auth, CRUD, similar things) once I know what I need, configuration and business logic depending. I think the key phrasing is primarily "when you're familiar with Rust" - if you're not familiar, then it will definitely be a slog. Certain things that would require you to manually implement a complex trait (for example, Send + Sync + 'static plus whatever else) would probably slow you down though, but presumably by that time you probably already know what you're doing.
- BWStearns 3y ago
  Do you have a goto library for auth in Axum? Maybe I just don’t implement it often enough but auth in Axum usually takes me an hour at least even if I’ve implemented it somewhat recently.

connicpu 3y ago

Not every project has to be suitable for every team of developers. Rust has a good number of people that both like it and are also deeply familiar with it, so it makes sense someone would build something that caters to them. Rust can be great for rapid prototyping when everyone on the project is already a Rust expert.

phero_cnstrcts 3y ago
So is rapid if you’re rapid.

aldanor 3y ago

Rust has: - serde; this beats both cpp and Python in terms of not spending a second of dev time on implementing serialisation deserialisation unless you're doing something funky. I would argue that this is one of the cases where it's much harder to handle it in Python than in rust - other proc-macros allowing you to quickly map your structs to sql or whatever else - lsp that works with zero configuration and beats many languages (again, cpp and Python included) because of rust's strictness, and rust-analyser is an absolute pleasure to work with - cargo tooling and zero-pain dependency management; high quality of packages in general Once you get past the initial learning curve and get comfortable with the language, these factors (and quite a few more not directly related to the language itself) eventually become more and more important for prototyping. (all subjective of course)

culebron21 3y ago
Which crate does map structures into SQL?
- saintfiends 3y ago
  sqlx [1] can definitely do this. [1] https://docs.rs/sqlx/latest/sqlx/ https://docs.rs/sqlx/latest/sqlx/
riku_iki 3y ago
> serde they have very many formats implemented. Which format is zero penalty, so I can use it and not write my own logic?
- aldanor 3y ago
  > they have very many formats implemented It's not "they", it's whoever wants to implement serde support for their own thing, can do it (so, many 3rd party crates have a "serde" feature that can be toggled on/off). > Which format is zero penalty This one is tough to answer unless you provide details re: what's your in-process data format, what's your target serialization format and whether it's binary or not, what's the objective function (serialization speed, deserialization speed, storage efficiency), and what exactly you mean by 'zero penalty' (which penalty?). // note that there's also alternative frameworks worth mentioning like rkyv and borsh-rs, each optimizing their own objective function

tomjakubowski 3y ago

When I wrote C++ full time I frequently prototyped algorithms in Rust. Prototyping in C++ is awful: it's so easy to accidentally trigger UB and then you're wasting time debugging some memory corruption instead of exploring your problem. Rust is close enough to C++ that you can get a good idea of equivalent C++ performance, and it isn't too hard to translate the prototype when you're finished. An exception being porting Serde (de)serialization over.