Live data from Hacker News

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

preslav.me

231–240 of 313 posts

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

#231

Earlier quoted context omitted.

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();

There is no need to use anything but filter, like filtered_temps = list(filter(lambda e: e["temp"] > 20, temperatures)) IMHO the most readable version (and coincidentally also the shortest).

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.

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

#232
post #127

Earlier quoted context omitted.

Ok, I wasn’t able to figure that out when I was in the codebase. What do you do if you’re working in a fork of the project and you need to make those changes?

Should be the same. You can replace to any location, and with modules it doesn't even need to follow GOPATH naming conventions. E.g. clone A and fork-B into adjacent folders regardless of fork status or import paths, and change A/go.mod to include replace original.com/B ../B and that should work fine. With GOPATH you would need to clone the fork into the original path. Which you can do if needed / modules don't preve…

Wow. You’re right - that is simpler than I expected. Thank you!

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

#233
post #217

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.

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

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

#234

Earlier quoted context omitted.

There is no need to use anything but filter, like filtered_temps = list(filter(lambda e: e["temp"] > 20, temperatures)) IMHO the most readable version (and coincidentally also the shortest).

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, {})

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

#235

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 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 datastructures (sets, dictionaries, tuples, etc) is very intuitive.

They have been completely surpassed by those in other languages. For example, you can't do this in Python list-comprehensions:

    xs = [
      if some_flag:
        yield 1
      
      for y in ys:
        yield y * 2
    ]
> Monkey patching is a liability? This is like saying a car is a liability because I am free to drive it off a cliff. You're technically correct, but you are the one in the drivers seat. The ecosystem does not do or encourage this behavior, with the exception of things like gevent where it is required.

Only if you are a solo developer. Unfortunately the Python ecosystem is built around things that compose poorly like annotations and exceptions.

> Mutability by default is common in virtually every language. You can't say it is good or bad, it's just a fact of life. There is a cost to immutable datastructures unless the language is designed from the get-go to utilize them efficiently.

It's a mistake, even though it is common. The cost is low in true FP langauges, because they can be optimized away.

> Lack of support for functional programming? Functions are first class in Python. You can pass them around all over the place, as args, put them in datastructures, etc. When you combine this with comprehensions and generators it is very powerful and lets you do lazy evaluation of complex transformations. There are lots of built-in tools in the stdlib to do functional programming. This is just straight up false.

Python lacks do-notation. It doesn't give you tail-call optimization. Function calls are slow. Immutability is very much opt-in. Lambdas can only be one line. If you do lots of FP in Python, you're in for a bad time.

> Deployment story remains extremely painful - again false, I do not know why people say stuff like this. Create a virtualenv (built into the standard library), and pip install your requirements. If you are using conda and all the other noise you are going to have problems.

In other language stacks it's pretty trivial to cross-compile from e.g. MacOS to Linux and things just work. In Python this basically requires Docker. Note that Pip install doesn't give reproducible builds. There's nothing like Go static binaries out-of-the-box, either.

> Slow execution of pure python code - this is the ONLY area where you are perhaps correct... but compared to what? For a lot of use cases, the speed of Python is not a problem. When it becomes a problem, you off-load that responsibility to something else. There is also something to be said for writing software quickly, which is a perk of Python for sure.

Python is about 100x slower than mainstream GC languages such as Java and C#. Having to drop into native code is not always possible and it's extra work besides.

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

#236

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

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

#237

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.

Yup. Go made a lot of odd choices from a language design perspective. It's pretty much "C, but with better types and a garbage collector!" It certainly has its usages and does some nice things. But at the same time, the obsession with compile speed has, IMO, has been a detriment to the language as a whole. We see this in the way generics ultimately entered go after years of causing problems by not existing from the g…

I'd say that the hands-down improvement over C is simplified threading and proper utf8 support. The utf8 alone (because of the notion of rune) is a good reason to use golang over C or C++.

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

#238

Earlier quoted context omitted.

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

> the lack of sum types

Wait, Go doesn't have sum types? How do you create any modern programming language and not build it on top of sum types? That seems so odd.

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

#239

Earlier quoted context omitted.

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.

And the industry doesn't care, ecosystem is 100x more important (please don't bring up that "seamless interop" fallacy crap).

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

#240
post #86

Earlier quoted context omitted.

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…

Elm is a spectacular "weekend language". You really can learn the entire thing and get a solid feel for it in a weekend.
Post reply on HN