"I just wanted to learn a new language"
Now, the points they've made are valid, Go concurrency beats the pants off python, and with gofmt, there is less of a debate about style.
Te bit about finding a team is pure horse cock. As they point out there are a bunch of C++/C programmers about. There are even more python programmers too. Go is a tiny pond compared to the big three (c, java, python).
Your assumption is wrong, we did not pick a different language just for fun or because we wanted to learn something new :)
Python was just not the language we needed for our APIs, we tried hard to make it work but eventually we looked at alternatives that would allow us to keep things simple and performant. End result was better latencies, a much simpler architecture (less async/MQ work) and processes that would eat a fraction of RAM and CPU compared to Python.
If you can program in any language, you can program in Go. There's so much less to learn than even Python (perhaps especially Python when you consider all of the different packaging tools, testing frameworks, sync vs async, decorators, metaprogramming, etc).
> "I just wanted to learn a new language"
Strong disagree. If the actual purpose was learning new things, they'd have chosen a language which does things a little differently than all of the mainstream. At least Haskell or some Lisp...
The fact they chose Go shows they care primarily about the practical side.
People want to learn a new language for reasons: perhaps they want to learn new concepts, perhaps they want a language that's faster, perhaps they want a more mature ecosystem, perhaps they want to increase their employability. There aren't people who "want to learn a new language" as their ultimate end goal.
Quite possibly! That would be consistent with my point that they chose Go for practical reasons, rather than to learn for the sake of learning, as KaiserPro was suggesting.
If you want to learn for the sake of learning, you'll learn a different paradigm, rather than rehash the same thing with a slightly different flavour. Also probably your productivity will tank.
It doesn't have to be a single variable equation. I can learn something both to learn it and for practical reasons.
The original comment I was replying to said their reason was "I just wanted to learn a new language", which is what I disagreed with.
and
> finding a team
Are connected. More people out there would be willing to work in Go than Python, even if more people know python. First, a large portion of python writers aren't backend devs, whereas pretty much all Go users are. Second, Python has a very bad rap as a backend language, and for pretty good reason. Third, if someone doesn't know Go, then can still get up to speed and use the language extremely proficiently within a few months, unlike any of the other languages you listed.
Which combined with a new code base is very stressful. but this avoids the main point, which is
> Python has a very bad rap as a backend language,
its not a front end language really(discounting the transpiled JS web stuff). I know people dont like it, and that's fair enough, but its as good as virtually any other language for "backend stuff". Its perfectly possible to write low latency high scaling code in python, just as it is in go and rust.
Despite what people say, code is just a logic brush, how you hold it, and how toy paint with it determines how pretty the picture is.
Yes there are inherent defects that each language has, but once again part of being proficient is know how not to blow your feet off. If Goethe can make wonderful prose in german, you too can make good scalable backend code in python.
Depends on what you mean. A tiny and simple HTTP handler brought up on lambda, sure, Python will be as good as anything else. Anything larger than that, and no, it isn't. Python just doesn't have the semantics to do what Go and Rust can at scale. I run a service that uses 4 threads in Python and it's horribly slow and unreliable. I worked on a service in Go that used hundreds of concurrent go routines and it was reliable as hell.
> Despite what people say, code is just a logic brush, how you hold it, and how toy paint with it determines how pretty the picture is.
That's a great analogy when you consider painters use different paint brushes for different parts of the job.
> Yes there are inherent defects that each language has, but once again part of being proficient is know how not to blow your feet off. If Goethe can make wonderful prose in german, you too can make good scalable backend code in python.
Sometimes yes. But accomplishing the same in Go is so much easier I don't know why you'd bother.
That is very anecdotal to the point where I’m not sure it is all that useful. Go is supposedly good at parallelism, yet it has plenty of warts to the point where it is not at all more stable than any other mainstream language out there, so other than its pragmatism on channels, it really is not better than what you can do in Java or C#.
If parallelism is truly important for you than the actor model will be hard to beat in terms of reliability.
Also, go accomplishes the same with much less verbosity because it's the default operating mode.
So yes, you can do everything with Java that you can with Go (not true with Python) but it's a bit like using a semi-truck to commute.
Theoretically, sure. If you _really_ know your stuff.
However, you can naively pack hundreds of thousands of go routines into a single thread in a go routine after a week or two of using it.
I'm not saying go is better, I'm just saying Java copied this abstraction for a reason: doing it right is hard
I can’t imagine ever picking a language based on this feature and seems weird to even mention it.
This has never caused me a minute of headache and the only time I care is when conflicting styles are used in the same file.
I always thought it was kind of dumb of Go to care about this but don’t care enough to affect my language choice. I don’t use Go but am open if it’s a fit for a project.
I like that Python has that variability and let’s developer make decisions as they see fit.
I don’t want to talk to people about tabs and spaces unless we’re already friends and having a few beers.
Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed?
Generally in the go community, contributions, patches, code, etc that's not formatted with gofmt is considered wrong/broken.
How do humans that disagree with the One Format deal with it? Do they self-select away from Go?
> Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed?
How does the format evolve over time as the community discovers improvements (if it does), and what are the implications for code on github?
Like much of go, there's the "go" way to do it, and the language simplicity reduces the chance of multiple programmers taking multiple approaches that are all different enough to require wrappers to interoperate. Sure your pet feature from some other language may be missing.
The language (and gofmt) have evolved. In particular since the parser is externally usable (by gofmt, IDEs, and other tools) you can actually use that tool to rename variables, functions, etc without having to worry about getting a REGEXP right. So when there's the occasional incompatible change gofmt can parse code into a tree, make a transformation, and then back info code ... including comments.
It's relatively common (in my experience anyways) to have commit hooks in git run gofmt on go code. Generally go's been very compatible, none of the issues like Python2 vs Python3. I'm sure some avoid go for these reasons, but I lump them in with folks that reject python because of whitespace/indenting.
This pretty much sums it up. Gofmt isn't perfect, but everyone uses it and deals with it. It's included with the language so there's no point in trying to create a "competitor".