Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Data Structures: Interfaces (2009)

research.swtch.com

Post reply on HN
Print view View original

41–50 of 80 posts

Re: Go Data Structures: Interfaces (2009)

#41

Post by debugnik »

foldr wrote: post #34
TheDong wrote: post #33

Earlier quoted context omitted.

since when has that stopped go? “[]rune(someString)” is O(n) and quite inobvious The O(n) loop is here: https://github.com/golang/go/blob/215de81513286c010951624243...

It’s obvious that this is O(n), no? You’re casting something immutable to something mutable, so it has to be copied.

And decoding subsequences of UTF-8 code units (bytes) into Unicode scalars (runes), which also forces a copy.

But why did Go pick the same syntax for cheap conversions and expensive ones, though? I'd expect this to be a standard function, not a type conversion.

Re: Go Data Structures: Interfaces (2009)

#42

Post by dotancohen »

rollcat wrote: post #37
rednafi wrote: post #20

Earlier quoted context omitted.

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.

> 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 lik…

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.

Re: Go Data Structures: Interfaces (2009)

#43

Post by rednafi »

rollcat wrote: post #37
rednafi wrote: post #20

Earlier quoted context omitted.

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.

> 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 lik…

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.

Re: Go Data Structures: Interfaces (2009)

#44

Post by sltkr »

saurik wrote: post #4
zknill wrote: post #2

A quirk of Go is that I can cast a `[]string` to `interface{}`, but I cannot cast `[]string` to `[]interface{}`. This blog post is my go-to explanation for why the second is not possible but the former is.

Is that really a "quirk" of specifically Go? I am pretty sure Java--the implementation of which defined a lot of how numerous languages handle this kind of thing--has the same behavior: you can cast String[] to Object, but not Object[].

Actually in Java you can cast String[] to Object[] although this is technically unsound.

This how generic methods like Arrays.sort() are implemented.

Re: Go Data Structures: Interfaces (2009)

#45

Post by rednafi »

dotancohen wrote: post #42
rollcat wrote: post #37

Earlier quoted context omitted.

> 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 lik…

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.

[flagged]

Re: Go Data Structures: Interfaces (2009)

#46

Post by coder543 »

dotancohen wrote: post #42
rollcat wrote: post #37

Earlier quoted context omitted.

> 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 lik…

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.

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.

Re: Go Data Structures: Interfaces (2009)

#47

Post by pjmlp »

neonsunset wrote: post #36
pjmlp wrote: post #31

Earlier quoted context omitted.

Unfortunately not always the best technology wins out, and the turns that go around them are nonetheless quite interesting. I am stating facts, do you want links to .NET team interviews where they assert it is a business decision VSCode is never going to achieve feature parity with VS for .NET? VSCode for Java doesn't have such artificial constraint, hence the better tooling, mainly implemented by Red-Hat. C# DevKit…

No, I don't. Developer tooling teams which ship Visual Studio and DevKit are almost completely separate from the teams overseeing the development of .NET itself (including the team responsible for the SDK). And, honestly, I could not care less because it does not affect me or my colleagues in any material way, nor it affects the actual Linux or macOS users. And also, have you tried writing Java in VS Code? I have and…

Ah doesn't affect you that graphical profiling tools are only available on VS, that management thought for a brief second to make hot reload VS only (saved by .NET community uproar and folks like Hanselman jumping onto discussion?), or that MAUI designer was thrown into the garbage can, and what is now available is pretty much WIP?

Lucky one I guess.

I have used it, its stability issue is orthogonal to feature parity, being whole Eclipse running headless, which is the point, features.

Re: Go Data Structures: Interfaces (2009)

#48

Post by neonsunset »

rednafi wrote: post #45
dotancohen wrote: post #42

Earlier quoted context omitted.

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.

[flagged]

[flagged]

Re: Go Data Structures: Interfaces (2009)

#49

Post by kgeist »

pjmlp wrote: post #32
kgeist wrote: post #30

Earlier quoted context omitted.

I never heard about "Ext-VOS". Tried googling it, and all mentions of it are from you ("pjmlp"), on Reddit, Github, etc. :) Where can I read more about it?

Don Syme from .NET generics and F# fame has written about it, that is how we got made aware of it. Now those blog posts are kind of gone from their original hosts. F# HOPL paper, https://fsharp.org/history/hopl-final/hopl-fsharp.pdf Original blog post on way back machine, including the link to "MSR White Paper: Proposed Extensions to COM+ VOS (Draft)" paper. https://web.archive.org/web/20190111203733/https://blogs.ms…

OK, so from what I've read, "VOS" was the older name for CTS (Common Type System), not the name of the whole project. The project was named COM+, COM Object Runtime, and Project Lightning at different times. "Ext-VOS" ("extensions to VOS") is a document that primarily proposes generics, which were only added in C# 2.0.

Re: Go Data Structures: Interfaces (2009)

#50

Post by rednafi »

coder543 wrote: post #46
dotancohen wrote: post #42

Earlier quoted context omitted.

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.

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…

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.

Post reply on HN