[hacknat]

0. It does dynamic linking on most stdlibs (libc, etc)

1. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly)

2. Generics would be nice. Who knows, maybe they'll be in 2.0?

Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in golang from the start (so that it could be part of the libs). Also having your own scheduler kind of breaks debugging, you can build go programs with gccgo, but gdb doesn't work because it has no concept of what a "go routine" is. Delve (https://github.com/derekparker/delve) will eventually fill the hole of the missing debugger, imo.

Edit:

Formatting

[pjmlp]

> What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly)

Oberon, AOS, EthOS, Singularity and Midori projects prove otherwise.

Go just needs an OS research PhD student proposing "Goberon" to their tutor.

[aikah]

> 2. Generics would be nice. Who knows, maybe they'll be in 2.0?

There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.

[hacknat]

Not that I even care that much, but that's total crap. Compile-time generics, which is what most people seem to be referring to when they say they want generics in Go, are eminently doable. It would not be hard to implement. Runtime generics are probably possible as well.

What are you even basing your assertion on?

Edit:

What do you mean, "there will never be a 2.0"? Do you have a crystal ball?

[pjmlp]

The team has already stated "The language design is done".

[grey-area]

The issues list has a bunch of breaking changes they've put off to Go2. It won't come soon, but probably at some point they will produce a Go2, if only to fix a few small annoyances and things they got wrong in the stdlib which would otherwise break the Go1 pledge. Of course, that doesn't mean Go2 will introduce lots of huge changes to the language, I doubt very much it would, but it probably will happen sometime.

https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+l...

As another datapoint, here are the answers of the team to a question on what they dislike about Go1. These are mostly breaking changes which would require a Go2. I don't think anyone is hostile to it long-term, they're just not in a hurry. There is a huge value to developers in not having churn in an ecosystem and breaking changes, I and many others really value that and am pleased they take this approach.

https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...

So I think you've misinterpreted the above statement, it was probably an off hand remark in response to proposals for Go1 which would have radically altered the language (I can find no ref to it on the web, 0 results for that phrase).

[pjmlp]

Update to my reply.

"So… when is Go 2?", Slide 38

"No plans. Maybe never.", Slide 39

https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMN...

[pjmlp]

It was done at one Strange Loop talk if I recall correctly.

[aikah]

> Compile-time generics

I don't even know if it's possible at this point, since it would break Go's reflection library. No IMHO it's designed not to be extendable at all.