Go is more a better Python. Even simpler syntax. Types and compiles to native (as they are all the fashion now).

Rust is the best bet we have at a better C (and a better low-level C++).

High level C++ competes with D and Go. Rust is a little too specifically targetted at the low level "systems" programming.

I don't think a "better Python" can be statically typed - dynamic typing, and all the associated runtime tricks that you can do with it, is kinda part of what makes Python distinctive (whether for good or bad, opinions differ there).

Go has this "interface" thing which lets you do duck-typing, and it's checked at run-time, as the types in Python.

This is consumer-side duck typing. Python also provides producer-side duck typing - you can make any of your objects a duck dynamically, by making them behave like a duck at runtime. I'm not aware of anything similar in Go wrt interfaces.

Rust also shines when it comes to high level abstractions. This is what attracts me to the language: as in C++, it covers the super low-level stuff, but it also powerful in business logic abstractions.

Go has far more in common with Java than it does with python. Arcane APIs that are incredibly difficult to use correctly while having a very simple base language.

I found the Go APIs I have worked with far more simple and idiomatic than any Java libraries I have worked with (which is admittedly not a lot).

It is, to a degree a matter of taste, of course, but Go APIs tend to be rather simple, whereas Java libraries seem to often have FileOpenDialogStyleTemplateProcessorFactoryFactory-type interfaces.

The major problem I have with Go currently is lack of function overloading, which means you either have to convert your data around a lot or have many similar functions for different data types that do the same thing (basically), but have different names.

I think the comparison with Python is quite fitting, because both languages encourage a certain way to think about and implementing things. For Python it's called pythonic, in Go it's called idiomatic.

For my edification, could you give an example of such an API in Go?

And more of a spiritual successor than an actual one.

You probably won't be writing kernels with it.

No as Go has a GC. It's just supposed to be a fast server-side language without very complicated code. Go is mostly successful due to Google and filling a niche (fast, simple, concurrent, all thrown into a fat statically linked binary I think).

> No as Go has a GC.

So what, so do Oberon, Modula-3 and many others including D.

Yet quite a few production OSes were even written with them, e.g. Native Oberon for the Ceres Workstation at ETHZ.

I think I'd rather not have GC in my OS. Oberon was a pretty small language, so perhaps the pauses were more acceptable.

It even supported live video editing.

Pauses weren't an issue for users' productivity.

I'd have to know more details to see y that's not a problem. Vastly superior code, or just a very lightweight system.. I dunno.

What is kind of left from the documentation. There are other sources but this one is easier to refer to.

http://www.ocp.inf.ethz.ch/wiki/Documentation/Front

Video editor playing a video on the lower right corner.

http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager?...