Why we switched from Python to Go
getstream.io
getstream.io
[0]: https://nim-by-example.github.io
The experience so far has been outstanding. Nim has functioned flawlessly with a minimum of magic. It seems to work very cleanly and the compiler is cleanly integrated, but still swappable (ie between gcc, clang, ming..) Nicely color-coded, too.
Exceptions are caught with full tracebacks, and pre-compile checks quickly point out exact location of syntax errors. (Good, clear error messages are surprisingly missing from many languages.)
Here's an awesome example; in my first day of coding, I was able to replicate python's "+" string concatenator ("hello" + "world" versus "hello" & "world" in Nim) with a one-liner:
proc `+` (x, y: string): string = x & y
Nim compiles quickly and its type inference (where it guesses what type of variable you're working with) makes strong typing mostly painless, and you still get all of the advantages (type safety, speed) of static typing.
There are some trade-offs that are made (obviously), but the language designers seem to make trade-offs in favor of speed and robustness over language features -- but this still leaves a lot of room for features.
I also like how the syntax has a lot of similarities to Python's. The only thing I've missed so far is a nim interpreter, so that I can get up to speed faster on the syntax or try things out quickly. The tutorial on the Nim website is definitely not for beginning coders (who would probably be quickly scared off by words like lexical), but it quickly covers the language syntax for experienced coders and seems to borrow a lot of the best ideas from other languages.
Nim is basically awesome. The few downsides are that the standard library is still pretty light (but that gives you an opportunity to build something great and have it be widely adopted), that there's no interpreter, and that the tooling is still a bit lighter than older languages. All of these will be improved with time.
And, it's fast. Really fast. Compare nim in these benchmarks[1] to any other mid-level (or even low-level) language and it really shines. It's generally much faster than Go, for instance.
template `+`(a, b: string): string = a & b
Try running `nim secret` on the command line, it's not perfect but it's enough to play around a bit.
There are some companies using Nim, but they're not in this list
Wow. That's cool. I'll have to look into this.
I won't say that Go is mainstream yet, but it feels very "production-ready" in those respects.
So the mainstream languages are...: C/C++, C#, F#, Go, Groovy, Java, JavaScript, TypeScript, Kotlin, Objective-C, PHP, Python, Ruby, Scala, SQL, Swift, VB.NET (source: https://www.jetbrains.com/products.html).
Sounds about right :)
I wish that I knew a phrase to mean "has all of the documentation, tools, and libraries that are needed for an average team of developers following common practices to be likely to successfully ship and effectively maintain commercial projects, consistently".
Many really interesting languages and frameworks don't pass this criteria. It doesn't mean that they are a failure: the idea of programming languages that are designed for teaching or research, and are specifically not for commercial use, perhaps used to be more common than it is now.
On a more unrelated note, is Groovy widely used? As someone who doesn't really ever use JVM languages, my impression was that it didn't have the similar usage to Kotlin and Scala, although I might be mistaken.
Of those 18 languages, only 13 are in the TIOBE top 50. Two of them (Apache Groovy and TypeScript) don't appear in the TIOBE top 50 so it's pushing credibility to call them "mainstream" languages -- the Java-ecosystem bias is more than "only slight".
My other hobby is microcontrollers, and I would love it if I could run Rust on my ESP8266. I can already run MicroPython, but it feels a bit hacky (probably unfairly), and it would be amazing if I could use Rust and easily link in all the C/C++ libraries the Arduino framework has available.
I know this reply isn't useful (I miss all the libraries, woo), but it's as specific as I can get. I started a very simple website uptime monitoring service:
https://gitlab.com/stavros/panoptes
I didn't get very far before the difficulty of integrating Diesel just stalled the whole thing.
IIRC someone is working on the ESP stuff...
> I know this reply isn't useful
Naw, it's all good: it's just as much about qualitative as quantitative. It's also because I'm writing a small framework in Rust in my spare time, so "rust for web" stuff is extremely top of mind for me. Thanks for taking the time :)
That'd be great, because I currently can't find a niche where Rust is so much better than Python that I won't just fall back to that, impeding my Rust progress.
> IIRC someone is working on the ESP stuff...
That's what I heard too, but progress seems stalled. Hopefully, in the end, it'll be easy to run on the ESP, but the biggest problem is the ecosystem (which is also much of the reason why I don't use micropython all the time). There are so many libraries for the Arduino framework that C is hard to escape.
One of the advantages of compiling to C and C++.
> This is an experiment for running Nim code on the ESP8266 ("NodeMCU") microcontroller. The end goal is an extendable framework on which to build autonomous ESP8266 applications, along with an associated web service which acts as a base station providing back-end message aggregation and front-end information display/control panel.
Out of curiosity: You use Nim professionally? Do you work for a company? What kind of software do you make? And what sort of people or organizations are your customers?
I remember that debugging it was a bit of a pain if just not a real option then. Maybe things have changed.
I wonder if python 4 could make this happen.
The thing that eventually makes me grab Go time and time again is how damn easy it is to drop into code of some library - even (and maybe especially) the standard library, something I rarely did or do in any other language. With Go there's little friction to do this, for multiple reasons. The source of truth for pretty much any project is almost exclusively Github, godoc.org documentation has links directly into the source-code for every single function and struct, and it forces you to set up a dev env that let's you understand it's structuring, where your libraries and it's code will end up. About the last part I had some mixed feelings at first, but after a while you appreciate it that the libraries you're using aren't tucked away somewhere in some system directory. Add to that that Go is a simple, pretty readable language, and you end up with a very transparent library system. Would I ever even think about jumping into the paramiko library (which I used on multiple occasions)? Not at all, so I didn't. The first time I used the crypto/ssh lib, I also didn't think about jumping into the code, but somehow, I did because it was the natural thing to do, and made me understand the internals and SSH a lot better (paramiko was slightly easier to get started with though).
Another thing I really like is that the language encourages not writing 'applications' but rather libraries that can be reused by virtually anyone, and your final application will be a relatively small front-end shim for it. While this is not hard in Python, creating a separate library for smaller stuff somehow always felt as overhead, while in Go it feels like the natural thing to do. In python, there's yet another ton of overhead if you want to add something to PyPI - while in Go it's a `git push` away. This also creates serious issues and pitfalls, but it makes contributing a library a lot easier.
note that it is possible to pip install from git repos and it's actually very easy. you're just not expected to have to do that :)
I’m not criticizing Go since I have no LoC in it, but in other restricted-and-flat languages and areas our company’s expertise quickly (read: in half a decade) went to the limit with no chance to turn the lang partly into dsl and level up. It is like playing rpg where you stuck to level 5 and never get powerful enough to take middle-level quest even with a great party.
While it seems cool to have automatic jsonification, build process and out of box concurrency, inability to create something that only your team can use and understand effectively means you’re locked to growing markets (bubbles) and never have real expertise and/or budget over bloated competition. This may play a bad game with your future, should roads cross with one who has.
Again, the type I’m talking about must be rare, and “there is only one opinionated way to do it” seems to fit better on average tasks.
Could you unpack that a bit further?
By "inability to create something that only your team can use and understand effectively", do you mean "inability to create something really powerful"? As it stands, it sounds like a good thing.
As for "'there is only one opinionated way to do it' seems to fit better on average tasks", from the Zen of Python: "There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch." And Python has been used to do plenty of above average tasks.
Keep in mind that the Zen of Python is mostly about how Python differs from its ancestors (basically, Perl). It's not a work on software engineering.
To get a sense of it, take a look at a failing test in a language such as Python that uses asserts for testing and compare it to the equivalent written in Go. Quite often, the error message in Go will be clear and to the point. On the other hand, I've seen plenty of assertion based tests in other languages that report inane things like "1 != 2" or "true != false" when they fail.
Go encourages putting the effort into this up front. It pays off later when things go wrong and you want to know why.
You can get there either way, but what you're used to weighs heavily.
For your example, depending on my experience, knowing that 1!=2 in some code I'm using directly might be more meaningful or actionable than "out of filehandles for accept()" in some deep chain of dependencies I know little about. Just depends on what you're used to.
But I think the bigger point is that, for libraries, errors should be an enumerated set of possible error conditions, not strings. You say "additional structure", I say the duplicate filename, the invalid email address or, crucially, the error that caused the error...chaining errors is very useful. The multiple returns idiom in Go may make this possible, but it's hacky and strictly worse than languages that can utilize generics and a more richly-typed set of errors.
It's often easier to fix 1!=2 if I know the entire error stack than it is to know exactly what happened where, but not the path down.
Like as obtuse as 1!=2 is, with exceptions, I might more easily recognize it as a reference leak.
This is common for things like map access. See an example here https://play.golang.org/p/P3k5tgFLd2
In Python, one would need to supply the message argument to avoid that. But Go seems no different, really; you still have to supply the message. My understanding of the testing package is that Python's:
self.assertEqual(expect, actual, f'expected ({expect!r} != actual ({actual!r})')
if expect != actual {
test.Errorf("expected (%s) != actual (%s)", expect, actual)
}
I do wish Python could figure out something better than "1 != 2", s.t. the assert would just do The Right Thing™ in a graceful way, but doing so would require facilities the language hasn't got (e.g., some macro capability). There are some packages that do some black magic stack walking to do slightly better, IIRC.
To me, Go's error handling falls a bit short because it is possible to forget to handle an error (though thankfully that unused variables is an error makes this more difficult), and you don't get an error or a result, you always get an error and result. (The language lacks a sum type, so it can't really do much better here.) It's on the programmer to not use the result, and to me that felt and still feels weird. The constant do-something, check, propagate is thing, too … I had hoped C had beat that out of language design as too tedious, frankly. (C.f. Rust, where even though error propagation is always explicit, it was `try!(foo)` early on, and `foo?` more recently.)
x = 1
y = 2
items = [4,5,6]
assert (x+y) in items
test.py:4: in <module>
assert (x+y) in items
E assert (1 + 2) in [4, 5, 6]An error message like '1 != 2' is a lot more meaningful when it's reported as the reason that test_new_foo_has_2_bars failed. Occasionally it's nice to give a more explicit message, which is why in eg Python you can optionally supply one, but it's not generally an issue if every test is really only testing one thing. To me, the Go approach seems to encourage writing cluttered tests that test several things at once.
The biggest reason for me is the inability to get stacktraces to where an error comes from.
Let me give a specific example where moving to Go really helped our tooling:
Go has some great interfaces, specifically their net & ssh client. In order to perform operations against some machines, we have to tunnel through bastions, however we'd also like the tool to work when an operator has already ssh'd within the region (the tool is installed on hosts as well -- so that long running tasks can be performed).
It was easy to create HTTP clients that easily tunnel through an SSH connection via Go's Dialer interface (present in the net & ssh package) or just directly if no tunnel was needed.
(In this particular case I did not vote on the OP.)
I don't use Go nor Python but still thought the article was interesting.
> they don't have much specific information except very generic "developer productivity"
They give you a lot of reasons but in reality choosing a language is seldom about arriving at a scientific conclusion and much more about what feels best. Just like choosing a dish at a restaurant.
That basically confirms the strength and weakness of python : it's very good for prototyping and if performance issues arise (and that can be later than one think), it's tough to optimize.
Additionally, a lot of performance issues can depend very much on what libraries are used.
I'd like to see both apps for comparison / more context.
Either, the database is the limiting factor (and thus, languages like Python are fast enough, anyway) or the really performance demanding parts are located in <5% of the coding.
In my case, I enjoy the productivity that Python gives me and if I encounter such cases, that demand very high performance, I implement them in C or with Cython (or both).
If, later in your project, you'd have to add GPU computations to your software, would Go still be a better choice than Python?
You are right in 90% of these post they are shallow this one was really a good read.
Modern Java and Go are so much faster than the alternatives that it's stupid to consider anything else if performance is important.
Golang and Java can manage over a half million HTTP responses a second. Node is pretty fast but why bother when Java is many times more mature in features, tooling, and and supports concurrency... And uses less ram and is usually faster. People moan about the "huge" Java runtime when JavaScript uses 3-5x more memory and has a huge runtime of its own.
All the big companies are using Java and Go almost exclusively for high volume endpoints and it blows my mind the amount of mental gymnastics some companies go through to avoid following suit.
Java has come a long way since J2EE. These days it's asynchronous, non-blocking, serverless, etc.. pretty much all the acronyms thrown around about node except its not JavaScript, which IMO is a huge win.
This leads to a lot of "first languages" being the latter and a perpetual glut of recent grads that know nothing else so will do those jobs for less
My personal experience is that the dynamic languages you've laid out generally have frameworks that are extremely conducive to rapid prototyping (Django is my favorite). I've seen and done the dance many times -- start with a Django/Rails/Laravel app, get a free admin and build up some CRUD pages in no time flat, and then once you've got enough traffic to care, move parts of the application to more performant platforms (Go/JVM usually) as necessary.
That's a serious question: I find it's often hard to tell what the bottleneck might be in these applications.
A python application can be anywhere from 10x to 50x slower than a native application. It also probably consumes at least 5x more memory.
Writing the same app in a compiled language is not even an optimization. It's just baseline work to ensure the code is not super slow.
Like, if you know you will sort a list of 10 items, choosing quicksort from the stdlib instead of bubble sort is not even an optimization. It's just common sense.
For concurrency (number of requests handled at once) instead of speed (end-to-end time of of a single request)
Why waste 10x more memory?
That sort of question is totally missing the point of why people use these languages, yeah? Languages in the web world don't tend to be chosen based on memory requirements (or speed as this suggests). Are there cases where you want to think about that? Sure.
People have plenty of reasons they'd want to use Python over Go, and vice versa.
"and vice versa" < Sorry, but no. There's no equivalency here.
The only reason I would ever use python is for small scripts that I only run on my machine and don't need to deploy anywhere.
Maybe 10 years ago Python was an attractive language because Java sucked and C# only runs on windows and there weren't many other good choices.
Now there are many expressive languages that are also statically typed and fast. D, Swift, Kotlin, etc.
Java is the only static language that features roughly equivalent levels of support ecosystem wide.
Good luck getting more than 100 calls per second out of the slow languages
Anyway, if you're locally looping for hundreds/thousands of queries to the database, instead of writing one query or calling a stored procedure, you're probably doing things wrong.
Java/Go with pretty much any database can manage about 50,000 individual queries+REST calls a second.
https://www.techempower.com/benchmarks/#section=data-r14&hw=... has some interesting benchmarks, apparently we should be using Dart or C++. Go does slightly better than JS but not a lot. Some newer Python frameworks aren't on there yet. None of them reach near 50k, but I don't know the details of the benchmark and they aren't all using the same DB. Certainly you can get crazy numbers depending on what you're testing. e.g. https://github.com/squeaky-pl/japronto gets one million requests per second through async and pipelining but those requests aren't doing much.
And you can make Python or even PHP fast if you try hard enough.
My argument is that the engineer overhead for Go and new breeds of Java frameworks are small enough that it makes no sense to use anything else if you're planning on scaling for real.
If you start with something else the cost of making a slow language fast and the multiples of extra machines you need costs far more than just using the faster language to start with
For the benchmark you posted, take a good look at the "realistic" vs "stripped" implementations and whether the test used an ORM. You'll quickly see that the realistic test applications with any kind of ORM are exclusively C#, Java, Go, and C++
Cost difference is another topic. While servers can be cheaper than developers, saving 90% of server cost can definitely clear some budget for enhancements.
You answered your own question. Why bother with those languages when the language isn't the bottleneck? In those cases, what language one uses becomes an entirely subjective matter.
> All the big companies are [...]
For every large company using Java, Go, Rust, C, etc. There's another one (hell, probably the same one) also using Python, Ruby, PHP or JS.
Arguments about what language is better are pretty flamey but it's hard to argue that performance is not an advantage of Go/Java
And I never even remotely argued such a thing so I'm confused as to why you are saying this in reply to me.
Reddit has some scattered Engineering blogs and my insight into youtube comes from a previous HN article by the author of GrumPy (who works on youtube at Google) in case you're curious.
Erlang is much slower in raw performance than both go and jvm: https://benchmarksgame.alioth.debian.org/u64q/erlang.html
Async approache similar to Erlang was reproduced for Java and Go already: https://akka.io
But it also has native coroutines embedded into language, which provide excellent asynchronous performance.
It'd be great if there were better benchmarks for common use cases of various languages. Spring on the Java side tends to be heavy on reflection usage, which is orders of magnitude slower than JIT'ed JVM methods. Benchmarks like the benchmark game don't capture this. Still despite that the Erlang VM performs very well on the benchmarks game compared to other dynamic/scripting languages. Often it's easily 5-10 times faster than Python or Ruby. Given the parents comment, I'd argue many programmers who enjoy developing with dynamic languages can do so with Elixir with comparable performance to Go/Java for high concurrency web applications.
Somebody should make those.
(People may have different ideas about which use cases are common).
As you can see, erlang is far from the top there.
However it gets more interesting if you look at the Latency tab. There Phoenix comes in with an average of 7.9 ms. In comparison Gin averages 5.8 ms, Spring at 12.1 ms, Flask Py3 at 23.1 or Py2 at 14.7 ms.
Where it's really interesting is looking at the max latency. Presuming this indicates roughly how 99th and 95th percentiles measurements would compare. In this category Phoenix comes in second with a max of 22.0 ms, behind only lib-mongodb at 20.8 ms. The lib-Mongolia is one of the fastest frameworks by raw req/s.
Appreciate the link to the benchmarks! Much more interesting, especially if you're concerned about max latency (and likely 99/95 th percentiles). In this case BEAM/Phoenix would let you plan capacity to minimize max latency fairly well as it appears very consistent.
But raw java servlets delivered 100+k req/s. It may mean that all this event loop/async/actors hype is overrated, and regular blocking approach can also deliver.
… and "Most (all?) large systems developed using Erlang make heavy use of C for low-level code, leaving Erlang to manage the parts which tend to be complex in other languages, like controlling systems spread across several machines and implementing complex protocol logic."
FAQ 1.4 What sort of problems is Erlang not particularly suitable for?
First: Because squeezing every last nanosecond's worth of performance out of your web app is actually an extremely rare problem to have. And if you truly cared about performance over programmer convenience, you'd practice what you preach and build your web apps in hand-rolled assembly, but I'd bet a lot of money that you don't do that.
The typical web application -- I'd be willing to bet over 99.999% of all deployed production web applications serving requests today -- has a bottleneck at the database and the network that dwarfs any overhead from language performance.
I remember a bit over ten years ago when there was debate in the Python web world about which templating engine to use to generate HTML. And people argued endlessly over microbenchmarks of them, to figure out which was fastest, but I remember one blog post which showed a pie chart of time spent in the average request/response cycle. Nearly all of it was accessing the database, and template rendering was a tiny, tiny sliver, so the author humorously labeled it "obviously this is the part we need to focus all our optimization work on". Language choice is similar.
Second: Because what else your company does matters. Where I work, web applications are how we expose data and interfaces to that data. But there's a gigantic stack behind that, of data intake, data parsing, data processing, analytics, the whole nine yards. It's all in Python, because Python has hands-down the strongest ecosystem of any popular programming language for that stuff. So the web applications which serve as the interfaces to the data are also written in Python; it means we have one language to worry about, one language to work in, one language every software engineer knows. I've been pulled onto projects doing things that didn't involve web applications at all, and I've been able to be productive because those projects were still in Python, and I could read code and get up to speed on what was happening, and take care of mundane things for a more domain-experienced person whose domain expertise was then free to apply to things I couldn't do.
Third: Because programmer convenience really and truly does matter. When I first started doing this nearly twenty years ago, people posted comments like yours, incredulous at the idea that someone would use PHP or Perl given their performance characteristics compared to Java (or C -- plenty of web apps used to be written in C!). But even then we knew: servers are cheaper than people. The average salary of a quality software engineer (or "web developer" as we were known then) would buy you a lot of compute time, either on your own (in-house or colo'd) metal, or nowadays on someone else's cloud.
So you choose based on convenience to humans. PHP, for all its faults, was an incredibly convenient language to write web apps in, and compared to the usual CGI model that preceded it, was a breath of fresh air when it took off. Today, frameworks written in Python, Ruby, PHP, etc. are similarly in a good position compared to more heavyweight things like the Java world (which for better or worse is still suffering the lingering effects of its mid-2000s "enterprise" reputation), or even Go (which is still young and still seems to come up short, both language- and ecosystem-wise, on some of the things actual working web programmers want. In particular, programmer-friendly ORMs in statically-typed language really really really want generics or a good equivalent, and Go's historic attitude toward that has not been great.
The performance gain from Python/Ruby to Java/Go is an order of magnitude larger than the performance gain from Java/Go to assembly. The productivity loss from Python/Ruby to Java/Go is an order of magnitude smaller than the productivity loss from Java/Go to assembly.
Therefore, going from Python/Ruby to Java/Go might be a good idea for web apps, but going from Java/Go to assembly is virtually never a good idea for web apps.
Common Lisp, Scheme, JavaScript, ML variants come to mind.
Having been part of a startup that used a dynamic language without a world class JIT/AOT compiler (Tcl) back in the first .COM wave, teached me to never do it again.
Or a bottleneck in a process which can be optimised into better data structures. Changing the language can only lower your constant cost and the scale - it will not change the complexity on its own, so it should be really the last resort.
A language is not just about overhead, it's also about capability. For example, your database is slow, and your web page needs to render by executing 20 queries. Will your programming language allow you to parallelize those queries? While your database/network may have high latency, they can still have good throughput.
This particular example is very real, and is incidentally relevant to the original post, since Python and Go implementations have different capabilities.
I have seen MS SQL server handle over 10k database queries per second on a regular machine in a real, huge application (over a million lines). Can Python handle 10k queries per second? Definitely not. In Java or go that load could probably be handled by a single AWS box that costs $10 a month.
I have never seen a database maxed out that wasn't stuck because of table locks. I've seen applications like WordPress die at 10, requests a second
Secondly, the majority of websites that make up the Internet (and Intranets) are not serving 10k/second. They're serving a 100th of that.
Third, because your database can handle 10k queries, and your database can aggregate and manipulate data, and it's optimised to do this -- it might be a good idea to perform these functions at the DB-level, as opposed to the web application.
Finally, as stated previously, for most businesses, it's easier to buy more beefy servers, or get a more experienced PHP dev (that understands how to optimise code) than it is to find a Go programmer.
Higher level languages might offer lower raw performance and more bugs. But they offer more features per dollar.
That isn't really specific to programming. You might also wonder why McDonalds is popular, even though their food is...meh.
Please cite “all the big companies.” Also exclusively? No seriously, that is a bold claim. Google isn’t one of them because most of those hotepots are still written in C++. I don’t know how you can claim this. Based on some occaion company blog posts, changing just one or two endpoints out of say 100?
What about Rust? I also know companies rewrote some hotspots in Rust too.
Easy to find out just by looking at their open job positions.
Microsoft is an exception because they built C# which is basically a more modern but less popular variant of Java. There was even a project for a long time that let you use Java code in C# projects by converting the bytecode, they're that similar.
The notable exception is Facebook. They were stuck in PHP hell for so long that they redesigned the language to make it work.
My current company has 15 Java & React engineers where 2 or 3 Rails would suffice. Load tops out at maybe a dozen requests/second. Feature development is super-slow. System complexity is off the charts.
That probably has little to do with language/stack and everything to do with constantly changing requirements/system growth.
To your required engineers comment, Spring Boot + jOOQ is easily one of the most productive backend stacks I've ever used. A single engineer could easily build a large API leveraging the stack.
If you're only using them for a REST API they offer similar features. Spring Boot supports loads of other stuff you probably don't need for something API driven
Because mature companies in competitive markets live or die by operational cost effectiveness.
Growth-phase companies or one with moats live or die by other means; if they are around long enough and are targeting a valuable enough market, they'll eventually probably be a mature firm in a competitive market, but a good way not to get there is to focus on the needs that such a firm would have rather than the needs the firm they actually are now actually has.
I think people obviously enjoy using Python/Ruby or whatever for small scripts, and by inductive reasoning they think they can enjoy programming even larger projects in these languages.
They also rationalize the slowness by pretending that performance doesn't matter or that the bottle neck is the database.
They abuse the adage about "premature optimization" being a bad thing. Not realizing that while it's stupid to prematurely optimize everything, it's equally unwise to write everything in a slow language. Using a fast language is not premature optimization; it's just the basic thing you need to do in order to not have a crappy optimization, which is a good thing , and everyone should do that.
Or, you know... You can actually measure those things. And unless you're growing like crazy, or have a massive initial audience, you're likely to find that 90%+ of the app time is spent in the database and your CPU time isn't even close to maxed out.
Why would you assume people would pretend any of that is true?
[0]: https://www.slideshare.net/Blaine/scaling-twitter/3-First_So...
Also, if your audience is small enough that a slow python can suffice, why even bother using a database server such as postgresql or mysql when you can just use sqlite and simplify the architecture?
EDIT:
[1] It's been 10 years since 2007 but people still do this more or less all the time. Write a webapp in js/ruby/python and spawn 20 instances of the application server
Recent benchmarks of a properly setup Ruby environment vs Go/Gin are showing Ruby/Sinatra as having 50% of the throughput https://www.techempower.com/benchmarks/#section=data-r14&hw=...
You can also just use JRuby and use a single JVM process. For small CLI apps, MRuby can even be compiled to C, then compiled as an executable.
If you want to do anything interesting, Python/Ruby are slow as hell, which is why you cannot do anything interesting in them.
For example, while in Go, you can load say 1000 rows from the db and perform some data manipulation on it in the code to get a desired result, you cannot do this in Python because it will very very slow.
So what you do is you write complicated sql queries and essentially offload all your work from the application server(s) on to the database server.
Now imagine that these rows on the database don't actually change very often. You could just load them once, keep them in memory (in a global object), and only update them once in a while (when needed). You can always do whatever search/manipulation operation directly on the data that is readily available and always respond very quickly.
This would be _unthinkable_ if you are using Ruby or Python, so instead you keep hammering your database with the same query, over and over and over again.
Is Python/Django performance significantly worse than Ruby/Rails? The situations you describe are things I do every day in Ruby. Getting 1000 rows from the DB and performing some operation only takes a couple of milliseconds in Ruby.
Ruby/Python are meant to be glue, and you can most certainly use them to glue together "interesting things", like image processing or audio processing in a web layer.
Memory caching rarely changed, often accessed, but ultimately persisted in a DB things like exchange rates in a global object is exactly what you do in Rails. There's a specific helper for doing it. http://api.rubyonrails.org/classes/ActiveSupport/Cache/Memor...
It's similar with Ruby/RoR - yeah, they can do async. But not on their own. With unicorn server, you still get no threading and just a bunch of processes. With puma you can do threading (async cooperative really) - as long as you keep the configuration/code within the limits of what's allowed.
And due to the extra care needed whenever you do caching/storage things, I expect unicorn is still the king in RoR deployments. (GH uses that for example)
What about memory usage? That's an un-appreciated axis, IMO: for example, all of crates.io takes ~30mb resident, which is roughly the overhead for MRI itself, let alone loading code.
Anyway, the Rust team loves helping production users succeed, so if there's anything we can do, please let us know!
You will have to close that IT-only part of your brain for a moment, and keep in mind that people create software for a reason. And every nascent project lives or dies by how promptly it adapts against incorrect assumptions or changes in the environment.
Difference in hardware costs do not even enter into the radar. They happen in a different universe that good decision making completely ignores at this point.
After you have a proper solution to a problem, and enough scale so that it's worthwhile to collect those gains, you move your software to another language. It's not a big deal.
FWIW, it always seems like a mostly zero sum game to me. Whatever efficiency you gain in using (e.g.) Python+Latest Frontend Framework+Backend Framework, you lose through having to wade through yet another set of new concepts and documents for those frameworks.
For me as a Python/Rails/C++ dev Java has a reputation of being too large, too complex and otherwise.. unwieldy.
Hearing things like "To test a bug I had to start 6 services on my computer and then I ran out of memory (computer had 16GB)" doesn't encourage me to try to do web dev in Java.
Wicket is a true OO approach to GUI which is quite different from the page-template style of Rails/Django/..., but I find it makes for much more compositional style, with lots of small reusable components that are just compositions of a few smaller components. And while not being able to monkeypatch everything can chafe initially, when you come to upgrade to a newer version of the framework you'll really appreciate the safety a compiled/typechecked language can offer.
Spring (with Spring Boot) has approachable tutorials [1] on how to get started but will get intimidating pretty fast.
I highly recommend using Kotlin instead of Java when trying out the JVM, though.
[0] http://sparkjava.com/ [1] https://spring.io/guides/gs/rest-service/
These days, i write most of my applications using the JDK's built-in web server. They're intended for internal use by single-digit numbers of people, and it works fine. It doesn't give you anything except the ability to serve HTTP, though.
Before that, i was writing apps using Spring Boot, which is a framework covering pretty much everything. It's easy to get started with, and requires no XML, but gets complicated fast as soon as you want to do anything even slightly unusual.
A more production-grade alternative to the built-in web server is Undertow, which again just does HTTP, but is fast and scalable, and fairly simple:
http://undertow.io/undertow-docs/undertow-docs-1.4.0/index.h...
Some people swear by Dropwizard as a more lightweight but still framework-sized alternative to Spring:
http://www.dropwizard.io/1.2.0/docs/getting-started.html
The tutorial there uses a smidgen of XML for Maven, but that's all. You can use Gradle instead of Maven, which lets you avoid XML and is generally much better, but you'd have to work that out yourself, or find someone else who has, perhaps this person:
http://automationrhapsody.com/build-dropwizard-project-gradl...
There's also Java EE, the 'offical' framework for Java. It's actually not bad to program with, but you need an application server to run your apps, and although those are miracles of engineering, the user experience is still stuck in the dark ages.
> Hearing things like "To test a bug I had to start 6 services on my computer and then I ran out of memory (computer had 16GB)" doesn't encourage me to try to do web dev in Java.
If you need to start six services, you must be doing some kind of microservice / SOA thing, and if you need >2 GB for each service, you must be using some very heavy-weight application server. Neither of those things are smart, and in combination, they're deadly!
One especially useful feature in Pyramid (and some other Python frameworks, Flask, Django etc) is the debug console, when I get an exception somewhere, then on the 500 page I can see the call stack and get a shell at each line in the calls stack, print the variables, view the last n requests, see the request variables and so on.
Really though, you should invest some time in learning typescript and react. These days most apps are just API calls on the back end and you deal with templating, forms, and other bs in the frontend.
Because most apps are built this way now, you won't find any "modern" Java frameworks that support what you want, and you're pretty much gonna be stuck with the older clunkier stuff.
The learning curve for new SPA frontend stuff is high but I've found it much more productive now that I'm into it. With HTML generated on the server it's too damn hard to get pages to do what you want
It's important to remember that Java has been around for 20-30 years and it certainly has not stood still. Many of the complaints people have are from Java of 10+ years ago.
Exactly. I spent about 5 years away from Java after J2EE made me swear it off. I learned a bunch of other languages and frameworks and recently went back. Java is awesome now. Unlike 5 years ago is relatively easy to avoid all the clunky old crap if you want to.
The new generation of Python web frameworks is pretty fast (check out Sanic[0][1] for example), Python has a huge growing ecosystem, you get rapid time to marked and if you find some part of your application to be the bottleneck, you can replace it with C/Rust, which you probably don't need, because your company won't ever scale as far.
[0] https://github.com/channelcat/sanic
[1] https://magic.io/blog/uvloop-blazing-fast-python-networking/
For large web apps it's still pretty much a nonstarter unless you want to not be able to take full advantage of libraries like sqlalchemy.
Nodejs had a great advantage by starting with asyncio from the beginning.
M:N threading would have been a much better fit, though that's out of question given the GIL.
Java and Go are terrible.
Simple as that.
Maybe they have better tools for managing package dependencies but Go doesn't have to deal with interpreter dependencies, which can be a major headache. Go also doesn't have the problem of conflicting system level packages.
Honestly no matter how good your deployment practices are, if you have to manage an application's deployment long term you're going to have dependency problems of some kind. I'd rather deal with those problems at compile time than hit an edge case during deploy or in prod.
Sure, as long as you're not using CGO and dynamic linking. Otherwise you'll get the exact same problems as the others.
> Go doesn't have to deal with interpreter dependencies
As long as Go is forward compatible this will old true, but I don't think this was the point of the comment.
'go get' is a half-baked package manager and yes it fetch packages and resolve dependencies between packages so that's a package manager. It just doesn't care about versions. Other languages have solved the issue by requiring a third party tool, Ruby even has its own build tool.
There is a reason why some gophers are working on an actual package manager...
Finally! I had to deal with a golang project once, the dependency management made me want to pull my hair out after using Bundler and Cargo
Not even then, to be honest.
I wrote a product that is deployed on many thousands of servers, and all of a sudden a not-insignificant population just started experiencing SIGABRTs on process start.
Turns out Amazon Linux (and some others) had removed a syscall that i386 Go on Linux was relying on (https://github.com/golang/go/issues/14795). We built our product with a manual patch against "src/runtime/sys_linux_386.s" for many months as a result, and it was really a huge headache to help all our customers.
I would be surprised if Python or even Java broke in this way, for example. I was really surprised it even happened in Go to be honest.
There are other runtime problems too, we had a weird interaction with a "cloud OS" based on cgroups (CloudLinux) screwing up our Go processes depending on how many goroutines we ran ...
I think Go is fantastic but its runtime can definitely clash with its environment ... it's not the same as a C program.
In Python, if you have control over the target system, this is solved with virtualenv. You can install whatever versions of libraries you want in there with pip without causing conflicts with system level packages.
If you intend to ship to end-users, yeah, you are kinda screwed. You are stuck using one of the various "freeze" methods, which, in my experience, kinda blow.
For context, you can install opencv, tensorflow, ROS, matplotlib, and the entire scipy stack in a virtualenv, with no external dependencies, using wheels.
This means that you can generate images, train a machine learning algorithm on them, compare the results to conventional CV algorithms, and display them in an ipython notebook all from a venv. There's a huge amount of C++ and even qt integration in that pipeline, all isolated.
It won't be maximally performant (ie for massive training), but for that you'd want distributed docker deploys or similar anyway.
Should someone have changed the Python build tool to be 2.7 or 3? Maybe if they were bored and new it was something that needed work or wanted to be good tech citizen. However, what really happened is that no one even knew what the tool was really doing, just that it was part of a suite of tools in a build process, and no one would have looked twice at it ever again had wheel not removed support for 2.6. /me shrugs.
I mean it totally would if the binary dynamically linked against a file you didn't have on your system, which is exactly what happened with `wheel` (python 2.6 doesn't have OrderedDict, which wheel now uses).
IIRC, we also had a problem where a wheel failed to find symbols in a SO it was linked against. It turns out that the wheel worked fine in precise, but failed in trusty, and we ended up having to split our wheel repository because the wheel was specific to the Ubuntu release. (It seemed, at the time, that whatever SO it was linked against appears to have made backwards incompatible changes without changing the major.) There are rare cases like this where the wheel is unique to attributes of the host that the wheel metadata can't capture.
And with the wheel packaging, you're free to embed that library in the wheel that depends on it. You can also not do that and rely on the system libraries. The wheel provides you a way to do what you want, but doesn't force you to do it.
The are good reasons for either of those approaches, so I'd say wheel does solve the issue.
What you say is correct, virtualenvs are not free from external dependencies always, but correctly build wheels are. Wheels and virtualenvs aren't the same thing.
And ros doesn't even need to be a wheel fwiw, its pure python, but its also just a painful thing to deal with for many, so it was worth mentioning.
Except when you run into edge cases, which happens all the time.
So it's why a lot of teams will use either Vagrant / Docker to setup local developer environments.
Also some of the data analysis packages don't work with virtualenv.
Erm... Why the heck are you running pip when deploying software? O_o It should be a build step, not a deployment step.
Yes, avoiding learning how to properly package and deploy your software is totally worth this cost.
I think Heroku also played a role in prolifirating the idea that you can just push your code (from a git repo) to a server, and the server will take care of deploying it. Which usually means the server will install all the dependencies from pip during the process.
That's one of the things I prefer about Go: the compiler can cross-compile, so I can compile the entire codebase on my osx machine and produce a single statically linked linux binary that I can just copy over scp to the server. Deployment becomes infinitely simpler.
Also, most programmers don't know a thing about administering servers. Ubiquity doesn't mean that it's a proper way, as you clearly see yourself.
> [...] the python toolset encourage this kind of approach by making it the default easy thing to do.
It's not quite the fault of Python tooling in particular. It's really the easiest way in general. Similarly, the easiest way to deploy a unix daemon is to run it as root user, because the daemon will have automatically access to all files and directories it needs (data storage, temporary files, sockets, pidfiles, log files). Anything else that is easier to manage requires to put a non-zero effort.
> That's one of the things I prefer about Go: [static linking]
Static linking has its own share of administrative problems. It's not all nice and dandy.
I don't have specific examples in mind but I've had a lot of frustrations with virtual-env.
Working with nix is also not very easy; docker might fare better here, but probably just a lateral move. In any case, Go outclasses Python on deployments. Also, my company is looking into compiling Python as a means of code obfuscation; Go compiles by default, which (modulo stripping) is probably enough obfuscation for our purposes.
I need to try Go one of these days !
The issue with different Unicode builds was fixed 5 years ago, in Python 3.3:
https://docs.python.org/3/whatsnew/3.3.html#pep-393-flexible...
Wasn’t that solved years ago?
The fact that go's Math functions only work with floats. Idiotic.
You have so many packages that have to add the same freaking min(int a, int b) function.
The only 3rd party library I pull in to build web servers is gorilla (routing, sessions) and a database driver .
Everything else you need is in the go standard library .
Are you telling me that Python helped you create a viable tech-oriented newsfeed and activity stream business, serving 500 companies and more than 200Million "end users"? That sounds like a great incentive for any entrepreneur to get started with Python.
You've gotten this far by using the language you've turned away from! Further, I'm confident you didn't solve every challenge you've had on your own but rather did so with the help of the worldwide community of Pythonistas who answer questions and help to solve problems.
It takes a village to raise a startup. Don't try to burn the village down after you've grown up and can afford to explore other villages.
However, for the API we've outgrown it in performance requirements. That's what the article is about, together with the things we found during the switch that we liked and disliked about Go.
Also, the reason we even considered a language switch is that we had performance problems related to our core design. Because of this we decided that we needed to rewrite most of our API code based on a new design. This required rewrite made us consider switching languages. Eventually we chose to rewrite our whole API codebase in Go for all the reasons in the article. (we did a small trial project in go first to evaluate it)
1) recommends Django or Rails for CRUD apps 2) mentions a lack of frameworks in Go as a negative
It's a good article and not a rant about which language is "better"
i guess after companies reach a certain size, they can go beyond choosing a programming platform for its ecosystem
and then they have reason, is being used heavily in messenger
https://reasonml.github.io/community/blog/#messengercom-now-...
For those of you working with Go. One of the guys on our team wrote a little tool called VirtualGo. It's pretty handy when you're working on multiple go based projects (https://github.com/getstream/vg)
A good language enables you to "compress" your code without making the code flow impossible to follow.
A bad language encourages you to obfuscate the flow of the program using wacky abstraction techniques.
Go doesn't exactly hit the sweet spot for semantic compression due to lack of compile time programming (aka generics?), but it does a good job of making the flow of the program pretty clear.
a.insert(i, x)
a = append(a[:i], append([]T{x}, a[i:]...)...)
Although I agree with you about some basic things in Go such as insertion being somewhat crazy, but there's a point I want to make about abstractions.
Abstractions that hide too many things away are not always a good thing.
If an abstraction makes something easier to write, but harder to read, that's not a very good thing.
Unfortunately Go does not exactly hit the sweet spot. It errs on the side of less expressive power.
EDIT:
Actually, for inserting into a list, the code can be simple, although the line will be split into three lines, and creates a new temporary list
// insert number 10 into position 2 var b []int b = append(b, a[0:2]...) b = append(b, 10) b = append(b, a[2:]...)
https://play.golang.com/p/ommopBd3io
Now, that _is_ overly verbose, but I don't think it's too off putting. I don't like it but I guess it's a quirk of go I'm willing to put up with.
I just don't get the appeal. Go seems a lot like what you'd get if you just removed every language feature that anyone has ever complained about; for good reason or not.
I'd also like to point out that I write this a Python-phile that has come to the understanding that Python is great until it isn't. When Python becomes to burdensome, the understanding of the problem delivered by my Python sketch helps to narrow the focus of what I need to solve the problem efficiently. By that time, Go has never been the correct tool for me. I'm comfortable writing solutions in C, Rust and Java, perhaps this is my problem.
Whenever I read or write Go I don't understand how it managed to capture the mindshare that is has. Especially in the face of other technologies available, Go seems like a timid step forward in descriptions of computation, when there are bolder choices that deliver valuable additions to my development ecosystem.
I appreciate that Go places a premium price on simplicity, however with languages like Rust make some big steps towards static guarantees at compile time the guarantees that Go makes seem pretty weak. But I feel that when I make the leap from Python to Go, I admittedly don't understand the allure. Static compiltion is really nice! Statically linked binaries for distribution is very nice! The tooling is out of this world! Hands down, Go has one of the best out of the box toolchains I've ever encountered. But when helping me think about computation, Go doesn't.
Go's concurrency primitives don't feel like a great deal of a step forward compared to C. I know, I know, this is crazy talk. I feel like I am missing some great wisdom about Go, I truly do. Concurrency is really hard and Go has clearly helped a lot of people minimize concurrency problems. But whenever I use channels I am reminded Go does not allow me to shut my brain off, and whenever the deadlock bug strikes, I feel that I might as well be writing C.
I don't mean to disrespect Go and the great things it does, the opposite of that! I am hoping Go delivers a bulletproof abstraction for concurrency. Until then I've become too familiar with other tools to justify using Go for more than incredibly niche use cases. I really hope that will change (both my mindset and Go)!
Rust's static guarantees come at a price: You have to learn Rust to take advantage of them, which is apparently no mean feat.
> I am hoping Go delivers a bulletproof abstraction for concurrency.
Don't hold your breath. Go has always been and will always be about “good enough”, not “bulletproof”.
There is a time and place for these tools. A part of managing a team is ensuring there are good practices around "getting creative" and that there is a clear rationale. Python's metaprogramming came in handy for helping us provide a high level syntax to work with our data model.
Go makes up for this by making other stuff being easy and fast to code.
What do you think struct-tags are? it's not like Go is free of DSL either. In fact the std lib itself uses them. Let's not pretend Go is without fault on that matter.
Personally, I see a language like Go and Python as solving different spaces. I wouldn't write a lot of website business logic in Go, and I wouldn't write a low-level TCP redirection daemon in Python.
> Reason 7 – Strong Ecosystem
> Go’s ecosystem (...) it’s of course not as good as (...) Python.
Then why do you put that as a reason to switch?
> Reason 5 – Fast Compile Time
If you want static binaries, great tooling and an excellent imperative and functional language, try F# with mkbundle. The compelling reasons to use go are shrinking.
> F# runs on Linux, Mac OS X, Android, iOS, Windows, GPUs, and browsers. It is free to use and is open source under an OSI-approved license.
If only somebody wrote a nice ML that compiled to Go! I love a lot of things about Go, but the language certainly isn’t one of them.
There's clearly value in combining Go's compilation speeds, stdlib functionality, rich ecosystem, lean fast binaries, GC etc with a rich and cutting-edge Haskell-ish/ML-ish type system (and the leaner syntax and compressed idioms). Will be great for clear thinking and expressive high-level type-driven dev and DSLs (and naturally, implicitly generics/code-gen haha), without having to wrestle with GHC/cabal/stack build annoyances/times and Haskell's whacky academic overly-PhD-ish "wrappings" around raw straightforward real-world needs such as http-server and db-client, where again the Go ecosystem shines.
(Did you look at tuning the GC? As a Scala guy I know a some people write off the JVM because the default GC settings are optimised for throughput rather than latency (whereas Go does the opposite), when often their requirements are comfortably within what the JVM can do when suitably configured. That said I've heard the CLR is less tuneable)
I have high hopes for Pony, though.
I mean, sure, the Haskell's GC is a big downside, but if latency is so important that you have to look how the performance of you GC compares to an usual language, why don't you go with a language with no GC for once?
Because once you start to look at the details, you will need all of them, and how deterministic is Go's GC performance? What's its 99th percentile? What's the 99.999th percentile? Will any of those change in a future version?
In any case, .Net (and I gather Java) games typically go to considerable trouble to reduce GC pressure by pre-allocating memory pools and reusing them during execution. For certain kinds of games, like where you load everything in a level up front and don't deallocate until you finish, that can be fine. For other kinds of games, that's a nasty constraint to try to deal with. It ends up bending your architecture in ugly ways that make it hard to develop the game.
> Use MetaClasses to self-register classes upon code initialization
Avoid metaclasses....
> Swap out True and False
Not possible anymore
> Add functions to the list of built-in functions
What are the practical reasons?
> Overload operators via magic methods
Useful but also recommend don’t. I can see someone writting numpy would do that, but most applications don’t have a reason
Profile profile profile! Find the bottlenecks.
Good luck finding a Python library that doesn't use metaclasses anywhere!
https://github.com/requests/requests/search?utf8=%E2%9C%93&q...
I must mention that to the LVM developers dealing with my latest lost wakeup problem.
I use both Python and Go regularly and the use cases rarely overlap. They are both fantastic languages and once you realise what you want to use each one for, you'll be one happy developer. (Applies to many other combinations of languages.)
For me Reason 3 is exactly the opposite, if I have to spend time manually writing code that other languages give me for free, I am anything but productive.
C++ is famous for sluggish compilation speed, but Java is not. Java code compiles pretty quickly; it’s a simple language.
Now, if you mean "simple" as in, needs an IDE to figure out what other languages figure out in runtime/compile time automatically, then yes, it's a dumb language
Not to mention the library, which is a jigsaw puzzle composed of barely fitting parts that need to be connected in non-obvious ways to work and made by people who want to prove they know several design patterns and can apply then to any situation instead of something that's rational and straightforward
However the largest disadvantage of Java is Java programs generally consume more than 10x more memory than the same scale Go programs, and need 20x more time to fully to warm up.
I do admit Java is more consistent than Go from the syntax design view.
I think all new language design must incorporate this goal going forward. It’s been simply too valuable. When I see something introduced that does x, y incrementally better but makes no effort for the above goal I get sad and move on.
It’s easy to get caught up in the technical challenges of a language, but this meta challenge is what really helped move the ball forward with Go, and I’d love to see it introduced as a first-class goal in new language design.
I rather work in a language like Python or Kotlin where the code just looks like how you would think the code would like (if i would write it in pseudocode on paper)
However Go in big teams will really be nice. Thats why they invented it in the first place.
Most of the time, things only need to be fast enough and trading speed for ease of development, deployment, and maintenance is an easy decision to make.
i use python more, can't recommend mypy enough, it's great for what it is. it has warts, but that's to be expected if you add an optional strict modern type system to 20 years of dynamic language.
mypy is great, I use it in 'public' api's, tricky parts where context alone is inadequate and where I previously fucked up - the latter usually is a signal that the flow or abstractions can be improved to the extent that I can remove the typing hints.
mypy helps me, it does not force me to throw a goat into the lava pit to appease the compiler.
If the goal is convenience don't go with types. If the goal is robustness, use types.
The stdlib is globally well annoted now. However, most 3rd party libs are not.
It is in the initial stages, but so far it has been pretty good - both as a learning experience and from a developer productivity perspective.
I've also open sourced a web app boilerplate that I extracted from GrowthMetrics' codebase - https://github.com/olliecoleman/alloy. It might be useful for people looking to get started with Go.
What's the biggest, beefiest real world program yet written in Go, and how long does it take to compile it?
A quick glance seems to indicate that cockroachdb takes about 9 minutes [1] and infuxdb about 15 minutes [2]
[1] https://teamcity.cockroachdb.com/viewLog.html?buildId=380603...
On my system, building just the Go code for the latest version of CockroachDB (about 360kloc) takes 24 seconds.
Kubernetes takes about 16m: https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/...
[1] https://ci.freebsd.org/job/FreeBSD-head-amd64-LINT/buildTime...
[2] https://ci.freebsd.org/job/FreeBSD-head-amd64-build/buildTim...
If you use docker as part of your ci build the dependencies as a separate step so they can be cached between builds. This is especially important for libraries like sqlite, which can take a lot longer to compile.
That seems to be docker.github.io, the Docker documentation, not Docker itself (and not written in Go).
For portability there is shipping your a widget set (QT is OK for this if your licencing needs are compatible with either case).
My experience with the language (building multiple production systems) is that the language itself is sort of it's own framework. You don't need to add much to build an application with the standard library. Which is a huge plus and makes things simpler.
PHP has template rendering, routing, and database conns built right in too ;)
Am I reading correctly?
I'll stick with Python.
I use it at work, and it is awesome. It has awesome error handling (Either/Option >>> exception) on my opinion, a much stronger type system (many errors are checked at compile). It is harder to learn, but you also have top notch package manager with the even bigger scala + java ecosystem.
The only solid reason this article gave was the second one and, really, is the only one that would ever make sense: If the language one's using becomes the bottleneck then, by all means, change it[1].
Everything else is fluff and opinions. Every single other reason is stuff that is entirely subjective and/or python already has and even the article itself acknowledges, at least for one "reason", python as the better option.
Well, at least they tried to be impartial by mentioning the absolutely odious error handling in Go. It's the biggest reason I became so disillusioned with the language once I actually tried it.
[1]: I, however, would try switching CPython for pypy before rewriting the entire architecture from scratch. It's more performant.
Performance is just gravy.
I'm hopeful about Python's type checking though, but so far it leaves a lot to be desired (absolutely no recursive types, lots of bugs, strange restrictions, confusing for variables, etc).
You like to write the type of your variables next to them, all the power to you. I don't or, more exactly, I prefer the little extra flexibility of not having to do that.
We actually did try pypy for a few parts of our infrastructure. It's better, but for what we tried only 2x faster.