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

21–30 of 80 posts

Re: Go Data Structures: Interfaces (2009)

#21

Post by skitter »

kgeist wrote: post #6
saurik wrote: post #4

Earlier quoted context omitted.

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

C# allows casting string[] to object[], but this requires the compiler to insert runtime type checks each time the array elements are modified: object[] array = new string[10]; // throws a run-time exception array[0] = 10;

C# inherited this from Java, which added it because it was designed without generics and therefore decided that the additional expressiveness provided by enforced array covariance was worth the tradeoff of having an unsound type system.

Re: Go Data Structures: Interfaces (2009)

#22

Post by neonsunset »

pjmlp wrote: post #18
neonsunset wrote: post #13

Earlier quoted context omitted.

Note that array covariance is largely considered a design mistake and if .NET was to be redone it wouldn't have one (and a bunch of smaller things that are an artifact of generics getting introduced in C# 2.0 and not 1.0, well, the problem is much worse in Go heh). Other data structures like List , Span , etc. do away with covariance. There's an upcast for ReadOnlySpan but only because it's zero-cost and does not int…

Well, .NET only exists in first place because of Sun's lawsuit, Ext-VOS was designed with J++ in mind. Thus having high compatibility with how Java used to be was a big factor designing C# 1.00

25 years ago :)

Re: Go Data Structures: Interfaces (2009)

#24

Post by nlitened »

saghm wrote: post #19
duskwuff wrote: post #5

Earlier quoted context omitted.

> I can cast a `[]string` to `interface{}`, but I cannot cast `[]string` to `[]interface{}` Surely that's just contravariance, though? You can't cast []string to []any because that would allow you to write non-strings to it.

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.

Re: Go Data Structures: Interfaces (2009)

#25

Post by kgeist »

pjmlp wrote: post #18
neonsunset wrote: post #13

Earlier quoted context omitted.

Note that array covariance is largely considered a design mistake and if .NET was to be redone it wouldn't have one (and a bunch of smaller things that are an artifact of generics getting introduced in C# 2.0 and not 1.0, well, the problem is much worse in Go heh). Other data structures like List , Span , etc. do away with covariance. There's an upcast for ReadOnlySpan but only because it's zero-cost and does not int…

Well, .NET only exists in first place because of Sun's lawsuit, Ext-VOS was designed with J++ in mind. Thus having high compatibility with how Java used to be was a big factor designing C# 1.00

.NET is still called COM+ in .NET's source code, they initially envisioned .NET as a successor to COM. They wrote about COM+ in 1997 in an issue of Microsoft Systems Journal (they talked about GC, runtime type info, etc.) It makes me believe the idea for .NET (COM+) existed before the lawsuit. It's possible that after the lawsuit, the COM+ and J++ teams were merged to reposition it as mainly a Java alternative.

Re: Go Data Structures: Interfaces (2009)

#26

Post by pjmlp »

neonsunset wrote: post #22
pjmlp wrote: post #18

Earlier quoted context omitted.

Well, .NET only exists in first place because of Sun's lawsuit, Ext-VOS was designed with J++ in mind. Thus having high compatibility with how Java used to be was a big factor designing C# 1.00

25 years ago :)

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 sucked the life of all those language implementations demoed at the launch back in 2001, and .NET SDK being offered on computer magazine CDs.

Which is kind of interesting, how things have changed 25 years later.

At least we finally have cross platform support (ignoring Mono and DotGNU efforts), and good AOT instead of NGEN, which should have been there on .NET 1.0.

Re: Go Data Structures: Interfaces (2009)

#27

Post by neonsunset »

pjmlp wrote: post #26
neonsunset wrote: post #22

Earlier quoted context omitted.

25 years ago :)

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 readers - this marks me posting for 20th time here that DevKit is an optional product and thousands of developers are happily coding in C# in VS Code and VSCodium, Neovim and Emacs without ever running into it)

Re: Go Data Structures: Interfaces (2009)

#28

Post by pjmlp »

kgeist wrote: post #25
pjmlp wrote: post #18

Earlier quoted context omitted.

Well, .NET only exists in first place because of Sun's lawsuit, Ext-VOS was designed with J++ in mind. Thus having high compatibility with how Java used to be was a big factor designing C# 1.00

.NET is still called COM+ in .NET's source code, they initially envisioned .NET as a successor to COM. They wrote about COM+ in 1997 in an issue of Microsoft Systems Journal (they talked about GC, runtime type info, etc.) It makes me believe the idea for .NET (COM+) existed before the lawsuit. It's possible that after the lawsuit, the COM+ and J++ teams were merged to reposition it as mainly a Java alternative.

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

Re: Go Data Structures: Interfaces (2009)

#29

Post by neonsunset »

kgeist wrote: post #25
pjmlp wrote: post #18

Earlier quoted context omitted.

Well, .NET only exists in first place because of Sun's lawsuit, Ext-VOS was designed with J++ in mind. Thus having high compatibility with how Java used to be was a big factor designing C# 1.00

.NET is still called COM+ in .NET's source code, they initially envisioned .NET as a successor to COM. They wrote about COM+ in 1997 in an issue of Microsoft Systems Journal (they talked about GC, runtime type info, etc.) It makes me believe the idea for .NET (COM+) existed before the lawsuit. It's possible that after the lawsuit, the COM+ and J++ teams were merged to reposition it as mainly a Java alternative.

> .NET is still called COM+ in .NET's source code

There was mostly no reason to cause unnecessary code churn to rename pre-existing code with complus-named variables inside dotnet/runtime. External-facing features and documentation never reference it. For compatibility reasons it still recognizes env. variables prefixed with COMPlus_ alongside DOTNET_ though.

See: https://github.com/search?q=repo%3Adotnet%2Fruntime%20complu...

In a similar vein, NativeAOT code still prominently references project RedHawk (these are slowly being renamed).

Re: Go Data Structures: Interfaces (2009)

#30

Post by kgeist »

pjmlp wrote: post #28
kgeist wrote: post #25

Earlier quoted context omitted.

.NET is still called COM+ in .NET's source code, they initially envisioned .NET as a successor to COM. They wrote about COM+ in 1997 in an issue of Microsoft Systems Journal (they talked about GC, runtime type info, etc.) It makes me believe the idea for .NET (COM+) existed before the lawsuit. It's possible that after the lawsuit, the COM+ and J++ teams were merged to reposition it as mainly a Java alternative.

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?
Post reply on HN