Maybe I'm picking nits, but the author is comparing programming experiences in each of those languages, which is perfectly valid. For example, last year I was part of a team that rewrote a very large Node.js program (several hundred thousand lines of code) in Go. The differences in following control flow and in the edit-build-test loop are like night and day.

We've found Go meets our needs better than Node.js for writing and debugging large programs. The languages are very different. Both are used for small and large programs. The experience in using them is what makes us choose one over the other.

Interesting. What are some the benefits you felt with Go in comparison to Node.js?

We already have a largish (couple hundred thousand line) Node.js app written in Typescript and are looking towards other alternatives for the future product as I am not very happy with the quality of Node.js ecosystem.

Sorry for the late reply. There are a few advantages to go.

1. we don't force our customers to lay down a large Node.js blob just to run our software.

2. The old code was written for an old version of Node.js, v4.x, I believe. As such, it was full of code suffering from callback hell, and a lot of anonymous functions written inline. It was very difficult to reason about when tracking down bugs. I'm sure your Typescript code is far better organized.

3. The edit-compile-test loop is far faster. It takes less than a minute (20-50 seconds) to compile the new codebase, which is a mix of Go and C apps and libraries. The developers use a simple build script to rebuild everything from scratch. The old codebase, a mix of Javascript and C apps and libraries, was built with CMake to manage dependencies. Each rebuild would complete in a few minutes for small changes, but could take about 10 minutes if the "right" code was touched.

4. Like theshrike79, I find Go's concurrency patterns, channels, and goroutines a delight to use.

5. We use json files for configuration. Go has a simple scheme for converting between json and structs. Node.js allowed us to make poorly structured json files. When we converted them to follow some simple nesting patterns of structs within structs, converting between structs in memory and json files was just too easy!

It seems that the new codebase is significantly smaller, so it's easier to find where things are implemented. Part of that is getting rid of tech debt and being very familiar with the new code.

When we were still in beta, we ran some performance tests. They indicated the new code was as performant as the old node code (which has been worked on for years). We expect to be able to improve on that as we have time.

I hope that helps. It's been a major amount of work to rewrite our apps while maintaining the old code base - not something to do on a whim. I know the dev team is delighted with the results. Good luck.

In my experience the active aversion to all kind of magic make Go code more maintainable even if you're not familiar with that particular part of the code base.

Stuff goes in, stuff comes out. You don't need to wonder if something outside of the scope magically comes around and changes things in the middle.

Also Go's concurrency pattern with goroutines and channels fits really well to my mental models of how stuff tends to work in my field.

I disagree. It's a language, it has symbols, syntax and conventions, it either gets interpreted or it gets compiled.

In the broad swath of languages, go and python are more similar than, say, python and Haskell.

What makes languages apples and oranges is generally not their compilation method but things that are more approach-centric or radically different syntax (which is why I left Rust out. Its syntax has been the thing that's slowed me down most there)

At a high level, I agree with what you're saying here - that it's difficult to compare rust or go with python. But I take some issue with your reasoning.

> After all python is still an interpreted scripting language.

Is it? Or rather, is this even a well-defined category?

> interpreted

Can't any (OK, almost any) language be either interpreted or compiled? The fact that python is typically run in an interpretive runtime setting doesn't really make it "interpreted" as a language. In fact, since python is nearly always compiled to byte code at runtime, it's arguable just as compiled as it is interpreted.

But that's not even the point: there's nothing lingual about python that stops it from being compiled. It can be compared with other languages that are typical run subsequent to a compilation step without being the apple to an orange.

> scripting

This one speaks to me even less. For python to properly be understood as a "scripting" language, I think you'd have to convince me that the lion's share of community energy is dedicated to a paradigm of running a single module front-to-back as a script.

And this is clearly not so.

I largely agree with what you said but

> there's nothing lingual about python that stops it from being compiled

Are you sure? Python is a very dynamic language. Some of the most dynamic parts of python might not be possible to compile fully ahead of time and might need to be JITed, because the behavior of the code will only be possible to determine at runtime.

CPython doesn't have a JIT. It compiles to bytecode, which is then "interpreted" by a stack based VM.

They have a historic point but you’re right that their description doesn’t make much sense given the modern way language runtimes are designed.

A better description would be “high level JIT compiled language”.

> Is it? Or rather, is [Scripting Languages] even a well-defined category?

We could say that the typical compiled language is used for scripting Unix syscalls :-)

Even if languages have different typing regimes, that does not mean that they can be compared. They are means to an end after all. Outside the language itself, you can also compare ecosystems, available tooling, etc.

For his ends, statically-typed languages have benefits over Python:

Obnam is about 15000 lines of Python code. That turned out to be too much for me in Python: too often there were bugs that a static, strong type system would have caught.

comparing apples and apples would be even less interesting.