Live data from Hacker News

Python Is Easy. Go Is Simple. Simple != Easy

preslav.me

221–230 of 313 posts

Re: Python Is Easy. Go Is Simple. Simple != Easy

#221
post #67

Earlier quoted context omitted.

I tried Go for about a day, and the exception handling and null-pointer issues were exactly the things that made me lose interest.

Sorry to disagree, but you can not judge a whole programming language in one day (no matter what your skills and experience in other languages are). Most likely what made you lose interest in Go are simply things you did not grasp yet in one day.

> Most likely what made you lose interest in Go are simply things you did not grasp yet in one day

It doesn’t take a day of use to be frustrated by go’s warts - like having nullable pointers everywhere, the lack of sum types and the awkward error handling. I think it takes more than a day to get used to those problems and work around them. And who knows if the juice is worth the squeeze?

Rust is the same. It takes less than a day to start fighting the borrow checker. Whether the language is worth the discomforts it brings is a question nobody can answer for you.

I think dismissing these criticisms by saying the poster just didn’t understand the language is overly dismissive. These criticisms are real and legitimate.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#222
post #159

I'm diving back into python after being mostly away for the better part of a decade having built high scale, highly available systems in Go during that time (including migrating several projects from python and perl to go). Being suddenly back in python is jarring. So much inheritance - abstract base classes and multiple inheritance via mixins, strange coupling in tests via over use of mocking and patching, and a rel…

I was thrust into a go project after a decade of python. The most jarring thing besides the 3rd party panics, was the idiom that nils are typed. This was different than python, java, JavaScript, c, c++, etc. Variable loop scoping is also weird. Writing unit tests is 10 times harder than python. Go statically links everything, and just that seems like going back 30 years in software development. Any security in a depe…

If you have CI/CD then rebuild and deploy isn’t a big deal. If you’re mutating running systems in an uncontrolled way you’re probably doing it wrong

Re: Python Is Easy. Go Is Simple. Simple != Easy

#223
post #86
post #67

Earlier quoted context omitted.

I tried Go for about a day, and the exception handling and null-pointer issues were exactly the things that made me lose interest.

The lack of true exceptions are annoying, but what kind of environment are you writing in that it's so expressly prohibitive to quit after a day? I've written error matching functions (and now there's errors.Is()) that mostly achieve the same things exceptions do, so I'm struggling to match being so overwhelmed by textual errors that you ignore every other improvement with the language over others.

> what kind of environment are you writing in that it's so expressly prohibitive to quit after a day?

I think it’s admirable to try other languages for a day. I’ve spent less than a day noodling with dozens of languages that seem interesting. I’ve never tried dart, kotlin, elm or Scala. Why not? Is it prohibitively expensive? No. I just haven’t taken the time and the initiative.

More people should spend a day with go, even if they don’t stay around it’s still nice to learn something new!

Re: Python Is Easy. Go Is Simple. Simple != Easy

#224

Earlier quoted context omitted.

The problem with error checking is that Go doesn't cover every case BY FAR. EVERY memory allocation can fail. And I mean EVERY. var x := 5 // where's the error handling? EVERY kernel call can fail. Even this is still not a 100% correct way to call fmt.Printf("Hello, World!"): s := "Hello, World!") writtenSoFar := 0 while writtenSoFar If you don't do this, you will find, for example, that writing large amounts of data…

In practice, how often does your rant on memory safety really apply though? Because I currently feel that you're inflating the argument substantially to make it seem like a much bigger, much more common problem, than it is. For reference, in 5-6 years of Go programming, memory allocation has been a problem for me exactly one time, and it was because I was a noob and tried to push about 60GB of data into a variable at…

Well that's the problem with correctness. I've seen this fail, in 20 years (that I noticed) about 20x. Let's assume I caught it 1% of the times I actually saw it so ... about once a week. More on slower networks.

This issue, not checking the number of bytes written, usually combined with incorrect EAGAIN handling, is a pretty pervasive problem in network programming. You will find the closer you get to 100% cpu usage, the more common this problem becomes, just like threading bugs. It's one of the ways a service goes from handling 5 Gbit at 90% cpu usage, then handling 5 kbps at 95% cpu usage (because everything suddenly errors out, then retries eat all the bandwidth). It's impossible to find if you don't know what you're looking for.

It's not this issue specifically: Golang programs, like C programs, are strongly incentivized to just keep going with incorrect data when other languages would crash.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#225
post #37

Earlier quoted context omitted.

I used Go for many years. My issue is that it's _almost_ a great language, but in its current version it's just a collection of foot guns that makes it difficult to get shit done. Go doesn't have some of the most library functions, so large codebases shared between teams end up with a dozen different implementations of functions like "minimum" or "filter". Good luck debugging a bug in one of the implementations. The…

I could not agree more with this. Go is so frustrating to me because there is so much I like but these things you listed make it miserable for me to use. A basic option and result type could fix a lot of the issues around errors and null pointers. I know languages like Scala, Haskell, and Rust have type systems that are often considered too complex but Go doesn't need all that to add these two.

Indeed. I enjoy working in Go and have written various things in it over the last 8 years. Last year I toyed with Rust (very different learning curve!) and still prefer Go for its simplicity and development speed. But, I would love to have Rust-style enums in Go. The 'similarly named constants pretending to be enums' and 'returning nil if not found' patterns suddenly started feeling wrong.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#226

The sad thing is that many people make language decisions on the beginner topics like syntax , literals, hello world or trivial samples. Sure a 20 line python app will be 40 lines in Golang, but that doesn’t mean 10k lines of python are 20k lines in golang. And there are way more serious considerations than LOC. Golang concurrency is amazing. You can reproduce an entire multi-core application stack with concurrent IO…

What’s also sad is people choosing between two very limited languages, Go and Python. Ultimately they both lead to the same place-orientated programming soup.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#227
post #148
post #140

Earlier quoted context omitted.

The Python typing nightmares you refer to go away on large projects as soon as you start using mypy, which I tend to find most large projects do these days. So yes, you can change that string and you do know. It's still better that it's optional and gradual - it's unnecessary overhead on smaller projects, spikes, notebooks, etc. which are what most big projects grow out of.

Python typing nightmares definitely do not just go away with the use of mypy. There are so so many ways to break out of the guardrails it supplies that are not caught.

I can write stringly typed code in haskell too if it comes to that.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#228

And Clojure has "Simple made easy" [1] [1] https://www.youtube.com/watch?v=SxdOUGdseq4 -> on of Rich Hickey's best talks

The added value of Clojure over JavaScript is marginal, and the trade-off is significant.

Sorry, but this is plain wrong. Clojure is a functional first language with an extremely powerful macro system. JavaScript has ad-hoc monkey patching and a heavy toolchain requirement to enable immutability.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#229
post #159

I'm diving back into python after being mostly away for the better part of a decade having built high scale, highly available systems in Go during that time (including migrating several projects from python and perl to go). Being suddenly back in python is jarring. So much inheritance - abstract base classes and multiple inheritance via mixins, strange coupling in tests via over use of mocking and patching, and a rel…

I was thrust into a go project after a decade of python. The most jarring thing besides the 3rd party panics, was the idiom that nils are typed. This was different than python, java, JavaScript, c, c++, etc. Variable loop scoping is also weird. Writing unit tests is 10 times harder than python. Go statically links everything, and just that seems like going back 30 years in software development. Any security in a depe…

The reason that we have static linking is because it's not "you" updating the affected library, it's more often than not the package manager and more often than not entirely out of your control.

Re: Python Is Easy. Go Is Simple. Simple != Easy

#230
post #166

Anyone who appreciates the benefits of simplicity should skip Go and try functional programming instead. The basic tenets are a model of mathematical simplicity: * Values are immutable * Functions are pure (i.e. no side-effects) * Functions are values (i.e. can be passed as arguments to other functions)

Exactly what I am doing with… Python.

Python has mutable data structures by default and you cannot have multi-line lambdas. The interpreter cannot optimise common functional patterns, so you pay a heavy perf cost. I could be wrong, but last I checked there is no TCO. Python is not even close to a proper FP language.
Post reply on HN