Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

Post reply on HN
Print view View original

261–270 of 301 posts

Re: Why We Switched from Python to Go (2021)

#261

Post by kaba0 »

BobbyJo wrote: post #259
KaiserPro wrote: post #237

Earlier quoted context omitted.

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

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

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

Re: Why We Switched from Python to Go (2021)

#262

Post by kaba0 »

mountainriver wrote: post #229
sliken wrote: post #147

Earlier quoted context omitted.

Go has one, the same one used by the compiler, so there's no arguments, no multiple standards, etc. Python has a few options, and when a new language feature comes out the time to implementation may vary. 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 f…

It’s also an example of how Go thinks about all problems. Do things one way that is well made and roughly satisfies most use cases

(Other than Generics, which was known to be required decades before its existence.. sorry)

Re: Why We Switched from Python to Go (2021)

#263

Post by kaba0 »

systemvoltage wrote: post #174
radicalbyte wrote: post #171

I have experience with both (and a lot of other languages) and honestly - I wouldn't move from Python to Go. I'd move from Python to the very latest version of C#. You get far better tooling, excellent performance, the ability to write extremely concise code (as long as you don't apply mainstream coding standards/style) and a better range of libraries for most situations than Go. More chance for re-use too (i.e. same…

To me the biggest advantage Python has is the debugging capabilities. Especially combined with PyCharm, ad-hoc interpreter to check things while the execution is at a breakpoint – this is just like cheating. It is too good. I am not an expert software developer and haven't developed anything that needs to be fast, but for my needs, Python is really awesome. That said, I want to learn Go properly.

Not sure about C#, but Java has a similarly good debugging story.

Re: Why We Switched from Python to Go (2021)

#264

Post by kaba0 »

bloblaw wrote: post #97
atx42 wrote: post #52

I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural programming great again? I get it, you can compile it and it has concurrency, but there's better alternatives in my mind, unfortunately not as popular.

Go is successful because it has many appealing features: 1. trivial cross-compilation 2. native multi-threading (eg no GIL or multi-process hacks) that is easy to take advantage of 3. fast. An order of magnitude faster than Python in many cases. 4. easy to deploy. Most often just a single binary I like Go because once I compile it, I can ship that binary anywhere and it will run. I like Python for a great number of t…

1. VM-targeting languages have even more trivial cross-compilation, like you even get a single .jar file 2. There are hundreds of languages like that 3. It’s not too hard to be faster than python - Java, C#, JS are all in the same ballpark as Go (and for more complex programs some can often surpass it due to the much better GC-implementations) 4. Very very slightly easier than the above mentioned bunch. But with Java’s stellar backwards compatibility record you pretty much just has to have a big enough JVM version and that’s it.

Re: Why We Switched from Python to Go (2021)

#265

Post by kaba0 »

bornfreddy wrote: post #243
snapetom wrote: post #210

Earlier quoted context omitted.

Null, void, wild, dangling in core C. DOS also had far, near. I believe one of the Windows Visual something platforms had extensions that added another three or four.

I'll bite. So null is just a special value one can assign to a pointer, marking it not used. In Go this is nil. Void means "absence of type" and is related to pointers only marginally - void* is a pointer to something we don't know a type of. In Go, I guess a pointer to interface{} would be the same? (Not quite, but close) As for wild and dangling pointers (I would argue the are the same - pointers that show somewher…

> As for wild and dangling pointers (I would argue the are the same - pointers that show somewhere they shouldn't), fair point. Of course one would expect this from a language so many decades younger.

It’s not due to age, but due to having a GC and being a managed language. I really don’t get all the comparisons of Go to C, the former seems to want to sell itself as a modern C replacement but they are nowhere in the same niche (and that’s ok, there are very few places where a GC can’t work). They just operate by completely different semantics when it comes to pointers.

Re: Why We Switched from Python to Go (2021)

#266

Post by kaba0 »

umvi wrote: post #83
atx42 wrote: post #52

I think Go and Angular should have died, and would already be footnotes in programming history if they had not been introduced by Google. Let's make procedural programming great again? I get it, you can compile it and it has concurrency, but there's better alternatives in my mind, unfortunately not as popular.

Procedural programming has always been great and continues to be great for most use cases. There's a time and a place for OOP, and there is a case to be made for functional programming, but it's hard to beat the simplicity of procedural programming. Go is an excellent procedural language that has lots of static guarantees and a super fast compile times (fast at least compared to C++).

I really would not call it “lots of static guarantees”.. it has some static guarantees at most. It is pretty low in type safety, compared to even C++ and the like, let alone Rust, Haskell, etc.

Re: Why We Switched from Python to Go (2021)

#267

Post by kaba0 »

erokar wrote: post #60
klodolph wrote: post #41

Earlier quoted context omitted.

Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about. This is not a performance issue, and it’s the #1 issue that I choose to rewrite Python programs in other languages. Python type annotations help. IMO modern languages like Go and Java are pretty easy to get into and you can use them for a first implementation without really sacrificing…

> Python has problems scaling to medium-size code bases because programs above a certain size tend to become difficult to reason about. In mye experience Python programs are not more difficult to reason about than equivalent Java programs. To the contrary an over-reliance on certain design patterns and ubiquitous, inescapable OOP complicates Java code bases, while the static typing is so weak it affords little safety…

> inescapable OOP complicates Java code bases

> while the static typing is so weak

Both of these are straight up false. Java can be written with static functions and single-depth inheritance trees just fine. Hell, the direction the language took for quite a few years now are pretty much this with records, pattern matching, etc.

And while Java is not Haskell, it has a moderately strong type system with quite a good generic implementation making even some more advanced functional patterns expressible.

Your claim on LOCs is also false (as well as most of this kind of claim) Java has at most a tiny bit of constant overhead, it won’t make it anywhere close to 2x.

Re: Why We Switched from Python to Go (2021)

#268

Post by kaba0 »

8organicbits wrote: post #24
yedpodtrzitko wrote: post #5

So they switched to Go from Python, because of following advantages: #1 Performance #2 Performance (to make the list longer I guess?) #5 Fast compile time... which is an advantage over Python how exactly? #7 Strong ecosystem... which brings us to disadvantage #1 - lack of frameworks (?)

> #5 Fast compile time... which is an advantage over Python how exactly? Compiled code can have fewer runtime errors, that's a big win. I read this as golang is better than python because it's compiled and golang is better than Java and C++ because the compiler is fast.

I have a hard time believing Go compiler being faster than Java’s. Like, none of them do barely any optimizations, but Go still has to do a bit more.

Re: Why We Switched from Python to Go (2021)

#269

Post by IshKebab »

d0mine wrote: post #216
IshKebab wrote: post #91

Earlier quoted context omitted.

There's an element of truth to that in some cases, but it's mostly just something Python fans say to excuse the fact that Python is so slow. It's not true for two reasons: 1. In practice writing a prototype in one language, then completely scrapping it and rewriting it in another language almost never happens for fairly obvious reasons. 2. The "slow bits" of a Python program are rarely neatly concentrated in a few pa…

The opposite is more plausible: it is rare when your performance issues are distributed evenly through the code. The very words such as bottleneck/hotspot indicate that it is common to get the most benefit by optimizing small parts of the code.

The fact that the words bottleneck and hotspot exist doesn't imply that they are common.

Re: Why We Switched from Python to Go (2021)

#270

Post by BobbyJo »

kaba0 wrote: post #261
BobbyJo wrote: post #259

Earlier quoted context omitted.

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

> 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 t…

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.

Post reply on HN