> And providing a better C.

I keep seeing this come up and I wonder if people have actually used C in the domains where it matters.

Go is not a C replacement/better C. You don't have control over what goes on the stack/heap which means you can't control memory layout. If you can't do that you're throwing away one of the key reasons you'd use C. Memory layout is critical to getting that 10-50x performance that you can't get in a managed language.

There's a bunch of domains where Go excels but if you're on constrained hardware where you really need the last bit of perf/memory it would not be the tool I reach for.

> Go is not a C replacement/better C.

Its not a replacement for C in most of the places where C is far and away the best existing choice for a whole project, it is a replacement for C in the zone where C's performance and static typing are attractive and would decided the choice in its favor, but Python's expressiveness, batteries-included stdlib, etc. also make it attractive and make it a little bit painful that the other factors weigh in C's favor. For a system that you might be otherwise do polyglot Python (or some similar dynamic language)/C development for that reason (or where you might do C-only somewhat reluctantly for that reason), Go could be a reasonable replacement for C (and, in the case where the alternative would be polyglot, Python or whatever else.)

Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements. If you're not taking advantage of data locality then it's possible to approach C's performance in any of those languages.

If your primary concern is performance(which is the only reason I'd reach for C today, esp w/ security concerns) then Go is not going to replace C in that domain.

> Sure, but in those cases Java/Swift/C#/etc are also reasonable replacements.

Well, Swift certainly wasn't when Go was introduced, but, yes, Java and C# were competitors in that role when Go was introduced (Java, even moreso at the time, tended to fall short on expressiveness -- which some argue Go does too, though in different ways -- and C# was deeply tied to .NET, which only had a first-class implementation on Windows; both of those have improved somewhat since Go was introduced.)

Swift probably, but Java and C# still suffer in a lot of situations from the lack of good AOT compilation options. There are implementations for both, but they're incredibly primitive compared to the JIT reference implementations.

Not .NET Native, which uses the same backend as Visual C++.

Unfortunately .NET Native is still for UWP only, so for most places you'd use Go it's pretty useless. Microsoft appears to have no plans to even bring it to ASP.NET: https://github.com/aspnet/Home/issues/285

Probably not, but they have CoreRT instead.

https://github.com/dotnet/corert

Many of us are actually mostly working on Windows, so NGEN, RyuJIT and .NET Native are all very good nice toolchain features.

And if I compare Go with the whole .NET stack and tooling, there are lots of things I see missing, in spite of better AOT support across the board.

... which is still in a fairly early state, like I said. And NGEN doesn't help the issue of runtime dependence at all.

I'm not really a fan of Go, but being able to write small tools in it without pulling in a huge runtime is a big drawback.

But that isn't a language feature, rather a toolchain one.

Once upon a time, on the PC we only had static compilation, regardless of the language.

.NET Core would help with the runtime dependencies (XCopy Deploy), but currently it is also WIP for those of us that care about desktop applications.

Is the .NET stack and tooling any more a language feature? You were happy to argue that tooling was important a moment ago.

In any case, when choosing a language for a project which doesn't fit your requirements because maybe the tooling will get there someday, I think you're going to pretty consistently end up in a sticky situation. I like C# a lot more than Go for most things, and some of the reasons are things you listed, but the goalpost shifting is getting ridiculous.

I am just digressing, sorry if you see it as goalpost shifting.

>it is a replacement for C in the zone where C's performance and static typing are attractive

Was C's "static" typing ever attractive as a static type system?

If the constrained hardware is more powerful than a Xerox PARC Dorado (Mesa/Cedar), a ETHZ Ceres Workstation (Oberon), DEC Firefly (Modula-3), then Go is certainly a better C.

Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed.

In spite of lacking a few features that I consider any modern language should have, ability to create memory friendly data structures isn't one them.

> Nothing prevents you to make use of statically allocated data structures, hands off from the GC if really needed.

Only if you give up closures, interfaces, defer, strings, the entire standard library, and all sorts of other things that don't immediately come to mind.

Programming without the GC in Go is technically possible, but impractical. The language just wasn't designed for that (and this isn't a knock against the language--it just was a non-goal).

I didn't say to not use the GC at all, rather to use it less.

We can use the GC for the 90% of the code that isn't performance critical, enjoying the programming productivity of using a GC enabled language.

After profiling the application and find out where those 10% performance/memory critical hotspots are, re-architect the data structures to use static allocation, either via the stack (compiling with escape analysis validation) or the global memory. Or even doing off-GC Heap allocation via syscalls.

Then make use of pointers or array indexes to access the static allocated data.

Plenty of examples in Modula-3, Oberon, Mesa/Cedar research papers.

There are plenty of languages that I would rather use for systems programming instead of Go, but the language is certainly capable of being used in the same scenarios as Oberon.

For example Astrobe, which sells bare metal Oberon compilers for ARM Cortex-M4, Cortex-M3 and Xilinx FPGA Systems.

If anything, comparing Oberon's SYSTEM with Go's unsafe packages, Go could use a few more intrinsics like CPU register access, but those as also doable with a bit of Assembly help. Which ANSI C also doesn't support.

My goal is just creating awareness that alternatives are possible, it doesn't need to be always C.

> You don't have control over what goes on the stack/heap

You do have this control. There is escape analysis, but I've never had to dance with it to make it put things on the stack when I need them to. I can get very close to C speeds with Go without much effort.

In that sense, Java and C# both have control too.

There are lots of cases in which escape analysis falls down. In particular, higher order control flow (closures/interfaces) will always cause it to fail, until Go implements some sort of higher order control flow analysis (which I doubt it will). Go uses interfaces a lot.

C# doesn't have escape analysis, but it has stack-allocated value types. Java doesn't have stack-allocated value types (yet), but it has escape analysis. It seems a lot harder to me to reason about escape analysis without value types, and I have no idea what happens in C# if you take a reference to a value type (i.e., is it moved to the heap?).

I never meant to imply escape analysis was somehow perfect; only that it is (mostly) easy to reason about.

Can I say X is a value-type(or better annotate it in declaration)? If not then I don't have that control.

Your compiler doesn't know your data access patterns, dataset size or a myriad of other factors that you need to tune if you really want to get full utilization from your hardware. To be clear I'm talking about ~5% of software out there, but when you need it you really need it.

Yes, the distinction between value and pointer types is explicit in the language, so you have all the control. This is, why you also have more control about the memory layout than in Java, which makes a huge difference in performance.

For the time being, until Java 10 gets released.

But how things are going regarding Java releases, Go could even get generics before Java 10 gets released.

Yes, it has value and pointer types, just like C (except without pointer arithmetic).

Just to make myself clear, on the point of 'providing a better C'. I just made that comment from language evolution point of view. And did not at all mean that Go is better than C, in all respects. I dare not say that.

What I meant was taking a step back to a point before C++ was created. And looking ahead, and choosing what works and is essential (strings, GC,... and some modern Internet usage things...concurrency...etc), and getting rid of all the bloat, which actually comes in the way, especially the opinionated bloat on how software should be done e.g. OO. And making a language based on that.

For some reason, this discussion reminds me of Linus Torvald's angry defense of using C, for git[1] :-)

[1] http://harmful.cat-v.org/software/c++/linus

How do you know this isn't just a new language thing ? All of the advantages you say always result from essentially any redesign, and they never last.

A quote from "Java in a Nutshell", from (I believe, 2002):

"Because Java is a simple and elegant language with a well-designed, intuitive set of APIs, programmers write better code with fewer bugs than for other platforms, again reducing development time."

Reads pretty similar to your argument for Go. I remember similar quotes for Modula-2, ML, (a lot of versions of) LISP, C itself, and I'm sure there's many more. It seems to me pretty likely that we're seeing the same evolution : Go currently is a simple, easy language that matches the current hotness (microservices) pretty well, because it was directly written to support that. The current hotness will go away and Go will have effectively-mandatory bloated libraries to support the next hotness, just like today it's becoming close to embarassing to use Go's standard library's http server for anything non-trivial.

Additionally, many of the criticisms of C apply to Go. It's looooooooooooooooooong simple code doing "a; if error { ... }; b; if error { ... }; c; if error { ... } ...". Many abstractions just don't work, and have to be "fixed" with crutches (like sorting, logging, ...)

Aah, Seeing such a good reply, so late. Does HN need notification? Probably not :-)

So, I agree with you a lot. There are no guarantees that Go will remain good for ever. It would be a challenge and need effort on the part of the language developers.

That said, I believe, when a language evolves over a period of 20 years. You get the benefit of hindsight to introduce the good things in a new language. So, Java's garbage collection is a big success. And Go developers incorporated it. Its a tradeoff with extreme (C like) performance, and devs went with convenience and security. Good call, in my opinion.

But the object oriented part of Java, in my opinion, is just a C++ inheritance, as at that point of time (mid 1990s). OO was the silver bullet, to all your sofware spaghetti problems. But as it turns out, it got more complex, if the design/architecture was bad. And good engineers design good enough without the OO.

So Go has taken that approach, which gels with me and lot other developers.

Your comment regarding the error handling part. Yes, it is cumbersome. But surprisingly, it seems to look better than exception handling when you write couple of modules with it. And for some reason, which others have articulated better than I can at this time, your programs are more stable as a result.

So overall what I like about Go, is the minimalist approach of just having the proven things which are good. And avoiding which are grey area or bad.

>By offering simplicity. Taking a step back to before C++. And providing a better C. C + strings + GC + map + slice(array) + json/xml parsing + http transport layer (server & client). What else do you need?

Language consistency (no magical functions like "make" or magical items like slices), DRYness (generics), better type-safety than C (interface{} is the void * of the 21st century), would be a good start.

Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc.

> Due to the mandatory GC, it's also not a C replacement where C is good at. Hence the backtrack on "systems", etc.

I tend to complain on Go's design decisions and don't have any actual use for it, but given my experience with Oberon, I do believe there are use cases where it would be possible to use Go as systems language.

For sure not in when targeting 8 or 16 bit CPUs with a few KBs, or timing constraints that cannot deal with possible GC pauses.

But for more beefy micro-computers like the original PI, it can certainly be an option.

This would a good starting point for anyone trying to attempt it

http://wiki.osdev.org/Go_Bare_Bones

Also I consider the ability to write compilers to be systems programming use cases and Go is already bootstrapped.

Having said this, yes there are better options to do systems programming with less need of Assembly help.

My question was more rhetorical. But thanks.

After posting, I realized its concurrent programming model, is another thing which I (and many others) am a fan of. I found the channel and go based approach, much better compared to explicit spawning of threads in languages like Java and C++.