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

31–40 of 80 posts

Re: Go Data Structures: Interfaces (2009)

#31

Post by pjmlp »

neonsunset wrote: post #27
pjmlp wrote: post #26

Earlier quoted context omitted.

Yes, and 25 years later Java is still relevant enough that Microsoft has become yet again a Java vendor, with their own distribution, made the key contribution for Windows ARM support, VSCode Java experience is still ahead of C# DevKit thanks collaboration with Red-Hat, and doesn't require an additional licence. At the same time, JVM has embraced the polyglot ecosystem CLR was supposed to be, while C# seems to have s…

If you have to reach for popularity as an argument in favour of technology X or platform Y, perhaps it's not a technical point you want to make? > VSCode Java experience is still ahead of C# DevKit thanks collaboration with Red-Hat, and doesn't require an additional licence. I'm not sure if you're intentionally attempting to make inflammatory replies or something in what I said rubbed you the wrong way. (for other re…

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 being optional doesn't change the fact specific features are only available when users opt into using it, with a corrrespondig Visual Studio license.

And yes, this irritates me, because I feel it is a disservice to .NET community how Linux and macOS developers are kind of 2nd class, not by .NET team themselves, but higher up Microsoft management.

Re: Go Data Structures: Interfaces (2009)

#32

Post by pjmlp »

kgeist wrote: post #30
pjmlp wrote: post #28

Earlier quoted context omitted.

That was the Ext-VOS project, that I made a reference to. WinRT was supposed to replace .NET by the original goals, after the Sinofsky and his followers took over Windows development after Vista, it has been COM as the main API. "Turning to the past to power Windows’ future: An in-depth look at WinRT" https://arstechnica.com/features/2012/10/windows-8-and-winrt... However as we all know by know, it didn't went down a…

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

Re: Go Data Structures: Interfaces (2009)

#33

Post by TheDong »

philippta wrote: post #12
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.

Because the latter would incur a hidden O(n) computation.

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

Re: Go Data Structures: Interfaces (2009)

#34

Post by foldr »

TheDong wrote: post #33
philippta wrote: post #12

Earlier quoted context omitted.

Because the latter would incur a hidden O(n) computation.

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.

Re: Go Data Structures: Interfaces (2009)

#35

Post by saghm »

nlitened wrote: post #24
saghm wrote: post #19

Earlier quoted context omitted.

Yeah, I have plenty of criticisms of Go, but this is something that it got right. For those who aren't familiar with the issue, in Java you can assign an array of a subclass to a variable declared as an array of the superclass, which leads to issues if you actually try to mutate it. Imagine if Cat and Dog both inherit from Animal, assigning a Dog[] to an Animal[] is totally valid, but then setting one of the elements…

I can’t help but keep noticing that all of the notorious problems with OOP are not due to inheritance, but due to mutability.

I don't know if I disagree with you or not, but having not used a language with inheritance with a while, I also don't really miss it at all. Even if it doesn't cause problems on its own, it just doesn't feel like it provides that much that can't be provided via some other mechanism either.

For what it's worth, I'm not sure this is even something I'd consider a "notorious" problem with OOP because the solution is really simple and wouldn't break anything else if done correctly from day one: just don't allow using arrays of subtypes in a place where an array of its supertype is expected. This was already known at the time Java was designed, and I'm pretty sure the people who designed Java knew it too; they just didn't pick the right way to handle it in my opinion. There's nothing inherent about OO that makes this bug that much harder to deal with than any other language because it can happen in any paradigm with subtyping (as demonstrated by the fact that it could have been present in Go if they did allow casting arrays of interfaces in that way).

Re: Go Data Structures: Interfaces (2009)

#36

Post by neonsunset »

pjmlp wrote: post #31
neonsunset wrote: post #27

Earlier quoted context omitted.

If you have to reach for popularity as an argument in favour of technology X or platform Y, perhaps it's not a technical point you want to make? > VSCode Java experience is still ahead of C# DevKit thanks collaboration with Red-Hat, and doesn't require an additional licence. I'm not sure if you're intentionally attempting to make inflammatory replies or something in what I said rubbed you the wrong way. (for other re…

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 it is overall worse (read: less stable) than just using IntelliJ Idea in a way that isn't an issue when doing so in C#/Go/Rust/TS.

Re: Go Data Structures: Interfaces (2009)

#37

Post by rollcat »

rednafi wrote: post #20
meander_water wrote: post #11

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 (from Python 3.5 - released Sep 2015) [1] https://github.com/python/mypy (v0.1 released Sep 2009)

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

Re: Go Data Structures: Interfaces (2009)

#39

Post by zozbot234 »

nlitened wrote: post #24
saghm wrote: post #19

Earlier quoted context omitted.

Yeah, I have plenty of criticisms of Go, but this is something that it got right. For those who aren't familiar with the issue, in Java you can assign an array of a subclass to a variable declared as an array of the superclass, which leads to issues if you actually try to mutate it. Imagine if Cat and Dog both inherit from Animal, assigning a Dog[] to an Animal[] is totally valid, but then setting one of the elements…

I can’t help but keep noticing that all of the notorious problems with OOP are not due to inheritance, but due to mutability.

Interface inheritance is OK (as long as you pay attention to these issues) but implementation inheritance is a huge mess because it's effectively antithetical to modularity. Your entire class hierarchy must be understood/evolved as a whole if you use implementation inheritance, that's the only way to avoid running into severe problems with its semantics as the code changes over time. Of course that's not exactly the most common approach given that class hierarchies in many real-world codebases are large and it's just not practical to survey them as a whole.

Re: Go Data Structures: Interfaces (2009)

#40

Post by rollcat »

philippta wrote: post #12
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.

Because the latter would incur a hidden O(n) computation.

It's not just the O(n), you must think of interface{} as a pair (concreteType, pointerToMutableData). It's a can of worms, allocating n*2 word-sized objects for each rune is just the surface layer - strings in particular are immutable.

I think Go does the right thing to make this allocation and assignment explicit, you may be a little less surprised with how the program actually behaves. https://go.dev/play/p/PzuBpM66VX2

Post reply on HN