5 ms·
You cannot really write an operating system without manual memory management. That's why Go is not a systems programming language. It does not diminish Go advan
by cft 9y ago
You cannot really write an operating system without manual memory management. That's why Go is not a systems programming language. It does not diminish Go advantages: I would personally prefer it as an application programming language to Java.
- pjmlp 9y agoCompletely false, there are several research OSes with kernel level GC. I suggest reading Project Oberon source code, it’s freely available.
- BuckRogers 9y agoI can't speak for the parent but he did say "cannot really". I would assume due to that he's aware you can write a research project in it. At one point, I thought Windows was to move to .Net even and MS backed out in the end. Back to Go, for anyone else reading this thread and wondering what Rob Pike thinks it is, evidence of them removing "systems programming" off their website is here. He explicitly states that he regrets it and that Go is not an OS writing language[0]. Andrei Alexandrescu offers a litmus test shortly after with a property of a systems programming language that Go also fails. If the creator of a language says it's not a systems programming language, I'm not sure how it can be argued by outsiders that it is. If there's more damning evidence that Go is not a systems programming language, I couldn't imagine what that would be. A shortlist of systems programming languages that would pass any litmus test would include C, C++, D and Rust. [0]https://www.youtube.com/watch?v=BBbv1ej0fFo&feature=youtu.be&t=6m44s https://www.youtube.com/watch?v=BBbv1ej0fFo&feature=youtu.be...
- pjmlp 9y ago> I thought Windows was to move to .Net even and MS backed out in the end. If you bother to read Joe Duffy's postmortems, and talks he has made about Midori, you will get it had nothing to do with technical issues, rather internal political wars at Microsoft. Also Microsoft did not fully backed out, the outcome of Singularity became the MDIL compiler for .NET on Windows 8.x. Midori influenced async/await, TPL, .NET Native used in UWP and the new low level language features on C# 7.x. > If the creator of a language says it's not a systems programming language, I'm not sure how it can be argued by outsiders that it is. I don't have Go in much high regard, but it certainly can be used for systems programming, and is being used as such today, regardless of what the anti-GC systems language crowd thinks. "G.E.R.T : Golang Embedded Run-Time" https://github.com/ycoroneos/G.E.R.T https://github.com/ycoroneos/G.E.R.T "Fuchsia TCP/IP stack", all network requests go through it. https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1PgTXAwAJ https://groups.google.com/d/msg/golang-dev/2xuYHcP0Fdc/tKb1P... https://fuchsia.googlesource.com/netstack/ https://fuchsia.googlesource.com/netstack/ "Fuchsia disk management utilities for file systems" https://fuchsia.googlesource.com/thinfs/ https://fuchsia.googlesource.com/thinfs/
- BuckRogers 9y agoIn that case it sounds like you have a bone to pick with Rob Pike over Go. I suppose you can find him on Twitter if you want to settle your feud. I'd suggest to not bother when I have him on tape contradicting you. I did read Joe's blog, years ago. Your takeaway there also leaves you with a bone to pick with Microsoft, if it's just politics then you should be able to find someone in management at Microsoft to set straight. It'd be a real shame if there were no performance issues and it was shutdown due to politics alone.
- pjmlp 9y agoIt doesn't matter what Rob Pike says regarding Go and systems programming, because Google, the company that employs him, has decided Go makes sense to write system components of Fucshia in Go. That is a fact, easily validated in Fuchsia's repository. According to you, Rob Pike should call management and let them know it is not a good idea to use Go for writing Fuchsia's TCP/IP stack. You only read Joe's blog years ago, yet you missed the talks he gave. Two years ago is not that long time ago, http://joeduffyblog.com/2015/11/03/blogging-about-midori/ http://joeduffyblog.com/2015/11/03/blogging-about-midori/ "My biggest regret is that we didn’t OSS it from the start, where the meritocracy of the Internet could judge its pieces appropriately. As with all big corporations, decisions around the destiny of Midori’s core technology weren’t entirely technology-driven, and sadly, not even entirely business-driven. But therein lies some important lessons too." http://joeduffyblog.com/2015/12/19/safe-native-code/ http://joeduffyblog.com/2015/12/19/safe-native-code/ "Over the course of 8 years, we were able to significantly narrow the gap between our version of C# and classical C/C++ systems, to the point where basic code quality, in both size of speed dimensions, was seldom the deciding factor when comparing Midori’s performance to existing workloads. In fact, something counter-intuitive happened. The ability to co-design the language, runtime, frameworks, operating system, and the compiler – making tradeoffs in one area to gain advantages in other areas – gave the compiler far more symbolic information than it ever had before about the program’s semantics and, so, I dare say, was able to exceed C and C++ performance in a non-trivial number of situations." "Safe Systems Programming in C# and .NET" https://www.infoq.com/presentations/csharp-systems-programming https://www.infoq.com/presentations/csharp-systems-programmi... "RustConf 2017 - Closing Keynote: Safe Systems Software and the Future of Computing" https://www.youtube.com/watch?v=CuD7SCqHB7k https://www.youtube.com/watch?v=CuD7SCqHB7k Around minute 30 he starts describing the uphill battle to convince other Microsoft teams to accept Midori achievements.