I actually find Racket easier to work with than some mainstream languages. It just gets all the basics right. You don't need huge libraries like Pandas because

I actually find Racket easier to work with than some mainstream languages. It just gets all the basics right. You don't need huge libraries like Pandas because the base language is reasonably fast and comes equipped with the powerhouse "for" macros that make most data processing easy. Macros are used all over the place in Racket and implement a lot of the core language. One of my favorite ones lately is the threading/pipeline macro. I think JS has been debating about this for several years now, but implementing this in Racket is not only easy (available as threading-lib if you don't want to write it) but better than if it were a core language construct. It can be better since using a syntax-parameter, you can rename any of the "keywords" necessary to implement said macro as a user of said macro if you want to. Also, since Racket macros track source line information, you don't need to choose between good error messages and performance. I also feel like Racket strikes a nice balance between dynamic and static. Function and variable names being misspelled is a compile time error, though types aren't checked at compile time. However, Racket had a very sophisticated contract system to help address that as well. If you really want something more thorough, there is even Typed Racket which has easy interop with the rest of Racket and is actually a sound type system unlike TypeScript. (There is apparently a way to bypass the runtime checks when calling untyped code, but this is done for performance and is uncommon, not like with TS where "any" lets you do whatever you want). I should also mention that while Typed Racket is a full language and does some pretty involved stuff besides just basic macros, people have also been working on a library that lets you create new type systems at the macro level by specifying the type reduction rules. One final advantage of macros in Racket's case is that by implementing language features as macros, it is easier to see what the overhead of some particular feature is. Looking at fully expanded Racket code is like looking at the disassembly in C except names are mostly preserved, stuff just moves around and new stuff names come in as well.