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

121–130 of 313 posts

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

#121

Post by grumpyprole »

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 once read that "Python" came from Monty Python's Flying Circus. And that's how I've always viewed the language, i.e. something akin to a Terry Gilliam animation.

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

#122

Post by munchler »

Anyone who appreciates the benefits of simplicity should skip Go and try functional programming instead. The basic tenets are a model of mathematical simplicity:

* Values are immutable

* Functions are pure (i.e. no side-effects)

* Functions are values (i.e. can be passed as arguments to other functions)

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

#123

Post by madeofpalk »

klodolph wrote: post #100
amelius wrote: 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 immediately clear (to me at least) what benefits you get from the 'pain' of borrow checking. I'm not sure what benefits you get from null pointer exceptions.

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

#124

Post by madeofpalk »

Gibbon1 wrote: post #110
mFixman wrote: 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…

I feel like the pointer stuff you could handle safely in a modern language. Because I think pointer and array notation are convertible so one isn't scarier than the other. But yeah not being able to tag pointers as 'can't be null' and have the compiler enforce that ignores everything we've learned in the last 40 years. You shouldn't be able to pass a potentially null pointer to a routine that can't deal with it. You…

Using pointers just to get a 'null' is just an annoying hack reflective of poor design. Instead, "no value" should be able to be directly represented.

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

#126

Post by bufio »

EnergyAmy wrote: post #73
ingoaf wrote: post #5

Earlier quoted context omitted.

Don't forget the fact that 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. Even generics in Go were a heated debate because they make the language more complex. All in all Go was created by geniuses and it shows.

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

Maybe you could educate them.

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

#127

Post by Groxx »

distortedsignal wrote: post #114
Groxx wrote: post #65

Earlier quoted context omitted.

> I need to make a change across both of these modules. Will my compilation pick up the changes? Yes, add a replace directive to A's go.mod and point it to B's directory. It'll pick up changes immediately. You can also vendor + disable modules + change stuff in the vendor folder to quickly experiment, though IDEs tend to get moody about this. Backwards incompatible in principle: release a new major version of B. Impo…

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 prevent that either, but modules don't need any specific locations at all.

---

The official module doc is... huge and doesn't spell things out in an easily-usable form, so you're far from alone in your confusion, but I do think it's worth reading. I routinely find people spending way more time struggling with them than it would take to read the spec and become an expert on it: https://go.dev/ref/mod

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

#128

Post by rplnt »

throwawa14223 wrote: post #78
bogota wrote: post #66

Earlier quoted context omitted.

I assume with the duck typing you are talking about interfaces? How has that caused issues? With huge projects that pull in packages i have seen the dependency management become a mess but most of the time its not that bad.

It was sloppy coding on the project I took over, but it still made me wish for explicit style interfaces. Cleaning up frequently broke the project in non-local ways, because someone would break an interface without meaning to.

Unless you are doing some (possibly unsafe) magic the interfaces are strongly typed, external dependencies are locked, so one cannot really break an interface without meaning to. Or I guess without realizing it immediately.

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

#129

Post by sf_rob »

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.

The interesting experiment would be to make Go startups work in Python and Python startups work in Go :)

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

#130

Post by starttoaster »

throwawa14223 wrote: post #88
starttoaster wrote: post #18

Earlier quoted context omitted.

Write more libraries of common tasks you have to do constantly. If you're not abstracting your chores, you've been doing it wrong.

Go fought me at every step trying to abstract away boilerplate.

I'm not sure how you mean it fought you. I've been writing libraries and utilities in Go for something like 5-6 years now though, so maybe what you and I perceive as "fighting" differs.
Post reply on HN