5 ms·

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

> 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.
  - epiccoleman 3y ago
    > 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.
    - stmblast 3y ago
      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.
  - danpalmer 3y ago
    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.
    - BWStearns 3y ago
      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.
- norman784 3y ago
  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.
  - watermelon0 3y ago
    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.
    - stmblast 3y ago
      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
      - pcthrowaway 3y ago
        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.
      - brainbag 3y ago
        vitest, like everything to do with vite, just works. The API is almost identical to Jest so you can swap over easily.
    - riquito 3y ago
      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.

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.
- epiccoleman 3y ago
  > 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.
  - stmblast 3y ago
    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.
- danpalmer 3y ago
  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.
  - BWStearns 3y ago
    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.
norman784 3y ago
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.
- watermelon0 3y ago
  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.
  - stmblast 3y ago
    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
    - pcthrowaway 3y ago
      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.
    - brainbag 3y ago
      vitest, like everything to do with vite, just works. The API is almost identical to Jest so you can swap over easily.
  - riquito 3y ago
    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.