Go is a great systems programming language especially for modern concurrent systems — http servers etc. It talks to C easily so you can integrate all kinds of system level code into your apps. Having a Garbage collector makes it trivial to write long-running daemons.
Modern operating systems have traditionally been written in C (and C++) plus some assembly language code. D can do everything C & C++ can do but it would still no doubt need the assembly language code.
Go lacks manual memory management. Some say that this would be a barrier for writing an operating system while others don't. The fact that you would have to use some assembly language code to talk to the hardware and you might need to add some manual memory management via assembly language code. After that I'm sure the garbage collector would make the OS more reliable and potentially a little quicker in places.
Either way I don't see why Go gets criticised for needing a bootstrap layer when operating systems written in C and C++ also need this.
What really bothers me about Go is not really that it's garbage collected, but rather that its garbage collector sucks so badly. Really, not all garbage collectors are created equal.
For example I'm working on a startup and we've been integrating with various bidding exchanges for serving targeted ads. All the bidding exchanges want the response to be generated in under 100ms, which includes the network roundtrip. This means on the server-side, the average must not be higher than 10ms per request, preferably lower. Scala on the JVM can handle it, but when I tried out Go, it was a disaster ... as that garbage collector stops the world and it's totally unpredictable, so you end up with spikes of latency that can upset your partners and given enough incoming requests, it can also blow up your buffers/queues, crashing your servers. It's also non-compacting, but that's a given, as it's not even fully precise yet.
Which is the reason for why integrations with bidding exchanges are usually written in C++ too (in case it's not clear, we are talking about B2B web services). We've gone with the JVM because it provides a good productivity/performance balance, but eternal vigilance is needed in profiling the memory allocation patterns and tuning the garbage collector to handle the load. And Go requires even more tuning. Which is why sometimes I fantasise about a high-level language that allows for manual memory management, as things would be so much easier ... although I'm rooting more for Mozilla's Rust, than I am for D.
What version of Go?
Message rate per second?
Message size?
What was the % increase over average response time during GC?
What class of hardware?
I did notice the Go's GC improved between 1.0 and 1.1.
Thanks!
Actually, contrary to C and C++ language specification, in D, support for inline assembly is part of the language specification.
> downvote
sambeau 50 minutes ago | link | parent | flag
I fear you are confusing systems programming language and operating systems programming language (or conflating).
Go is a great systems programming language especially for modern concurrent systems — http servers etc. It talks to C easily so you can integrate all kinds of system level code into your apps. Having a Garbage collector makes it trivial to write long-running daemons.
Modern operating systems have traditionally been written in C (and C++) plus some assembly language code. D can do everything C & C++ can do but it would still no doubt need the assembly language code.
Go lacks manual memory management. Some say that this would be a barrier for writing an operating system while others don't. The fact that you would have to use some assembly language code to talk to the hardware and you might need to add some manual memory management via assembly language code. After that I'm sure the garbage collector would make the OS more reliable and potentially a little quicker in places.
While I am on the D and Rust field, I support Go's ability to do this.
Go is no different from Oberon in system capabilities. And Oberon was used to write quite a few desktop systems used at Zurich's ETHZ during the mid to late 90's.
The OS bootloader and the kernel package for hardware interactions were written in Assembly, with the remaing parts in Oberon.
You can read all about it here, http://www.inf.ethz.ch/personal/wirth/books/ProjectOberon.pd...
> Either way I don't see why Go gets criticised for needing a bootstrap layer when operating systems written in C and C++ also need this.
Because many tend to assume compiler extensions to C and C++ are part of the language.
It is a fun quiz asking C and C++ developers what is part of the standard and what is compiler specific behaviour.
Systems programming doesn't seem to be a very well defined term. My understanding is that it is certainly not application programming and it requires pretty tight management of hardware resources. That includes things like operating systems, database systems, embedded systems, networking software like firewalls, etc.
[0] You know what I mean.
A GC is just a special case of a memory manager.
systems language => for building systems, many parts, many interconnections
operating system language => ability to use the hardware with no limitation. even for a monolithic part.
So... every language?
In a lot of contexts, this is a feature (makes terrible code smells in normal code easier to see), but depending upon the type of coding you do, you do sometimes find yourself wishing it were a bit easier when dealing with things like graphics APIs where you just want to lock a texture, update some bits in-place, and then unlock it. Sometimes what might be a couple lines of C code are 10s of lines of Go code where you either do crazy gymnastics with the unsafe package, or juggle things in and out of byte buffers.
This changed with the recent 0.8, `for` is now syntax sugar for using the Iterator trait, which optimises exactly like C++ (the vector iterator even vectorises when LLVM can do it).
Rust has actually moved to have iterators that are very similar to (a subset of) D's ranges.
It has literally transformed writing D code, and for the better. There's another little feature, -cov, which will tell you which lines of code are covered by the unit tests.
It's hard to understate the improvement these engender.
http://dotsub.com/view/892ed71a-0d53-499d-aaa8-d5e642f2942c
Still, I think you raised valid question in the first part of your message, though the second is a bit offensive and I also thank Andrei for his clarification and use the opportunity to congratulate for this milestone of D language. I like D and even if I use C++ at work, I know I'd enjoy using D especially for the features that let my code "see" and "build" the other parts of the code.
Others have been using it to distinguish languages suitable for writing operating systems/drivers years before Go introduced this confusion.
And does the unsafe package allow you to build a C-style manual allocator or not (regardless of whether it integrates with Go's new or make operators)?
"D has resolutely exited C++'s shade because it is good at things C++ is not good at, in addition to being good at things C++ is good at. Also, Go would be tenuous to frame as a better C because it cannot do everything C does - e.g. unsafe memory access and manual memory management, which are needed in certain systems - and it interoperates poorly with C."
In short, he states that D can do unsafe memory access and manual memory management. Go can't.