Hacker News Reader

Comment by openquery | Hacker News Reader

> 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.

View on HN

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.

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.

> 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.

Python's package / project management story is seriously abysmal compared to its competitors. It's crazy that for a language with as much adoption the best we have is poetry. Adding and isolating project dependencies should not be a difficult thing to do, it should be first class in any serious language like it is in node, ruby, elixir, rust, etc etc etc.

I think they are making steps with Pipfiles, but yeah it's definitely not great. I had to use Python for a hackathon a while ago and it was probably one of the worst experiences I had trying to get set up with my group.

Thanks for the input, and I completely agree in the value of all of these aspects, just not so much for prototyping.

Tooling and packaging disappear with a sufficiently good prototyping environment (and Cargo doesn't completely eliminate this in my experience anyway), Rust's type system means also working with the borrow checker which is not useful for data modelling (outside of safety concerns), large refactorings aren't necessary in small prototypes (even as things change).

You're right that it's easier to grow a codebase organically from a good starting point, and Rust will offer that, but I'm not sure that's the right focus for rapid prototyping. The aim is not about setting solid foundations, it's about testing ideas.

Rust is nice, don't get me wrong. I don't disagree with any of these points. I just think that they're all in the mode of improving "traditional" backend development, not in the mode of making rapid prototyping as good as it can be.

Re data modeling: If you’re using copilot or something similar I’ve found it really fast to drop in a comment with a sample of the data and then quickly crank out the appropriate types. It doesn’t get them all perfect in one shot usually but it reduces the overhead enough to make it effectively free when considering the safety and refactoring benefits.

Also rust offers you out of the box tests, so you can write tests to prove your code does what you'd expect, before finish the whole prototype, it helps a lot versus most languages, most of the time you can just run `cargo watch -q -c -x test` and start hacking.

Python has had tests and a cli that discovers them since 3.2 https://docs.python.org/3/library/unittest.html

>>Test Discovery¶ >> >>New in version 3.2.

It's invoked by:

>>python -m unittest

Edit:

I guess if you're argument is for the watcher...great but I use `entr` https://github.com/eradman/entr when I want that feature and it just works across languages but I've not used continuous testing for ages.

How are Rust tests any more suitable for rapid prototyping than Python tests? If writing tests can even be considered "rapid prototyping".

You cut down a chunk of tests by not needing to figure out what type something is. You can also use assert! and assert_eq! in your main code without even using tests which also cuts down on tests, where applicable.

You can also write unit tests in the same files as your main code. Eventually you'll want some kind of test suite when your codebase gets big enough, but it works well enough that you don't need to if you don't want to (for a small codebase).

Frameworks like Axum also of course support testing - for instance this crate lets you quickly mock up your server without having to do much: https://docs.rs/axum-test/latest/axum_test/

> You cut down a chunk of tests by not needing to figure out what type something is

I have literally never written such a test in a rapid prototyping context.

When you are prototyping you change code here and there, so a type system helps in that regard and I consider type system as a kind of test. So by having that built in, you need to write less tests, but AFAIK python has an optional type system, not sure how that works, but I suppose it would help in that regard.

If find that exactly the situation where a type system is intrusive, not helpful.

Many other languages have similar easy ways of running tests on file changes.

For example, in (Node)JS, you can just do `npx jest -o` if you are using Jest testing library, and with Scala you would usually use `~ test` in sbt shell.

That's not the same thing, I think he's referring to the fact that in Rust you can keep unit tests and code in the same file, and strip them away at build time. That's not a thing in the js world (and most other languages), where tests must be in a different file and you are forced to export functions to test them, even if you wanted to keep them private in that file.

To be honest you might be able to use just the built in node test runner (deno and bun also have their own test runners), but IMHO are not as ergonomic as Rust, in Rust you can test private functions in the same file, and that let's you prototype faster, you write a simple function and a test (even when the prototype is not fully functional).

In JS land you could do the same I think, but you would need to export all methods that you want to test and they are in other files, and to make things worse you need to setup Typescript to make your IDE more useful and also write less tests, I would argue that in that case vite/vitest will be more helpful because the tests runs with the same config as the bundler, but still, it does not work out of the box as Rust, there might be other languages that have also good ergonomics as Rust in that regard, but none of the languages that I use besides Rust do that.

This is likely just a me problem, but I always found Jest extremely annoying to set up with React and TypeScript - particularly with attempting to follow the documentation for jest and then failing spectacularly (in spite of using React Testing Library, jsdom + jest).

Cypress on the other hand I found to be really, really good

Cypress and Jest aren't really operating at the same level though. Cypress competes more with Playwright (functional, E2E tests), and Jest competes more with Vitest, Chai, Mocha, Jasmine for unit tests (though it can also do much more).

Personally I prefer Vitest to Jest... if it will work for the codebase I'm in.

vitest, like everything to do with vite, just works. The API is almost identical to Jest so you can swap over easily.

Reply on news.ycombinator.com