Live data from Hacker News

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

preslav.me

251–260 of 313 posts

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

#251
post #217

Earlier quoted context omitted.

All these things are a trade-off; unqualified statements that "sum types make everything simpler" are just wrong, because they don't. Whether it's worth the trade-off is a subjective judgement call and a completely different thing.

If all things are a trade-off, what would the trade-off of adding sum types be? > All these things are a trade-off; In some cases the trade-off is so one sided that its hardly worth the conversation. If everything is a trade-off, do you feel the same way about indenting your code? Or structured programming - aka using if/while blocks instead of gotos? I think I'd confidently say that indented code makes everything si…

> If all things are a trade-off, what would the trade-off of adding sum types be?

Harder to write tooling for the language, bit harder to reason about code, possibly slower compiles (hard to claim this one for sure without a working implementation that has wide-spread use), harder to add features or change the language in the future, harder to work on (or implement a new) compiler.

None of these are insurmountable problems of course, and "Harder" means "harder relative to" rather than "hard". It's not clear to me anyway that sum times are a "slam dunk" type of feature. For example I've written a bunch of Go tooling over the years, and I really like that Go makes this fairly easy, partly due to the simple syntax. This is perhaps not something the "average developer does" or even a niche concern, but on the other hand: good tooling makes all the difference.

I'm not necessarily adding sum types to Go; details matter and it would partly depend on those.

Almost every single feature that has ever been added to any programming language was useful to add. I find many of Ruby's features useful, even some of the more esoteric ones, but that doesn't mean it was a good trade-off to add them.

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

#252

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…

> No matter what your opinion is about Go (as a language), but they nailed it for bigger projects. I don’t understand this template? 1. No matter your opinion on X: 2. Opinion Y is true about X! If all you have are compliments about X: just go directly to (2). You’re not making a begrudging concession, after all.

Or the related fallacy, "X was designed to be good at Y, so clearly X is good at Y!" (or worse, "is the best way to do Y!").

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

#253
post #243

Earlier quoted context omitted.

I never said there aren't features in Go I would rather see removed, or that there aren't features I would like to see added, or that Go is perfect in general.

Súm types (or even just working enums) would replace iota.

Only for some uses of iota. And iota is "simpler" from some perspectives, because you never have to deal with it anywhere except in const (..) blocks (that is, it's a very "localized" feature that barely interacts with anything else).

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

#254

Earlier quoted context omitted.

> geniuses That's very strong language. Go was created by some smart people that have completely ignored programming language developments that happened after the 70's.

Ironically, we had more advanced languages than Go in the 70s.

Advanced != good. It takes some genius to realize that.

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

#255
post #251

Earlier quoted context omitted.

If all things are a trade-off, what would the trade-off of adding sum types be? > All these things are a trade-off; In some cases the trade-off is so one sided that its hardly worth the conversation. If everything is a trade-off, do you feel the same way about indenting your code? Or structured programming - aka using if/while blocks instead of gotos? I think I'd confidently say that indented code makes everything si…

> If all things are a trade-off, what would the trade-off of adding sum types be? Harder to write tooling for the language, bit harder to reason about code, possibly slower compiles (hard to claim this one for sure without a working implementation that has wide-spread use), harder to add features or change the language in the future, harder to work on (or implement a new) compiler. None of these are insurmountable pr…

> It's not clear to me anyway that sum times are a "slam dunk" type of feature.

They certainly are for me. I use them constantly in my two main languages - typescript and rust. Expressing similar ideas in go using iota and go's interfaces is far more awkward, inefficient and error prone.

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

#256
post #33

Earlier quoted context omitted.

I wonder why isn't Clojure more popular.

lisp turns a lot of people off - it does require some retraining of your mind. when people need to get shit done this friction is too great, and so they fall back on other tools. going to do advent of code in clojure this year though to force myself back into it - it's a great language.

Separately from that, Clojure turns some genuine Lisp people off.

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

#257
post #208
post #33

Earlier quoted context omitted.

I wonder why isn't Clojure more popular.

I tried to use Clojure a few weeks ago. I have two projects for it: the first is that I have a "TOML test matrix" where I compare different TOML implementations against the test suite. This works by feeding a binary a TOML document which then outputs a description of that in JSON. I set that up for a whole bunch of languages. The second is instaparse, which I'd like to use to quickly test a TOML document against the…

[deleted]

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

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

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

> 70s, 80s and 90s

It reminded me of Go vs. Algol-69 http://cowlark.com/2009-11-15-go/

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

#259

Earlier quoted context omitted.

lisp turns a lot of people off - it does require some retraining of your mind. when people need to get shit done this friction is too great, and so they fall back on other tools. going to do advent of code in clojure this year though to force myself back into it - it's a great language.

Separately from that, Clojure turns some genuine Lisp people off.

That confuses me. It’s such a great lisp.

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

#260
post #197

Earlier quoted context omitted.

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

You could claim the same thing about JavaScript. It's very possibly more popular than Python, but it's definitely not better designed than Python or most of the other languages in current use.

Yes and that would be a correct claim. Unless one assumes that a language is objectively "good" or "bad", in which case, rationally speaking, we would only be using "good" languages, which is clearly not the case. Ironically the same happens with natural language. In theory we should all be using Esperanto by now, in practice English as the de facto international language is totally fine.

The main difference with JS is that we don't know whether it would be so commonly used if it wasn't for browsers. Still, it seems that the majority of efforts are towards augmenting JS' capabilities rather than finding ways to use alternative languages on the web (yes, I'm aware of WASM and maybe in the long run this statement will be proven false).

Post reply on HN