Hacker News Reader

Comment by zknill | Hacker News Reader

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.

View on HN

> 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 to a Cat will throw an an exception.

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

The mutability is a red herring here. It depends on what methods your object has and where the generic type resides within the signature. It just so happens that an immutable array has only one relevant "method":

    get :: Int -> T

Here, T is on the right/return side, therefore an immutable array type would be covariant. But a mutable array also has a

    set :: Int, T -> void

which has T on the left/parameter side and therefore requires contravariance (and you cannot have both, therefore you get invariance). But the issue is not with mutability, since you could just as well have something like

    setImmutable :: Int, T -> Array(T)

and you still wouldn't be able to make Array(T) covariant.

And for the record, it is only raw arrays in Java that have this issue, generic types like List<T> are invariant (of course you can explicitly ask for a List<? super T> if you want to only call "setter" type methods on it, or List<? extends T> for getters, aka methods where T appears only on return side).

This setImmutable would return a new instance of Array<Animal> which would not be Array<Cat> like the original, and would contain any mix of cats and dogs.

So immutability resolves the covariance problem, I think?

My main point was that mutability and covariance are two orthogonal concepts that just happen to overlap here due to function signature shape. But it seems that you are right, I cannot think of any expression that would type-check with Array<Animal> but not with Array<Cat>. ChatGPT was very unhelpful in trying to produce a counterexample, since it probably trained on too many entry level stackoverflow posts about this issue.

I've never quite understood enough about types to know why, but: it's more like the difference between read-only and write-only.

One of the variances is safe if you only read, and one is safe if you only write.

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.

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;

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<T>, Span<T>, etc. do away with covariance. There's an upcast for ReadOnlySpan<T> but only because it's zero-cost and does not introduce the issues stemming from covariance.

Luckily, you almost never see someone use array covariance beyond occasional object[] upcasts (and the compiler is also good at reasoning whether to insert covariance checks or not).

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.

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

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.

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

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.

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)

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.

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.

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.

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.

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

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

Huh, fair enough!! What's then funny in the context of this thread is that, while I am sure I knew that 20-25 years ago, it feels so wrong that it would support that -- and more like a "quirk" that it ever would -- that it surprises me (though it certainly doesn't shock me: most things have many quirks).

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

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.

Don't all conversions require copying the value at the level of the language semantics? You can cast a float to an int, but you can't assign an integer value to a float variable (leaving aside whatever optimizations the compiler might make). Casting a float to an int is only cheap because a float is a fixed size. So it seems unsurprising to me that casting a larger value results in a proportionally larger copy.

Most conversions are things like casts to enum types or aliases I think, which never are O(n), like:

    dur := time.Second * time.Duration(2)
    
    headers := http.Header(map[string][]string{})

    httpDir := http.Dir(filepath.Join(parts...))

In all of these cases, it's just a type-cast which is zero-cost, and I think that's what makes it feel surprising that casting between strings/runes specifically incurs more significant computation than any other cast.

All of those are copies and hence O(n) in the size of the value copied. This is hidden somewhat because your examples use constants and literals. (As numeric constants aren’t typed in Go the first example arguably doesn’t involve a copy, but the rest do.)

I didn’t know even know this. TIL, thanks.

Reply on news.ycombinator.com