Yes, in terms of concepts, Go is pretty much a Java 1 with a native compiler as default implementation.

However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language.

>> However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language.

Yeah, only that you wont do this sort of things in a memory managed language like Go.

They make you think is low level(PR ?), only that it isnt THAT low level ;)

Go should be able to switch off the GC, and allow people do to manual memory management if it really want to be that low-level..

Also, a way to take off the runtime, and work as skinny as any C program could..

Only than, you could make real low-level programming like OS, device drivers and the like..

The use cases for Go right now in its current incarnation, are things like: cloud/distributed stuff(against C++), or command line tools (against Python)

To make it a contender against C, there's a long road.. and im sure its one route they dont want to go..

No one forbids you to call into the OS and manually allocate memory.

Oberon family, Modula-3 are two examples of languages with OS that were used in real life situations, although in academic context, for several years.

Native Oberon System 3 and AOS were quite powerful desktop OS for the 90's.

Although I must concede their unsafe package is more powerful than Go's unsafe package.

Anyway, nowadays I personally prefer Rust or D nowadays.

The problem is not that you can't manually allocate memory, it's that you cannot not automatically allocate memory.

That's debatable, as you can write the code in such way that it does not trigger allocations in a specific situation where it might be critical.

Having used Native Oberon in the 90's, I became convinced that system programming languages with GC are possible.

Latest versions of AOS even had video players with good framerate written in Active Oberon, with some Assembly snippets.

However, in the Oberon family, besides NEW, the other implicit memory allocations are only triggered by string manipulation and starting tasks, if I recall correctly.

That helps, but in some domains, it's 100% unacceptable. For example, kernels or more intense, high-end video games. And can you tell Go's GC not to run for a period of time? I thought that it could stop the world at any time.

Don't get me wrong, I do 90% of my coding in a garbage-collected language. But any mandatory GC does limit your domain.

> That helps, but in some domains, it's 100% unacceptable. For example, kernels or more intense, high-end video games.

However such systems exist.

Kernels => Native Oberon, Blue Bottle, EthOS. All desktop oriented systems used at ETHZ in Switzerland during the 90's. Used for teaching OS design, and a few teachers even used them as their main system.

High end games => The Witcher for XBox 360. They made use of a GC runtime in the game engine.

> But any mandatory GC does limit your domain.

I tend to think the limit is more religious than practical.

Please note that I defend GC enabled systems programming languages, not necessarily Go for such domains.

Seems to be a common sentiment, but from where I'm standing there are at least a few huge differences between Go and Java:

* duck typing * goroutines * channels

And some smaller but still important differences:

* Very light-weight Public/private distinction * Slices * Objects that embed directly in other objects, not as references * Return-value error handling; only a very restricted form of exceptions

> goroutines * channels

java.util.concurrent offers tasks and queues.

As for the rest, they are not unique to Go, better languages offer similar features.

That is a huge mischaracterization and borderline flamebait.

Not even borderline! "Flamebait" was practically invented for that exact type of comment.