A thing that REALLY turned me off in go... 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.
So, one more vote for generics?
Why we switched from Python to Go
291–300 of 406 posts
Re: Why we switched from Python to Go
#292Earlier quoted context omitted.
Hi, Jelte from Stream here. The post was definitely not meant to indicate that people should stop using Python. We still use it happily for the website and I'm still a big fan of it myself. 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.
I would love to hear your experience in two years though. I find the go runtime incredibly lacking in terms of introspectability. That's okay if you run google scale operations where you just throw away the environment on deploys and you do not care about the individual processes, but if you are running a reasonably lean operation the ability to see what a process is doing is incredibly helpful. That even affects sim…
These are good points. Stack traces in Go are a matter of discipline while they're free in Python. That said, I think Go brings a lot to the table even for a lean operation which more than compensate for these weaknesses. Probably the biggest advantages are that Go deploys as a single binary, and one Go process is sufficient to make efficient use of the machine's resources--no need for something like it's uwsgi. At our small Python shop, we probably have two full time positions dedicated to managing our Python installation process. This could conservatively be halved with Go. Beyond that, we have a couple more full time positions for managing the fleet of servers required to run or applications--Go could easily reduce our machine demand to 2 or 3 (including redundancy) which would probably require just one engineer to maintain not to mention the savings on our AWS bill. These are just a couple of obvious benefits to Go, but for us this isn't enough to justify a rewrite.
Re: Why we switched from Python to Go
#293Earlier quoted context omitted.
For that project, we had very specific requirements: easily handle SSL/TLS with contexts and control over self-signed vs certificate checking, JSON processing, speed, nice syntax, and one of the most challenging requirements: statically compiled, linkable against musl and libressl, while still supporting mingw_64 for windows. Only a few languages have flexible compilers that can do this; for example, rust can't (afai…
If you do concatenation a lot, it's better (for performance, of course) if you make it a template (so Nim will just replace a + b with a & b): template `+`(a, b: string): string = a & b But probably C compiler is smart enough to inline your proc :)
Ah, brilliant! thanks!!
Re: Why we switched from Python to Go
#294Earlier quoted context omitted.
For that project, we had very specific requirements: easily handle SSL/TLS with contexts and control over self-signed vs certificate checking, JSON processing, speed, nice syntax, and one of the most challenging requirements: statically compiled, linkable against musl and libressl, while still supporting mingw_64 for windows. Only a few languages have flexible compilers that can do this; for example, rust can't (afai…
You can also check out this: [redacted] But there's almost no features in it as I'm lazy :) I think that the best feature in this lib is a python-like range type: [redacted]
[redacted] is really slick... looks so much like Python.
Re: Why we switched from Python to Go
#295The post never mentions PyPy. Have you tried it? Could increase the performance dramatically for free.
Re: Why we switched from Python to Go
#296Python was my entry into the programming world, and I've been an evangelist ever since... Or I was until I ran into distribution and parallelism. Since then, Nim has been my go-to language of choice. It is all that Python was, plus unbelievable speed, compiling to shippable binaries, and some other cool language features that admittedly, are still beyond my scope of abilities. Still quite lacking in libraries compare…
I tried Nim in non commercial capacity and liked it. Wrote an Aho-corasick string matching algorithm in it to see how it fared with Lua/Luajit and it was fairly close in speed. The code was also quite pleasant to write. I remember that debugging it was a bit of a pain if just not a real option then. Maybe things have changed.
This could help! https://nim-lang.org/blog/2017/10/02/documenting-profiling-a...
Re: Why we switched from Python to Go
#297If you can switch from Python to Go, you weren't using Python anyways, you were use Gothon or Javthon. 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.
Would love to, but what I would miss from Go is that low latency GC. If ya need it, ya really really need it. 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.
I don't get how low latency GC can be a good selling point.
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?
Re: Why we switched from Python to Go
#298Earlier quoted context omitted.
People who use Python are generally happy without it IMO. It's not a big deal.
people who use python more aren't as happy about it, otherwise mypy wouldn't exist. 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.
A large part of why mypy exists is due to cargo-culting groupthink that leaves the 'static typing > dynamic typing' trope less challenged than it ought to be. Static typing is just not as useful as the glossy claims - and the boilerplate cruft incurs way more friction than typists like to admit.
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.
Re: Why we switched from Python to Go
#299You had me at 4. I'm definitely GOing to give this language a GO now. That was a GOod introduction to the language, a veritable advertisement, if you will.
The audience on Hacker News takes themselves way too seriously, apparently.
Re: Why we switched from Python to Go
#300Earlier quoted context omitted.
Wheels solved this problem in 2013. 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 eve…
Have you actually done this? If so, on what platform(s)?
Linux, If you'd like, I'll post the pipfile for the repository.