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

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

preslav.me

Post reply on HN
Print view View original

191–200 of 313 posts

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

#191

Post by candiodari »

starttoaster wrote: post #28
vore wrote: post #19

Earlier quoted context omitted.

Go doesn't really warn you if you forget to handle an error return, which in my experience continuing silently in the face of error conditions is far scarier than crashing loudly.

Check out ErrCheck. It's a static analysis tool that detects exactly this. We added it to our common Makefile that we use for testing/building Go projects. Typically I have it test for this among other things before I commit, and then it runs again in CI scripts before a merge to main is allowed. In my experience, if you're not checking errors, then you're often just going to crash loudly. Likely at a similar point t…

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 to a network socket suddenly only sends half the output to the other side. Plus anything could set O_NONBLOCK on stdout, which would require this. And time.Sleep() is required in some cases where the program redirects os.Stdout to itself.

Even this does not take have proper reactions if an OOM occurs somewhere. So it is still not correct.

It's like C. Simple Go looks correct and just chugs along, destroying data instead of crashing. This makes people feel programs run correctly ... but they don't.

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

#192

Post by arp242 »

kevincox wrote: post #174
morsecodist wrote: post #137

Earlier quoted context omitted.

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.

"Defaults are useful" was IMHO the biggest mistake Go made. I understand that it made the language a lot simpler but this was a simplification that ended up moving the complexity to the user, rather than just removing it. I have seen so many bugs caused by default values, production outages. Plus the code is harder to understand because you need to consider the default value case, and make sure that it is only left a…

A huge downside of that it that adding a new (public) struct field will be an incompatible change. And what people will do is add a non-public struct field with a setter method, both to avoid the compatibility break but also because for many of these fields the defaults are just fine (even though sometimes they're not) and no one lines having tons of boring boilerplate.

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

#193

Post by stouset »

JohnMakin wrote: post #154

Am I insane that: > filtered_temps = { entry["city"]: entry["temp"] for entry in temperatures if entry["temp"] > 20 } is less readable to me than: > for _, ct := range temperatures { if ct.Temp > 20 { filteredTemps[ct.City] = ct.Temp } } ??

And all of it is less readable than

    city_temps
      .select { |ct| ct.temp > 20 }
      .to_h   { |ct| [ct.name, ct.temp] }
Or

    let map: HashMap = city_temps
      .iter()
      .filter(|ct| ct.temp > 20 )
      .map(|ct| (ct.name, ct.temp) )
      .collect();

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

#194

Post by ShamelessC »

dxbydt wrote: post #106

A VC once told me that as a rule, Go startups were more likely to succeed than Python startups. Maybe because successful startups are working on simple problems, not easy problems.

I feel like it has more to do with those VC's having simultaneous investments in Google. Also, the "google pitch" for Go was generally that it was easier for junior devs to get started with, meaning your start up won't have to pay employees as much. Not at all true, of course but investors rely heavily on signaling.

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

#196

Post by aserafini »

dxbydt wrote: post #106

A VC once told me that as a rule, Go startups were more likely to succeed than Python startups. Maybe because successful startups are working on simple problems, not easy problems.

There are tons of startups that were built on Python that became enormously valuable companies: Instagram, Dropbox, Reddit, Spotify, YouTube, Pinterest, Quora, SurveyMonkey, Twitch, Zenefits.

I don’t think the data supports your VC’s thesis.

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

#197

Post by chpmrc »

lambda_garden wrote: post #68

Python is valuable due to the ecosystem of libraries it offers. The language itself is extremely poor. I think this is not something most Python users are aware of since if you are doing ML, data-science or simple scripting there is little reason to step outside of the ecosystem. - Weird scoping rules - Very limited list-comprehensions - Ability to monkey patch things is a liability - Mutability by default - Lack of…

I could address each of these "issues" but I'd rather focus on the following:

> The language itself is extremely poor

> I think this is not something most Python users are aware of

These two statements are contradictory. If it was indeed so "poor", people would notice :) If they instead increasingly adopt it (out of appreciation, not because they are lobbied into doing it) it becomes really difficult to logically demonstrate that it's a poor choice. Software development is a very efficient market. Everyone is (or can be) aware of (almost) everything. So if most people (including experienced devs) gravitate towards a certain technology, the only acceptable explanation is that the technology, as a whole, is good.

Deconstructing and pointing out the flaws of the individual components is a common flawed thought process IMHO. Python is great despite all the issues you point out. To me this is equivalent to comparing individual components when shopping for a product, missing the fact that it's the ensemble of all those (flawed) components that make the product (or the language, in this case) work. The easy syntax, the packages, the community, those are all things that make "weird scoping rules" pretty much irrelevant.

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

#199

Post by tick_tock_tick »

mFixman wrote: post #37
phplovesong wrote: post #4

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…

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

Does https://pkg.go.dev/slices#DeleteFunc not work for you or do you need it to be called filter? It's there for maps too https://pkg.go.dev/maps#DeleteFunc

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

#200

Post by pphysch »

emodendroket wrote: post #136
pclmulqdq wrote: post #10

Earlier quoted context omitted.

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.

If you're "not really looking at" LLM output, you are abusing it.
Post reply on HN