5 ms·

One thing I like about Go is that you can read a decade-old blog and still find it somewhat relevant. Python was the first language I made money with. However,

One thing I like about Go is that you can read a decade-old blog and still find it somewhat relevant. Python was the first language I made money with. However, these days, I struggle to read and make sense of type-ridden, generic-filled, Pydantic-infested Python code.

rollcat 2y ago
> Python was the first language I made money with. However, these days, I struggle to read and make sense of type-ridden, generic-filled, Pydantic-infested Python code. I'm in the same boat. Python was great when it was a snake. I liked additions like the "with" statement - they were very pythonic. I think it's good when the language evolves, although the direction Python took feels more like grafting - oh people like cats, so let's graft some fur onto the snake; people like bats so let's attach wings. The creature no longer resembles a snake, or any other animal for that matter. I still think Python 3.0 was the right thing to do - get rid of "old style" classes, default to Unicode strings, be strict about mixing Unicode with bytes, etc. While there, I wish we got rid of the __init__(self, ...) crap - repeating yourself three times was absurd. The language was getting better up until 3.4 or so, and it slowly started going downhill from there, async being the inflection point. I don't think you can fix it anymore. Python 4.0 will never happen, at least not the way 3.0 did. Go has its problems too. "if err != nil" is awful - stack unwinding exists, but it's awkward and "bad style". Tuples exist, but not as a first-class object. Generics dropped way too late (but at least I'm happy we went thru so many proposals, finally settling on something actually reasonable). Past mistakes cannot be easily undone, so I'm happy it's taking a more conservative approach.
- dotancohen 2y ago
  Please state you musings about the async. I'm just getting into that right now and I wonder if my misgivings are a result of my age or a fundamental issue with the Python implementation of the concept. Seriously, all and any insight and advice appreciated. Thanks.
  - rednafi 2y ago
    [flagged]
    - neonsunset 2y ago
      [flagged]
      - rednafi 2y ago
        [flagged]
        neonsunset 2y ago
        > Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency. I know, which is the exact reason the reply states "uncharacteristically". And yet, it fails to acknowledge existing terminology and tradeoffs and just states at the end in a couple paragraphs how Goroutines shall deliver us all from evil (which could not be demonstrably further from the truth). Surely we need to expect better from one of the Dart's authors than forgetting to mention all the caveats virtual threading via stackful coroutines comes with? And this completely ignores that Go applications end up having to reimplement .NET's task system system anyway and that Goroutines are poorly suited for "fine-grained" concurrency. Even the UX of Goroutines is bad. Want to return a value when one exits? Be sure to not screw up synchronizing and passing the data by hand. One must imagine Gophers writing all that boilerplate happy. I suppose, it's a preferred pastime to learning the internals and ceasing to post the same tired shibboleths.
        rednafi 2y ago
        [flagged]
        neonsunset 2y ago
- rednafi 2y ago
  This is a more elaborate version of how I feel about Python these days. Python is still a much nicer language than something like JS, but it hasn’t been very successful at saying no to things. I like type hints, but it’s easy to go overboard with them. Pydantic and FastAPI are great. The problem is that typenauts and academics coming from other languages are trying to bring every feature under the sun to Python. The core team hasn’t been able to fight this barrage of feature requests. The same is true for Go. I regularly see Rust/Haskell folks talking about how things could be better if Go had xyz feature. While it’s true that Go would probably have benefited from a little more expressiveness, how much more? Where do you stop? I like Go because it’s not Rust or Zig. I mostly write server software, and Go is far more productive in that space. The Go team understands this and is much more protective about scope creep. Keep your type theory off my lawn and let me make money in peace, please.
  - esafak 2y ago
    Okay, but there are people who hate Go but are stuck with it at work, and would like it to be more expressive etc.
- dfawcus 2y ago
  Re tuples, I guess you mean the multiple return values, and this assignment form: https://go.dev/play/p/vxm6lV7JS4z https://go.dev/play/p/vxm6lV7JS4z However how would real first class tuples be an improvement in Go? Alef had them, and allowed various manipulations, as well as returning them, and passing them to functions. I note that they are present in Hare, but not present in Odin. Where the latter has the Go inspired multiple return values, but (AFAICS) no tuples, but does add tagged unions. Generally I'd not want to store a tuple, preferring a struct with named fields. So the only uses I can think of are those temporary ones for multiple return values and assignments, which are already covered.
  - rollcat 2y ago
    My issue with Go's implicit tuples is similar to the pre-1.18 generics built into the language. We've had generic append since before 1.0, but it was "magical", you couldn't write your own generic append for e.g. a custom container. We've later managed to add generics in a way that didn't make append, make, etc seem out of place; but make remains a function with an optional, typed second parameter, IIRC the only one of its kind. The implicit tuples seem just as magical. You can have func f()(int, error), but a:=f() is an error. It's arguably better than Lua (which ignores the second value), but arguably loses to Python (which returns a proper, first-class tuple). Similar with destructuring. You can have g() struct{int;error}, but not i,err:=g() or struct{i, err} := g(). You can have f()(int, error), but again not a:=f(). You can have h(int, error) with h(f()), but that's a hardcoded special case, and somewhat unintuitive, since it violates x:=f(); h(x) - which would however hold in case of returning a struct. Go is just less composable, full of arbitrary exceptions and edge cases. (I do still love it though.)
    - dfawcus 2y ago
      Sorry, but your response seems to be about consistency, or "purity" at some level. While what Go has may be inconsistent, what functional impact does that have? I can't see a need for 'de-structuring' as such, absent tuples. Even if it had real first class tuple types, like Alef did, what would one do with them? As I indicated, I'd not want to store them (other than holding in locals), prior to use. As I recall, Alef did support de-structuring with tuples, as well as re-structuring. One could assign either way between an unnamed tuple, and an 'aggr' (it's name for a struct). So at most I'd want to break them apart, which the return value thing gives. Hence if I was creating Go 2.0, I can't see why I'd want to add first class tuples, but could see a use for adding tagged unions.
- throawayh666 2y ago
  Wow, we're on pretty much the same path. Loved Python when I got into it circa 2011. Didnt have prior programming experience, minus basic BASIC and HTML. It was simple enough and the stdlib include enough things to get me going, but it had enough complexity to intrigue me to dive deeper (list comprehensions, bytes vs strings, inheritance vs composition) and I think I learned a ton about programming thanks to it. But these days when I see modern Python, it looks "uncomfortable". It has so many features, and so many ways of doing things that just figuring that out feels like a massive time sink. I write server-side software with Go now. I feel like with Go I can just sit down and start solving problems. That applies even to sitting down and diving into a 10 year old codebase.

rollcat 2y ago

> Python was the first language I made money with. However, these days, I struggle to read and make sense of type-ridden, generic-filled, Pydantic-infested Python code. I'm in the same boat. Python was great when it was a snake. I liked additions like the "with" statement - they were very pythonic. I think it's good when the language evolves, although the direction Python took feels more like grafting - oh people like cats, so let's graft some fur onto the snake; people like bats so let's attach wings. The creature no longer resembles a snake, or any other animal for that matter. I still think Python 3.0 was the right thing to do - get rid of "old style" classes, default to Unicode strings, be strict about mixing Unicode with bytes, etc. While there, I wish we got rid of the __init__(self, ...) crap - repeating yourself three times was absurd. The language was getting better up until 3.4 or so, and it slowly started going downhill from there, async being the inflection point. I don't think you can fix it anymore. Python 4.0 will never happen, at least not the way 3.0 did. Go has its problems too. "if err != nil" is awful - stack unwinding exists, but it's awkward and "bad style". Tuples exist, but not as a first-class object. Generics dropped way too late (but at least I'm happy we went thru so many proposals, finally settling on something actually reasonable). Past mistakes cannot be easily undone, so I'm happy it's taking a more conservative approach.

dotancohen 2y ago
Please state you musings about the async. I'm just getting into that right now and I wonder if my misgivings are a result of my age or a fundamental issue with the Python implementation of the concept. Seriously, all and any insight and advice appreciated. Thanks.
- rednafi 2y ago
  [flagged]
  - neonsunset 2y ago
    [flagged]
    - rednafi 2y ago
      [flagged]
      - neonsunset 2y ago
        > Bob Nystrom worked on Dart at Google and wrote the amazing Crafting Interpreters book. Rob Pike referenced this article in his 2023 talk, Go: What We Got Right, What We Got Wrong, while discussing the trade-offs between CSP and coroutine-driven concurrency. I know, which is the exact reason the reply states "uncharacteristically". And yet, it fails to acknowledge existing terminology and tradeoffs and just states at the end in a couple paragraphs how Goroutines shall deliver us all from evil (which could not be demonstrably further from the truth). Surely we need to expect better from one of the Dart's authors than forgetting to mention all the caveats virtual threading via stackful coroutines comes with? And this completely ignores that Go applications end up having to reimplement .NET's task system system anyway and that Goroutines are poorly suited for "fine-grained" concurrency. Even the UX of Goroutines is bad. Want to return a value when one exits? Be sure to not screw up synchronizing and passing the data by hand. One must imagine Gophers writing all that boilerplate happy. I suppose, it's a preferred pastime to learning the internals and ceasing to post the same tired shibboleths.
        rednafi 2y ago
        [flagged]
        neonsunset 2y ago
rednafi 2y ago
This is a more elaborate version of how I feel about Python these days. Python is still a much nicer language than something like JS, but it hasn’t been very successful at saying no to things. I like type hints, but it’s easy to go overboard with them. Pydantic and FastAPI are great. The problem is that typenauts and academics coming from other languages are trying to bring every feature under the sun to Python. The core team hasn’t been able to fight this barrage of feature requests. The same is true for Go. I regularly see Rust/Haskell folks talking about how things could be better if Go had xyz feature. While it’s true that Go would probably have benefited from a little more expressiveness, how much more? Where do you stop? I like Go because it’s not Rust or Zig. I mostly write server software, and Go is far more productive in that space. The Go team understands this and is much more protective about scope creep. Keep your type theory off my lawn and let me make money in peace, please.
- esafak 2y ago
  Okay, but there are people who hate Go but are stuck with it at work, and would like it to be more expressive etc.
dfawcus 2y ago
Re tuples, I guess you mean the multiple return values, and this assignment form: https://go.dev/play/p/vxm6lV7JS4z https://go.dev/play/p/vxm6lV7JS4z However how would real first class tuples be an improvement in Go? Alef had them, and allowed various manipulations, as well as returning them, and passing them to functions. I note that they are present in Hare, but not present in Odin. Where the latter has the Go inspired multiple return values, but (AFAICS) no tuples, but does add tagged unions. Generally I'd not want to store a tuple, preferring a struct with named fields. So the only uses I can think of are those temporary ones for multiple return values and assignments, which are already covered.
- rollcat 2y ago
  My issue with Go's implicit tuples is similar to the pre-1.18 generics built into the language. We've had generic append since before 1.0, but it was "magical", you couldn't write your own generic append for e.g. a custom container. We've later managed to add generics in a way that didn't make append, make, etc seem out of place; but make remains a function with an optional, typed second parameter, IIRC the only one of its kind. The implicit tuples seem just as magical. You can have func f()(int, error), but a:=f() is an error. It's arguably better than Lua (which ignores the second value), but arguably loses to Python (which returns a proper, first-class tuple). Similar with destructuring. You can have g() struct{int;error}, but not i,err:=g() or struct{i, err} := g(). You can have f()(int, error), but again not a:=f(). You can have h(int, error) with h(f()), but that's a hardcoded special case, and somewhat unintuitive, since it violates x:=f(); h(x) - which would however hold in case of returning a struct. Go is just less composable, full of arbitrary exceptions and edge cases. (I do still love it though.)
  - dfawcus 2y ago
    Sorry, but your response seems to be about consistency, or "purity" at some level. While what Go has may be inconsistent, what functional impact does that have? I can't see a need for 'de-structuring' as such, absent tuples. Even if it had real first class tuple types, like Alef did, what would one do with them? As I indicated, I'd not want to store them (other than holding in locals), prior to use. As I recall, Alef did support de-structuring with tuples, as well as re-structuring. One could assign either way between an unnamed tuple, and an 'aggr' (it's name for a struct). So at most I'd want to break them apart, which the return value thing gives. Hence if I was creating Go 2.0, I can't see why I'd want to add first class tuples, but could see a use for adding tagged unions.
throawayh666 2y ago
Wow, we're on pretty much the same path. Loved Python when I got into it circa 2011. Didnt have prior programming experience, minus basic BASIC and HTML. It was simple enough and the stdlib include enough things to get me going, but it had enough complexity to intrigue me to dive deeper (list comprehensions, bytes vs strings, inheritance vs composition) and I think I learned a ton about programming thanks to it. But these days when I see modern Python, it looks "uncomfortable". It has so many features, and so many ways of doing things that just figuring that out feels like a massive time sink. I write server-side software with Go now. I feel like with Go I can just sit down and start solving problems. That applies even to sitting down and diving into a 10 year old codebase.