Live data from Hacker News

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

preslav.me

131–140 of 313 posts

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

#131

No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and fast enough for most programs, and its really, really easy to be productive. When i picked up Go i basically got shit done without ever having written a single line of Go. Its statically typed (with generics yey!) and compiles very fast. Its easy to create smal…

As someone who mostly writes request-handling services, I just don't think propagating errors through gateway/repository -> controller -> handler layers deserves 90% of my attention. But unfortunately that it is where it goes doing microservices glue type stuff in Go.

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

#132
post #33

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

I wonder why isn't Clojure more popular.

Because it's not easy.

You need the right balance of "easy" and "simple" and Clojure does not have it.

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

#134

Earlier quoted context omitted.

As someone with the misfortune of inheriting a million plus loc Go project I disagree. Go is a nightmare from the duck typing to dependency management.

I think you typed "python" wrong :) Duck typing is a python thing. And the dependency management is a nightmare, constantly breaking. To the article's point - you _must_ run it in a container and defer to the OS to have anything resembling a sane development story.

OP meant structured typing, which is the strong type version of duck typing.

As long as the type supports the same interface anything goes, even it actually supports another one, where the methods have the same name, with different semantics.

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

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

I can understand why you felt the need to share that, but if you only used it for about a day, aren’t you just reporting your initial impressions? If I used Rust for about a day, I would probably complain about the borrow checker. And if I used Python for about a day, I would have no idea what people are talking about when they complain about package management in Python.

It's pretty clear what the payoff is for the investment in using a borrow checker, and it's quite big. Less so for writing if err != nil on every. other. line. That's just an unnecessary nuisance.

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

#136

Yeah, but the amount of boilerplate one must read and write in Go is frustrating, even compared to Java.

With things like copilot, the boilerplate (if err != nil sorts of things) comes out really easily, and you can skim past it when reading. Also, I have noticed that a lot of the other stuff that people call boilerplate in Go is actually an artifact of static typing (eg having to unmarshal JSONs before querying them), and is ultimately what prevents you from having Python-style runtime crashes or weird bugs.

Mindless AI-generated boilerplate you're not really looking at sounds like a likely vector for bugs.

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

#137
post #37

No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and fast enough for most programs, and its really, really easy to be productive. When i picked up Go i basically got shit done without ever having written a single line of Go. Its statically typed (with generics yey!) and compiles very fast. Its easy to create smal…

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.

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

#138
post #37

No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. Go code always looks the same, performance is predictable and fast enough for most programs, and its really, really easy to be productive. When i picked up Go i basically got shit done without ever having written a single line of Go. Its statically typed (with generics yey!) and compiles very fast. Its easy to create smal…

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…

This roughly lines up with my feelings. Go is a solid improvement over many languages that we inherited from the 70s, 80s and 90s.

But it also retains a certain "we don't need a robust type system; weak-ish static typing is good enough" ethos that made sense in back then, when compilers were hard enough to write that it was easier to justify making the programmer handle more things manually for the sake of simplifying the compiler authors' job.

This is always a tradeoff, of course, but I think that the optimum balance has shifted even further in favor of programmers. Some of Go's decisions still made sense in the 2000s when the language was first being created. But now, 15 or so years later, I think many of us could be forgiven for wishing for a language that's a lot like Go except that it dared to dream just a little bit bigger.

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

#139
post #135

Earlier quoted context omitted.

I can understand why you felt the need to share that, but if you only used it for about a day, aren’t you just reporting your initial impressions? If I used Rust for about a day, I would probably complain about the borrow checker. And if I used Python for about a day, I would have no idea what people are talking about when they complain about package management in Python.

It's pretty clear what the payoff is for the investment in using a borrow checker, and it's quite big. Less so for writing if err != nil on every. other. line. That's just an unnecessary nuisance.

Yes, and that is exactly what you don't want in a "get shit done" language.

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

#140

Earlier quoted context omitted.

Ok that's totally fair. What's the Go name for it? In my mind Go interfaces are duck typed.

mostly joking - your complaints are big problems in python. Dependency management in Go has been contentious (historically) with "to vendor or not to vendor", glide and dep, GOPATH, etc. But that is all solved. Go mod for the win. As far as "the nightmare of {using interfaces}" -- I have no clue to any controversy there. It is one of the most celebrated features of Go. Not sure where you were going with that. In Pyth…

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.

Post reply on HN