cargo-watch

rnal mutation and making helper functions. Doesn’t always work because some languages like Rust don’t have legit support for currying (afaik in 2023 August), but in those cases you can hack it with builder methods to an extent. Finally, if you want to understand the middle of the midwit meme, check out this wiki article and connect the free monoid to the Kleene star (0 or more copies of your pattern) and Kleene plus (1 or more copies of your pattern). Those are also in regex so it can help you remember the regex symbols. https://en.wikipedia.org/wiki/Free_monoid?wprov=sfti1 The simplest example might be {0}^* in which case we find: “”, “0”, “00”, “000” … a language with only one letter in the alphabet could still make all the natural numbers like that. With Boolean alphabet (two variant enum) we have {0,1}^+ which omits the empty monoid by using the + operator: “0”, “1”, “00”, “01”, … note this sequence will eventually yield every possible Turing tape, which is the same thing as listing every possible series of coin flip results assuming no coins land on their side (Turing’s undecidability paradox might be bullshit, but that’s another story) I meekly suggest, FP can save you days of headache if the only thing you do is clone your data and mutate the clone. Yes, that’s inefficient, so is dealing with infinite bugs due to state mutation in multiple places. Also, you can look into HAMTs / immutable / persistent data structures to juggle the pointers and copy-on-write on the storage data structure if you find yourself repeatedly cloning data then it would accelerate your stuff. Options include: Python: Immutables https://pypi.org/project/immutables/ Rust: RPDS https://docs.rs/rpds/latest/rpds/ and Im https://docs.rs/im/latest/im/ Rust isn’t great for letting you do FP things like other languages, but it does have the best type system imho which makes it the leading functional programming language right now imho. If you’re not using too many specialized python packages then I recommend using Rust instead, even for toy demos, as you can be more confident your code works without needing to run it and wait for a crash like you would in debugging python, and the tests also run faster in rust due to the incremental compilation. Use cargo-watch and you can retest your code every time you save your work. https://github.com/watchexec/cargo-watch I usually write a make command to cargo watch and rerun each test file : code file pair independently so then you won’t rerun your tests in other modules when you change the one you work on (faster but might miss stuff if you change API contracts which touch other parts of your codebase)

rust, because they use different terminology. - Docs can be confusing to read because every method on collections like `map` or `filter` returns its own Trait. People have explained why this is to me a couple of times but I still haven't gotten it through my head. - You still have to think about memory and pointers. Not always a bad thing, but it is an extra dimension when solving a problem. Overall I'm powering through. I'm hoping to get to a point where Rust is an obvious choice for anything that involves finer control of memory. [0] https://github.com/watchexec/cargo-watch

had to be rebuilt. My own code was small, but still. > Rust makes you think about dimensions of your code that matter tremendously for systems programming...It makes you think about real but unlikely corner cases and make sure that they’re handled...These are all valid concerns. But for most web applications, they’re not the most important concerns. I disagree strongly (at least about corner cases). Maybe you don't want to bother with this stuff when you're still in the prototyping phase, but once a service is fairly well established, it's definitely beneficial to be forced to think about corner-cases (both in libraries/IO, and in your own business logic that you've hopefully modeled with Rust's powerful type system). Not only is your API usually the authoritative source of truth for your application/service, it's exposed to the whole internet by design, just begging to be prodded for logic holes. This IMO is one of Rust's main benefits; it's been called "the practical Haskell" before, and while its ecosystem isn't yet the most practical one for web servers, it is still much more so than Haskell's. > Lots of missing pieces This is the strongest point, in my opinion. Rust's web ecosystem is definitely still in the early days, and this is partly because Rust's benefits aren't nearly as extreme in this usecase as they are in other usecases. There is for sure a chicken-and-egg problem as not enough companies are using Rust for web servers, which means not as much time is getting invested in the relevant libraries. I hope this changes; I don't know for sure that it will. It feels like it is, but very slowly. That said: > Unfortunately, a lot of the incredibly exciting work in the Rust ecosystem has nothing to do with web application servers. There are some promising web frameworks - even a somewhat higher-level framework - but they’re undoubtedly in a niche. Even Actix, the main web framework, has a very top-heavy set of contributors. The author failed to mention or wasn't aware of Rocket (https://rocket.rs/), an up-and-coming Rust web framework that's extremely exciting and provides a programming experience strikingly similar to that of Flask or Express. It's still in 0.X releases, the current release doesn't build on stable rustc (though the master branch does!), you're still going to have a hard time finding SDKs for auth and payment and cloud, etc. But the important thing is that it shows what's possible. Web servers can be ergonomic to write in Rust, benefiting from its wonderful type system and performance, with very few sacrifices. We just need the ecosystem to catch up. Hopefully enough companies will realize the opportunity and that will happen. In summary: Yeah. Rust is a hard way to make a web API right now. But I don't think it has to be.