6 ms·
.1 of a millisecond is very impressive. Does this mean Go can finally be considered a systems programming language?
by bitmapbrother 10y ago
.1 of a millisecond is very impressive. Does this mean Go can finally be considered a systems programming language?
- aikah 10y ago> .1 of a millisecond is very impressive. Does this mean Go can finally be considered a systems programming language? Can you write an OS kernel in Go ? no Go's runtime still depends on a OS. And whoever talked about Go as a system language didn't have kernels in mind, but "network infrastructure".
- pjmlp 10y agoOf course you can, time to learn about Mesa/Cedar, Modula-2+, Modula-3, Oberon, Sing#, System C# and possibly a few others. Here you can learn how those guys at Swiss Federal Institute of Technology in Zurich did it. http://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://people.inf.ethz.ch/wirth/ProjectOberon/index.html Basically the runtime is done bare metal thus becomes the OS kernel. Oh, and Oberon wasn't just a research OS, it was actually used across the computing department by many of its employees.
- 4ad 10y agoYou can absolutely write a kernel in Go, many year ago Go used to ship with a bare metal runtime, as a demonstration...
- Someone 10y agoGo needs a runtime, but it need not be a full OS; it could be a not too big library that gets linked to a kernel written in go. Similarly, can you write an OS kernel in ISO C? No, you still need some assembly or runtime support. For example, ISO C doesn't have any notion of making syscalls or returning from the kernel to a caller or for setting up page tables. Any argument why go isn't suitable for systems programming along these lines should be about how much and what kind of runtime is acceptable for a systems programming language. A (fairly popular, I think, but certainly not universally agreed upon) argument could be that systems programming languages cannot have garbage collection because it should be possible to implement a garbage collector in them, and doing that in a language that already has one is possible but silly.
- 4ad 10y agoGo's garbage collector is implemented in Go.
- Someone 10y agoI can't find it in the documentation, but I would think that must be implemented in ProtoGo, where ProtoGo is a Go-like language that doesn't use Go's garbage collector or a library that does (Enforcing not using anything that uses the garbage collector may be left to the programmer) That is necessary even with a concurrent garbage collector because a garbage collector that allocates in its own heap may hang itself (propaganda allocates; gc triggered; gc allocates; gc triggered to satisfy the allocation; new gc triggered; etc.) . Or do Go's developers accept this risk and live with it?
- 4ad 10y ago> Enforcing not using anything that uses the garbage collector may be left to the programmer It's left to the compiler actually. Programmers can't be trusted. The runtime does not implicitly generate garbage (like arbitrary Go code). It is compiled with a mode that fails compilation if something can't be stack-allocated. When heap allocation is necessary, it is requested manually. However, the memory returned is garbage collected, as usual, there is no free.
- pjmlp 10y agoBesides 4ad reply, here you can see how Oberon has its GC implemented in Oberon, as another example of a bootstrapped GC enabled systems programming language. http://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel.Mod.txt http://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Kernel...
- johncolanduoni 10y agoMost other sophisticated GCs (e.g. .NET and Java's) can obtain pause times in a similar range for generation 0 collections. So if GC is the reason you don't want to use one of those you'd probably be more interested in improvements in worst case pause times. Go is however very good at avoiding unnecessary object allocation and doesn't need a JIT so it may still be closer to what you need than those languages.
- pcwalton 10y agoRight, and tenured generation collections are already concurrent in HotSpot and .NET. Generally only heap compaction needs to stop the world; you can disable compaction if this is a problem for you.
- deleted 10y ago[deleted]
- DSMan195276 10y agoPersonally, I would say latency isn't the problem, and that not being able to avoid the gc makes Go automatically not a systems programming language. Not all situations can afford a gc, and really for a lot of systems programming usage (Particularly embedded systems) using a gc just obscures memory usage when you in a lot of cases the memory can be declared statically to begin with (Ensuring a maximum amount of memory usage). That's not to say you couldn't potentially write an OS or an embedded system in Go (I mean, you can write OS's in Lisp if you really want) but I doubt it would be fun and I doubt anybody would recommend it. You definitely won't be writing idiomatic Go without a lot of extra pieces that you can't really afford in those situations.
- pjmlp 10y agoUsing Oberon, Java and .NET is surely more fun than plain C and there are a few embedded companies selling such stacks for their boards.
- deleted 10y ago[deleted]
- the8472 10y agoThe lack of control over threading makes it problematic as systems programming language.
- bishop_mandible 10y agoSince the term is not defined anything can be considered a systems programming language.
- _ak 10y agoThe Go developers provided their definition, which is something people conveniently ignore whenever they try to be clever about Go not being a systems programming language.
- jjnoakes 10y agoTo be fair, if I repurpose a term that is widely used in one way to mean something else, the confusion that ensues is kind of my fault.
- geodel 10y agoSo many places I worked had systems engineering department and none of them had anything to do with operating systems/ device drivers. I wonder whether it has to do with OS hackers hanging on internet together and deciding what systems would mean.
- _ak 10y agoThere was no repurposing, as the context was exactly explained. Only later, the detractors decontextualized the Go team's original statements.
- pjmlp 10y agoGo can become a systems programming language, even if the GC haters don't think so. It has the same features as Oberon for systems, programming which was used to build quite a few Workstation OS at Swiss Federal Institute of Technology in Zurich (ETHZ), by Niklaus Wirth. https://en.wikipedia.org/wiki/Oberon_(operating_system) https://en.wikipedia.org/wiki/Oberon_(operating_system) You can read the source code here in the 2013 revised edition of the 1992 book. http://people.inf.ethz.ch/wirth/ProjectOberon/index.html http://people.inf.ethz.ch/wirth/ProjectOberon/index.html The only thing missing from Go versus what Oberon offered is register access on the unsafe package, but even then can be sorted out with an extension or a few calls into Assembly. Oberon-07, which is even more minimalist that either Go or the original Oberon is sold by Astrobe for bare metal programming on cortex M boards. http://www.astrobe.com/default.htm http://www.astrobe.com/default.htm Go is already bootstraped into itself, so the writing compilers is taken care of. It is used by Docker and Kubernetes for managing containers. It just needs someone writing an OS with Go for its Master or PhD thesis, or even just port Oberon source code, which is freely available into Go. http://wiki.osdev.org/Go_Bare_Bones http://wiki.osdev.org/Go_Bare_Bones
- _ak 10y agoWhat the Go developers consider a "systems programming language" was exactly explained in the very first announcement/presentation of Go. They clearly outlined that it's for building systems like Google's, not operating systems.