Hacker News Reader

Comment by BobbyJo | Hacker News Reader

> "I just wanted to learn a new language"

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.

View on HN

> if someone doesn't know Go, then can still get up to speed and use the language extremely proficiently within a few months

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.

> Its perfectly possible to write low latency high scaling code in python, just as it is in go and rust.

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.

> 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.

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.

Java didn't have a comparable thread/worker model to Go until this year, and arguably added it because of the success of Go routines for highly parallel services.

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.

Let’s not mix up virtual threads with the overall paradigm used for parallelism. Sure, on the former front Go was ahead for a time, but both are still pretty prone to race conditions and all the usual problems associated with parallel code.

> it really is not better than what you can do in Java or C#

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

Reply on news.ycombinator.com