After all python is still an interpreted scripting language. To me comparing it to rust and go is like apples and oranges.
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.
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.
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.
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 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)
> 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.
A better description would be “high level JIT compiled language”.
> 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.
We could say that the typical compiled language is used for scripting Unix syscalls :-)
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.