Loving this already. Count of Monte Cristo in the terminal is a mood

my god

In practice, the packaging issue doesn't really come up unless you're using some OS-specific code from std::os, which is mainly for files and process/thread primitives. With rare exceptions, if tests pass on one platform, they'll pass across the board. OS-specific bugs are rare

#![allow(clippy::too_long_for_skeet)]

The learning curve is definitely there, though it gets overstated for the memes
the Result/Option types, ownership/borrowing, the trait system (esp Send+Sync) and async were the hurdles I faced, in order of difficulty
reach out here or on discord @nroman1938 if you'd like to chat about it

It was fun, though I got to chat with Gjengset not long after it came out and they definitely made things more dramatic/provocative in the edit. Interviewers gonna do what interviewers gonna do

I can't speak to the latter two fractions, but I don't recall BMI being a measure of weight divided by ... surface area???

- concurrency typing built in w/ Send + Sync. You won't touch them too often, but the peace of mind is great
- functional-inspired iterators + closures are useful and unobtrusive until you're ready for them
- a language that has your back w/ safety
- cargo. full stop. www.youtube.com/clip/UgkxBju...

I don't really participate in those code platforms so I can't speak to it, but I'd recommend Rust on the following:
- ergonomic and robust static HM type system
- tagged union enums as first-class citizens, even having Option<T> and Result<T> are just so nice
/cont

'Yea, those other languages are sexy, but I need a job so I'm going to learn Rust'

The cycle is complete! the promised day has come!

I do highly recommend Rust (though I came from a Python background, likely have different use cases)

For a 'Typescript but stricter' may I interest you in ReScript? rescript-lang.org
@fham.dev will have a lot to say

Gleam is also cool: runs on BEAM, compiles to JS!
gleam.run

I've had pretty good experiences with Egui in rust for GUIs, and ratatui for TUIs. Though if I wanted simplicity, I'd expose a pyo3 API and work from the Python side. That's what I do for my library interfaces: call into the api on a single thread, get the GIL and run multithreaded under the hood

pydantic is a start, but it's really not enough... especially since a lot of users will have pydantic type signatures and then... not use a pre-run type checker. So they don't even end up seeing the errors!