Disclaimer: I have no TypeScript experience. I'd say poking at both languages is useful. The choice of ecosystem can come later, according to the taste and tasks.<p>Rust:<p>- makes you a better coder indeed, Rust is pretty clear and organized about its abstractions. Sum types, honest traits, no nil values, disciplined approach to errors and generics, the right amount of niceties and syntax sugar. The idea of borrow checking (and when to avoid it) is a valuable insight into programming in itself. Straightforward RAII instead of wanton `defer`s everywhere.<p>- fearless concurrency (no global mutable variables, Arc, Send + Sync, ownership of objects by threads) with reliability heads and shoulders higher than everything else.<p>- first-class support for WebAssembly (wasm-bindgen, js-sys, wasm-pack, etc). Interfaces with other languages well (PyO3, Node bindings, C/C++ via bindgen/cbindgen).<p>- fine-grained, low-level control over memory allocations and layouts.<p>- requires quite a bit of effort and dedication to use it effectively. The standard library is extensive in volume (not functionality), takes time to learn, has its own conventions and context-dependent, non-straightforward idioms.<p>Golang:<p>- a language to get things done, with very decent and extensive ecosystem.<p>- a perfect choice for backend servers, microservices, everything working over the network.<p>- teaches about perils of freely mixing shared memory with concurrency. Goroutines are so easy to spawn, until they are not. Channels seem like a good idea, until dive into a real code base with mutexes and shared memory. Still, both goroutines and channels are solid, practical tools that work well.<p>- writing new code is objectively faster and easier with GC.<p>- compared to TypeScript, still teaches to manage memory layouts and has structs as values.<p>- doing pretty basic things like iterators, sum types, custom data structures, even tuples of values can be painful, but this is changing with the newly introduced generics.<p>- I still try to come to terms with the wild abuse of programming language theory terms in Go, where an "interface" is not just a trait, but also a set of types and behaves almost like a supertype.