4 ms·

The comparisons to python are a bit dated now. All of the examples can be implemented in python using typing extensions [0] and statically checked before runtim

The comparisons to python are a bit dated now. All of the examples can be implemented in python using typing extensions [0] and statically checked before runtime using mypy [1]. [0] https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html (from Python 3.5 - released Sep 2015) [1] https://github.com/python/mypy https://github.com/python/mypy (v0.1 released Sep 2009)

rednafi 2y ago
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.
globular-toast 2y ago
More specifically, you can do interfaces with Protocol[0]. The main problem with it seems to be as soon as you a single Protocol mypy becomes extremely slow. [0] https://docs.python.org/3/library/typing.html#typing.Protocol https://docs.python.org/3/library/typing.html#typing.Protoco...

rednafi 2y ago

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.

globular-toast 2y ago

More specifically, you can do interfaces with Protocol[0]. The main problem with it seems to be as soon as you a single Protocol mypy becomes extremely slow. [0] https://docs.python.org/3/library/typing.html#typing.Protocol https://docs.python.org/3/library/typing.html#typing.Protoco...