Comment by rollcat | Hacker News Reader

Comment by rollcat | Hacker News Reader

Parent Full thread

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

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.

Re tuples, I guess you mean the multiple return values, and this assignment form: 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.

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

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.

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

Same reasons why Go fixed C's: inside-out type declarations, function pointer syntax, ERRNO, headers, macros, signal handling, UB, all the things that technically had no "functional" impact but still directly contributed to consistency, ergonomics, clarity, ease of comprehension, and (either by proxy or directly) correctness.

> I can't see a need for 'de-structuring' as such, absent tuples.

Your playground example of a, b = b, a is not destructuring a tuple in action? It's basically the same syntax / mechanism as Python's destructuring assignment, which existed since before Go (except Python's was always more powerful).

It's almost like you can do everything you want with a tuple in Go, except for actually holding it in your hand.

> Even if it had real first class tuple types, like Alef did, what would one do with them?

Similar things you'd do with a function without a name - work directly with the data at hand, without having to do the extra round trip to the attic to declare its name or shape.

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

That would probably break Go. I liked Chris Siebenmann's take on the subject:

https://utcc.utoronto.ca/~cks/space/blog/programming/GoUnion... https://utcc.utoronto.ca/~cks/space/blog/programming/GoUnion... https://utcc.utoronto.ca/~cks/space/blog/programming/GoUnion...

Meanwhile tagged unions bring you virtually all the way to ADTs, where pattern matching (generalised destructuring) is basically a must.

(By the way, Python stumbled really badly when it added pattern matching without even having proper structs. It's almost comical, given def __init__(self, ...), that should've been gone as a part of the 3.0 break-the-world.)

> Similar things you'd do with a function without a name - work directly with the data at hand, without having to do the extra round trip to the attic to declare its name or shape.

Note that in Alef, tuples are essentially a dual for an aggr, but with unnamed fields. So one always has to (explicitly, or implicitly via inference) declare its 'shape', in terms of number of members, and type of members.

So one could declare:

    tuple (int, byte *, int) t;

Then manipulate 't', one could also have a function return a tuple as in:

    tuple (int, byte *, int) something(int x) { /* ... */ }

Then handle its return value either as:

    t = something(2);

or

    byte *str; int value;
    (nil, str, value) = something(7);

However the tuple 'shape' is always statically determined. Is that in your view satisfactory, or not?

Or do you desires something where the tuple is an entirely dynamic type, sort of akin to syntax sugar on top of '[]interface{}'? More akin to the sort of dynamic thing which Python offers?

Such that one can potentially have a program run, and each call to a given function returning a tuple may have different numbers of elements, potentially of different types within it. So that for said program, if the function return value depended upon input data, one could not determine the full set of tuples which may be returned?

Since func() (A, B) is different from func() (A, B, C), I'd expect first-class tuples to do the same. At which point there would be a lot of similarity between (A, B) and struct{A, B}. Perhaps they should be equivalent? From which "struct{a A, b B} = f()", or even "switch x.(type) { case struct{a A, b B}: ...}", or "case (a A, b B): ..." could follow. It might be too much Rust influence, but it might be a good influence, given there's already a lot of interest in unions/enums/ADTs (but see "start with goals").

The counter-arguments are that "type A struct{}" and "type B struct{}" are different types, and that anonymous structs are seldom found in the wild (likely due to their verbosity), but perhaps this is a chicken-and-egg problem? Go already does local type inference, because "var mypackage.VeryLongThing = mypackage.NewVeryLongThing()" is stupidly repetitive. But there's always a fine balance between code being terse and readable (I will never wrap my head around APL).

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.

Here's a good one: https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

The problem is futures (async/await) as a concept; JavaScript, Rust, etc all have the same problems.

Take CSP by contrast: https://en.wikipedia.org/wiki/Communicating_sequential_proce...

Any Go function can take a channel, return a channel, or use a channel (and spawn goroutines) internally, unbeknownst to the caller/callee. It may lead to some bad design decisions (code that must not be async may never be), but it won't get in your way when you least need a refactor.

If you're having problems with async in languages it isn't your fault.

Spinning off a thread for a single small purpose and trying to synchronize with the result seems fine in theory, but it is a very small piece of the larger puzzle of concurrency and usually gets people into trouble once they realize they need more, because anything more complicated than that one use case becomes very tricky.

tl;dr Async/await is what the Python community has settled on, so I don’t think there’s any point in resisting it now, but the fact that it happened is a historical curiosity from my point of view.

-----

I’m not the person you replied to, and I actually don’t have anything against async/await as a pattern where it is needed, but I know that prior to Python getting async/await, there were some moderately popular green threading / coroutine libraries like gevent and eventlet. You would (mostly) just write normal, synchronous Python, and then blocking calls would be intercepted by the runtime and allow other coroutines to take their turn. This felt Pythonic to me at the time, because most code would work in both sync and async environments. You didn’t have to write a separate async version, and you didn’t really have to update old libraries.

The other pre-async/await approach was taken by Tornado and Twisted... basically a form of callback hell. I don't think anyone liked this, but it might have been popular because it worked... and unofficial green threading implementations like gevent/eventlet sometimes broke in interesting ways. (I think officially incorporating a gevent/eventlet-style solution into Python would have overcome most of the issues... but, that's just my speculation.)

I’ve never used Python professionally outside of some short scripts, but it was one of the first languages I used seriously for hobby stuff back during the early days of the Python 3 transition. I never fully understood why Python chose to switch to async/await. Promises can be useful for structured concurrency patterns, but as someone who has been writing Go professionally for a number of years… I just don’t think most code should need to be async-aware.

For a language like Rust, I think async/await makes perfect sense. Rust cannot afford to impose a runtime on everyone, and async/await can be implemented in a very low level, efficient way that gives the developer as much control as they need. This kind of ultra-low-level optimization stuff just isn’t relevant to Python… so, as an outsider, I almost wonder how (in Python) async/await isn’t just a clunkier coroutine system.

If I were to try to rebut my own comment, I would say that async/await was probably chosen because "explicit is better than implicit", and green threading might have been too implicit for the Python community's tastes.

There are a few truths in this. I’ve been involved in a few large projects written in Python and have seen both ups and downs.

Green threads required extensive monkey patching, and debugging those programs was incredibly hard. Instagram moved from them to async/await and wrote a blog post about it, iirc.

But I agree that Python’s async/await implementation is a bit too low-level and could use better abstractions. A lot of the hate Python async gets is due to the `asyncio` library. It’s a shame that the default library is full of deprecated and gotcha-ridden APIs. Trio attempted to fix these, but adoption has been low.

The community settled on async for the same reason I love Go despite all its faults. It’s flawed, but you can build successful systems with it. Lots of companies still write new services in async Python instead of Go because, as big as the Go community is, Python’s is absolutely ginormous.

Plus, LLMs brought more new people to Python than most other languages, and it’s easier to find Python developers and teach them async than to hire Gophers.

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.

Okay, but there are people who hate Go but are stuck with it at work, and would like it to be more expressive etc.

Reply on news.ycombinator.com