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.
That is indeed quite weird
Why we switched from Python to Go
41–50 of 406 posts
Re: Why we switched from Python to Go
#42>Go forces you to stick to the basics. This makes it very easy to read anyone’s code and immediately understand what’s going on.
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.
Re: Why we switched from Python to Go
#43Re: frameworks 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.
You could say that nearly for any language. Very often you could do just fine without one.
Re: Why we switched from Python to Go
#44The guy didn't even mention type checking. Guess it's not a big deal to him. Zero type errors during runtime is a big deal.
Well, it's Go, so you're going to have some runtime type errors. interface{} is way too common to avoid them completely (I had the order of arguments for two ConcurrentMaps wrong, for instance, and it blew up on reads -- found it almost instantly, but alas, at runtime). But it should be a much smaller number than python.
Re: Why we switched from Python to Go
#45when you list as a con "package management", meaning "go is even worse than python"... man.
Re: Why we switched from Python to Go
#46Why does anyone write web apps in Python? PHP? Ruby?
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.
Re: Why we switched from Python to Go
#47If 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.
Re: Why we switched from Python to Go
#48> Python, Node and Ruby all have better systems for package management 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…
> conflicting system level packages 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.
> this is solved with virtualenv
Except when you run into edge cases, which happens all the time.
Re: Why we switched from Python to Go
#49Why does anyone write web apps in Python? PHP? Ruby? 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 faste…
High quality Java and Go developers are more expensive than Ruby and JS webdevs, partly because there are just so many of the latter.
Re: Why we switched from Python to Go
#50Why does anyone write web apps in Python? PHP? Ruby? 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 faste…
The answer is that for a huge variety of software, performance is not important, or perhaps is only important for a subset of the application.
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.