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

281–290 of 313 posts

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

#281

Post by morsecodist »

phplovesong wrote: post #264
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.

Having used Ocaml for quite some time, i can understand this. However, i cant tell people (junior devs, or devs who just want to work and does not care about comp-soyery) to learn an ML (+ all the FP idioms) with a straight face. Having a (val, err) tuple IS more easy than returning a monad. Sometimes (most times?) pure procedural code is just the best, and i really hate languages that have feature X but does not sup…

You really don't need to think about monads or functional programming to have option and result. The focus on explaining these in the context of sum types and monads only serves to distract most people. A list is a monad and people use them every day and they are fine.

> Having a (val, err) tuple IS more easy than returning a monad.

Arguments about which concept is easier for people to understand pretty quickly descend into subjectivity but I don't believe this is universally true. Why am I getting a value when there's an error? What do I return as my value when returning errors? Explaining to someone that a function returns (val, err) and only one of these values will be significant is more or less the same as describing a result.

Option is even simpler. It's a list that can have at most one item. Or, you know how in python you can set a variable to None? Here's how to do it in a strongly typed language.

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

#282

Post by lenkite »

morsecodist wrote: post #137
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 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.

I like Go for its standard library but truly hate its nil behaviour and default value semantics. Uber effectively built a static analysis tool from scratch to catch nil issues: https://www.uber.com/en-IN/blog/nilaway-practical-nil-panic-...

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

#283

Post by josephg »

theshrike79 wrote: post #274
josephg wrote: post #218

Earlier quoted context omitted.

Sounds like a waste of time. I’d rather just not have that code in the first place. I don’t want to write it. I don’t want to maintain it. I don’t want to have to scroll past it when I’m working, and have my monitor made artificially smaller because my code has the same repeated error handling code everywhere. What a waste of brain cells.

Sounds yes, but isn't in practice. You look at patterns every time you read code, if the pattern is clear, it's easy to see from far away. Any disruptions in the pattern stop your progress and you need to zoom in to see what's actually going on.

Right; but the computer is much better at fixed patterns than I am. This is the philosophy behind linters, automatic indenting tools in IDEs and gofmt and friends.

Given a choice, I’d rather that the compiler does the work to write “if err != nil …” thing, using any mechanism for it - exceptions, or whatever.

You’re right of course. I can deal with patterns. I do so every day. I can type that code over and over and visually learn to spot when I do it wrong. But I’ve got a computer right here in front of me. I’d rather get the computer to do that work and spend my attention focusing on the task in front of me.

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

#284

Post by runekaagaard »

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 } } ??

A great typing system is generally a good thing if many people work on the same large project. I love how nim typings gets out of your way but are flexible enough to not tie you down.

That being said - by Rich Hickey - typing also add a lot of complexity and non-optimal bindings between stuff. Untyped incremental development with just simple scalar types, and a single list, map and set type is wonderful. Large refactorings, not so much.

Adding gradual typing to a project often gives you the worst of the two worlds. You still fear changing stuff, _and_ have lots of overhead doing all the typing. Either your project is fully type checked at compile time or it isn't.

Python match statements are useful for checking structure and de-duplicating the container name:

    result = {}        
    for temperature in temperatures:
        match temperature:
            case {"city": city, "temp": temp}:
                if temp >= max_temp:
                    result[city] = temp
Oh, and python typing has come a long way:

    from typing import List, TypedDict, Dict

    class Temperature(TypedDict):
        city: str
        temp: int

    def filter_temperatures(temperatures: List[Temperature], min_temp: int) -> Dict[str, int]:
        result = {}
        
        for temperature in temperatures:
            match temperature:
                case {"city": city, "temp": temp}:
                    if temp >= min_temp: # Most of the time >= is what people mean.
                        result[city] = temp
                case _:
                    raise ValueError(f"Wrong temperature format: {temperature}")

        return result

    my_temperatures: List[Temperature] = [
        {"city": "City1", "temp": 19},
        {"city": "City2", "temp": 22},
        {"city": "City3", "temp": 21},
    ]

    print(filter_temperatures(my_temperatures, 20))
    print(filter_temperatures([{"typecheck error": "and runtimeerror"}], 20))

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

#285

Post by bborud »

bunderbunder wrote: post #280
bborud wrote: post #272

Earlier quoted context omitted.

I'm not so sure that we're necessarily talking about small, inexpensive changes here. Anything that changes the fundamental character of a language is probably going to have bigger consequences than you might imagine. I've been writing a fair bit of C lately. I'd say that the way Go error handling works has exactly nothing in common with C. Despite spending 15 years mostly writing C on UNIX 20 years ago, when returni…

Ergonomically, the thing that Go and C have in common about error handling is the thing that the grandparent pointed out - you don't get much language-level support in helping you to remember to check for errors. If you forget, then there's a decent chance that the error condition will be allowed to silently propagate. Structured error handling is as opposed to exceptions. I think that the most famous implementation…

Error handling is tricky because it is (usually) people who write code, and people are lazy and sloppy. Force people to deal with errors and they'll find new ways to not really handle errors.

I'm not opposed to language support for pushing developers to handle errors. But experience suggests it isn't the magic bullet we sometimes tend to think it is.

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

#286

Post by baby »

SpaceManNabs wrote: post #163
baby wrote: post #39

Earlier quoted context omitted.

Yes, like Python and Javascript right? Turns out you don’t need a great language when you provide what most people want: great tooling, good resources to ramp up, great stdlib, etc. Believe it or not Golang was the first language to do this, and probably still the only one? (Rust misses the mark on great stdlib)

> great stdlib Many comments say the opposite of this. I am not too experienced, but I do know that go has a great standard library for web apps.

I'm pretty familiar with Golang's stdlib and other languages stdlib and I'm not sure what the other commenters are on.

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

#287

Post by tick_tock_tick »

mFixman wrote: post #207
tick_tock_tick wrote: post #199

Earlier quoted context omitted.

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

To be honest, I used to use Go before generics became a thing. I'm glad that they implemented some basic library functions 10 years down the line.

Yeah no offense but most of the people online that I find complaining about Go used it a long time ago or got their talking points pre-generics and haven't touched it or really looked at it since then.

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

#288

Post by throwawa14223 »

arp242 wrote: post #186
throwawa14223 wrote: post #157

Earlier quoted context omitted.

Conversely I could go longer between compiles if the type system caught more.

Most of the times when I really care about quick feedback cycles is when I'm experimenting to see what approach does and doesn't work well in the first place. I care a lot less about it for "simple" errors like typing errors, typos, or whatnot. This is mostly trivial stuff compared to "is this entire approach good or not?"

I think I agree with you, but in trivial projects even the infamous slow compilers are fine. Toy Rust projects and small Java projects get compiled very fast.

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

#289

Post by throwawa14223 »

phplovesong wrote: post #265
throwawa14223 wrote: post #34

Earlier quoted context omitted.

As someone with the misfortune of inheriting a million plus loc Go project I disagree. Go is a nightmare from the duck typing to dependency management.

I assume your only part of a larger larger team working on this 1M LOC project? If you are alone with no previous context/knowledge the language does no really matter, you would be in a world of hurt nonetheless.

I agree with you but that pretty much invalidates Go. The whole selling point is that it is lacking anything to make the language interesting to use but you can drop in and any two Go programmers write the same understandable code.

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

#290

Post by bunderbunder »

bborud wrote: post #285
bunderbunder wrote: post #280

Earlier quoted context omitted.

Ergonomically, the thing that Go and C have in common about error handling is the thing that the grandparent pointed out - you don't get much language-level support in helping you to remember to check for errors. If you forget, then there's a decent chance that the error condition will be allowed to silently propagate. Structured error handling is as opposed to exceptions. I think that the most famous implementation…

Error handling is tricky because it is (usually) people who write code, and people are lazy and sloppy. Force people to deal with errors and they'll find new ways to not really handle errors. I'm not opposed to language support for pushing developers to handle errors. But experience suggests it isn't the magic bullet we sometimes tend to think it is.

Completely agreed.

I'm only responding to point out that I never claimed or even implied that there's such a thing as an error handling magic bullet, just that I think that Go's approach to error handling has been oversold. It compares favorably with an "enterprisey" approach to exceptions, precisely because that method makes it so easy to hide the dead bodies. But I don't love that Go's (and C's) approach makes it so easy to implicitly suppress errors, because that's effectively the default behavior. In a language that forces you to check for errors, by contrast, it's harder to be lazy and sloppy without being explicitly lazy and sloppy, which then means that such behavior is more likely (not guaranteed - again, I'm not trying to claim a panacea - just more likely) to be noticed during code review.

Post reply on HN