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

241–250 of 313 posts

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

#241

Post by zimpenfish »

otabdeveloper4 wrote: post #74
zimpenfish wrote: post #30

Earlier quoted context omitted.

> it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a…

Yeah, you just described every Go project. Reading Go code is a nightmare of frustrations.

I disagree because I've seen some readable Go codebases but I wholly agree that bad Go codebases are a nightmare.

Try comparing the Honk source (clear, direct, modulo the unangst wacky names for everything) with GotoSocial (unreadable, interfaces and abstractions out the wazoo).

(Yes, I know GTS supports the MastoAPI but that doesn't force the hellish onion-layer abomination they've created.)

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

#242

Post by Izkata »

ReleaseCandidat wrote: post #234
stouset wrote: post #231

Earlier quoted context omitted.

In the provided example, they’re turning it into a map of city names to temps so I kept that. Yours keeps it as an array of objects with a name and temp. If you skip that, city_temps .select { |ct| ct.temp > 20 } city_temps .iter() .filter(|ct| ct.temp > 20 ) .collect(); are still best IMO just due to the natural method chaining of iterators.

Oh, yes, of course you're right, I didn't see that until now - did I say already, that I hate Python's list comprehensions or everything not totally simple?. So that needs reduce: def filter_func(acc, e): if e["temp"] > 20: acc[e["city"]] = e["temp"] return acc filtered_temps = functools.reduce(filter_func, temperatures, {})

Technically that's a dict comprehension, not a list comprehension (though they are pretty much the same). The old style, before they existed, was to create a list of 2-tuples (key/value pairs) in a list comprehension and pass that to dict().

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

#243

Post by arp242 »

ReleaseCandidat wrote: post #233
arp242 wrote: 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.

> unqualified statements that "sum types make everything simpler" are just wrong, because they don't. Just about everything is "simpler" than Go's `iota` (which isn't even easier for the compiler implementor).

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.

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

#244

Post by munificent »

mrweasel wrote: post #36
zimpenfish wrote: post #30

Earlier quoted context omitted.

> it doesn't have this overbloated concept of inheritance and polymorphism of let's say Java where you have to look through 6 files to understand what's even going on Several Go codebases I've worked on would like a word. Some Go people really love their interfaces and abstractions and making sure every method is only 3 lines and pretty soon you're 20 files and three type hierarchies deep trying to figure out what a…

A certain number of developers will be able to complicate any language or mechanism you provide them, it's how they feel important. I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else, except they aren't, so they build extremely complex systems, because they think that's what smart people do. They are interestingly often extremely well versed in their…

> I've notice the there is a group of people who has their entire identity tied up in being "smarter" than everyone else

I've also seen the opposite where people revolve their entire identity around not being the person and they swing too far the other direction and end up being a masochist and doing things the dumb way because they're too afraid of coming across like a snob.

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

#245

Post by whalesalad »

tyree731 wrote: post #236
whalesalad wrote: post #171

Earlier quoted context omitted.

I really cannot agree with most of this. Weird scoping rules? This will rarely if-ever impact you in the real world. The list comprehensions in Python are incredible, in fact people over-use them all the time in really gnarly ways. Like [x for x in [y for y in [z... and the consistency with the same system supporting all datastructures (sets, dictionaries, tuples, etc) is very intuitive. Monkey patching is a liabilit…

> Slow execution of pure python code - this is the ONLY area where you are perhaps correct... but compared to what? Compared to… basically everything? Python’s performance is unacceptable, especially given that single threaded processor performance isn’t really improving any longer.

asyncio is quite fast, especially with libuv/uvloop

- https://github.com/libuv/libuv

- https://github.com/MagicStack/uvloop

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

#246

Post by richbell »

porjo wrote: post #176
patmorgan23 wrote: post #170

Earlier quoted context omitted.

And it's funny because go has a whole http server in the standard lib, but not minimum?

There is 'min': https://go.dev/ref/spec#Min_and_max

Since v1.21, which wasn't released that long ago.

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

#247

Post by ReleaseCandidat »

arp242 wrote: post #243
ReleaseCandidat wrote: post #233

Earlier quoted context omitted.

> unqualified statements that "sum types make everything simpler" are just wrong, because they don't. Just about everything is "simpler" than Go's `iota` (which isn't even easier for the compiler implementor).

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.

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

#248

Post by josephg »

arp242 wrote: post #217
josephg wrote: post #211

Earlier quoted context omitted.

I really think go goes too far to the point of hurting productivity and expressiveness. For example, go is missing any way to write parametric enums (sum types). Sum types make code much simpler and more expressive. The equivalent go code (using interfaces) is uglier, more verbose and more error prone. There’s a lot of features like that which go leaves out - like iterators, optional (nullable) types and so on. The o…

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 simpler. And if I were given the choice, I think I'd choose structured programming every single time. I also don't often find myself questioning my daily choice to use high level languages rather than writing assembly directly. What else? Mmm... functions? I like those.

I feel the same way about sum types. They feel like an obviously good idea. Try as I might I can't think of any reason not to have them in a language like Go - except, as I already said - that they are another thing to learn when getting started. Having sum types and generics also makes it much easier for the type system to support optional types. And that makes it easier for a language to do away with Hoare's "billion dollar mistake".

If you disagree, I'd love to hear what you think the downsides are.

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

#249

Post by afandian »

danenania wrote: post #144
bunderbunder wrote: post #138

Earlier quoted context omitted.

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…

I think the key question is how robust a type system can be while keeping compilation extremely fast. Slow compilation absolutely destroys developer productivity.

I’ve used a number of languages over the years and I have never been more productive than with Kotlin.

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

#250

Post by [deleted] »

durable_queue wrote: post #235
whalesalad wrote: post #171

Earlier quoted context omitted.

I really cannot agree with most of this. Weird scoping rules? This will rarely if-ever impact you in the real world. The list comprehensions in Python are incredible, in fact people over-use them all the time in really gnarly ways. Like [x for x in [y for y in [z... and the consistency with the same system supporting all datastructures (sets, dictionaries, tuples, etc) is very intuitive. Monkey patching is a liabilit…

> Weird scoping rules? This will rarely if-ever impact you in the real world. It can be a problem if you have nested loops. Things would have been less error-prone if Python introduced a let keyword. > The list comprehensions in Python are incredible, in fact people over-use them all the time in really gnarly ways. Like [x for x in [y for y in [z... and the consistency with the same system supporting all datastructur…

[deleted]
Post reply on HN