Programming

Overall I agree with what the author says, though I have a few further thoughts:

One might argue that writing types are time consuming, and the bugs are not an issue when programmer can cover those cases with automated tests.

These two arguments contradict each other and together are an argument for static typing, not against. Which just shows how weak these arguments are.

but a more powerful type of inference that can actually infer the whole type of a function by analyzing the body of the function.

This bit I am not convinced by. Inferring the API of a function from its body makes it harder to see breaking changes when you refactor the body. It can be useful for internal private helpers, but IMO public APIs should be explicit about their signature.

Functional Programming

I would go one step further here. It should support OOP and procedural paradigms as well. No single programming paradigm is best suited to all problems. Sometimes a mixed approach is best. Any language that heavily leans oneway at the expense of the others limits itself to the problems it can best solve. I do admit the far too many languages lean too much towards OOP at the expense of functional style.

So it is easy to push for a functional style over OOP in new languages. But I would be weary of purely functional language as well.

I've been liking Go. Reminds me of Python without the risk of filling my Linux install with dependencies.

With regards to immutability and pure functions, I don't really care where the language falls on the scale the author defined so long as there is a way to easily express deeply immutable objects and pure functions. There are a ton of benefits of those two things and a lot of optimizations and assumptions that can be made with them. So I don't really care if everything is immutable by default but just being able to tell the compiler/runtime "Hey listen, this thing won't change ever, got it? So go crazy with passing it to threads and stuff" or "This function will 100% definitely return the same value if given the same input so if it takes a long time you can cache the result if you're able to." both seem very appealing.

I'm surprised that he didn't mention Rust when talking about type inference. The way it does it is excellent.

TypeScript has become my go-to general-purpose option. Between Node.js & the web you can build anything (and share code between all these different domains), the JS ecosystem is huge so there's existing libraries & examples for everything, it gives you a good balance between productivity & performance (much faster to run than Python, much faster to write than Rust), and proper typing solves the rough edges of JavaScript without being so strict that you have to fight it.

I work with Kotlin, Rust, and Bash for various other specific things (e.g. Android apps, very low-level/high-performance code, and widely-compatible scripting) but 9 times out of 10 I'd reach for TypeScript if there isn't a special reason.

Rust is my goto language today. It dips its toes into a bit of everything I like doing (webdev, cli apps, etc) and I feel comfortable with it. I haven’t found a project where Rust would hold me back yet, but I’m assuming I will eventually.

I've become a big proponent of static typing and the functional programming paradigm, both of which solve the problem of figuring out what you're looking at.

With OOP and side effects you can receive a variable but still not know what it really is, is it modified somewhere before or after that you missed? Is it passed deep into nested functions that modify it? Who knows! With pure functions that goes away completely, you can easily inspect what goes into it.

Static typing also solves, among many other problems, this same issue. I've written a good deal of python, and anytime I go from rust, my current love affair, back to python I end up needing to take a break and go to my dog for emotional support. I've tried using mypy for static type analysis, I still use it, but it's very far from perfect; not least because many of the scientific libraries I use don't implement static type hints and are in fact written in such a way that implementing them would be difficult or nonsensical in some instances. It's a complete nightmare. The only solution would be every one of these libraries rewriting themselves, so not likely.

In my opinion, it depends on your goals and scope. If memory manipulation (Probably not the correct words), and/or every bit of performance matters, or it has a large scope, then one would pick Rust/C-lang. If development time and scope is small, something like Python is better.

Source: I used C++, C#, Python, and I use G'MIC (language very much geared for raster graphics processing).

I want to say Rust, but for some stuff it's probably very overkill. I love it, but there's a reason we don't use CPP for everything. (WASM may change things here but IDK)

Swift would be an excellent candidate for the title of "simpler Rust," but unfortunately it's doomed to rot in Apple's walled garden for all eternity.

Honestly, I would say TS (which I hate, but it's indispensable for many things) or any JVM/NET language (Kotlin, C#, both are good)

my opinion is a good language needs these qualities. Portable, Safe, Fast, Easy.

which seems to be similar to the author of the article. the language I have found to match the criteria the most is the D programming Language, its so mediocre in every area.

3 separate compilers, gcc llvm and mars backends. can be as safe as you want it to be, with constructs for purity, GC, and contracts built in. can be as fast as you want it to be it is a systems language and gives you all the necessary tools to go down to C level or below with a good in line assembly, but generally the idiomatic code is fast enough you dont need to go to the C level.

it is also very easy, you have a lot of C libraries and D libraries you can use and with a built in C compiler (currently beta) you can import C libraries easier, it also has a similar syntax to C so its very easy to rewrite C code in D, it has an optional GC so if you are going for max performance you can beta test algorithms quickly using the GC and when you are ready for max performance you can do it all manually, or you can use the feature to test what is using the GC so you can avoid the GC in loops, I did this in a game recently, I used the GC to setup all memory at the beginning and turned off the GC so I would never use it in a loop,

another nice feature is functional features that make the language cleaner to write. I dont think this approach of being perfectly mediocre is necessarily the best but at least on paper its very good, and in practice there have been companies (specifically Weka Digital) that swear by the approach, they can use one language for both testing out ideas and the final product. but again in a lot of cases you dont want a language that is good at everything you want one that is good for your use case.

also the article was very interesting, language design fascinates me and the article was a good read really enjoyed it. currently planning on learning Haskell and Zig soon should be fun to compare these once I am comfortable with them.

Kotlin

I agree on basically all points. Great article, nicely explained.

Typescript. Runs everywhere. Very active community. It’s the modern day Java.

I am enjoying Swift.