[Daishiman]

A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system.

Seriously; LuaJIT achieves greater performance and has more abstractions in place; Rust fills the niche of systems programming languages easily.

I just fail to see the long-term utility of Go in a space where you have upcoming, high-performance languages like Julia and Rust, all while V8 and asm.js continue to improve in performance, LuaJIT wipes the floor in sheer speed for a dynamically typed language, C++ gets saner abstractions every day and the Erlang VM gets such a nice language as Elixir in the space of critical distributed apps.

Go would be interesting if you were at least getting something interesting out of that garbage collector in terms of type system goodness; as it stands Go is only slightly safer than C in that regard.

And by the way: what the hell does not having a Map() function have anything to do with performance? C++11 has std::transform which goes as fast as anything else. Any functional traversal of data structures can be trivially turned into an internal representation with the same performance characteristics as a loop. It's the biggest cop out ever.

[pjmlp]

> A systems programming language would never come with a baked-in, hardcoded garbage collector incapable of soft realtime applications and such a limited scope in utility, not such a constrained set of concurrency primitives and such a basic type system.

- Mesa/Cedar (Xerox PARC)

- Modula-3 (Compaq/Olivetti)

- Oberon/Active Oberon (Swiss Federal Institute of Technology)

- Sing# (Microsoft Research)

- D (Digital Mars)

[dbaupp]

Presumably you're contesting the garbage collection point? However, the statement was a conjunction of that and:

- not such a constrained set of concurrency primitives

- such a basic type system.

I imagine those languages have a good type system and/or good concurrency primitives (i.e. possibly making up for their GC "penalty").

[pjmlp]

My main point was GC, yes.

Actually the original Oberon type system is simpler than Go's. Its later revision Oberon-07 is even simpler.

All the other ones I mentioned, have better type systems than Go, even support for some form of generics.

Concurrency depends on the language, but you get a mix of threads, co-routines, tasks, active objects and processes, overall.

[virmundi]

Something that gets lost in the use of "System Language" is that the language was intended to make systems like a web server. This can have a garbage collector since it can pause a bit.

[Daishiman]

My point exactly is that Go provides nothing in this domain that hasn't been extensively traversed by other languages.

[tptacek]

Language war? Really?