11 ms·
> The kernel may be the core of a Linux system, but neither users nor applications deal with the kernel directly. The amount of complexity in a modern libc, gl
by luriel 15y ago
> The kernel may be the core of a Linux system, but neither users nor applications deal with the kernel directly.
The amount of complexity in a modern libc, glibc in particular, is mind-boggling.
One thing I love about Go is that it completely bypasses even libc, the Go runtime and stdlib use syscalls directly(well, except on Windows, for obvious reasons), in a way a Go program is "closer to the metal" than a C program.
- drucken 15y agoUnfortunately, Go with its mandatory GC is about as appropriate for systems programming as Java, regardless of how its marketed...
- burgerbrain 15y agoFor the more traditional definitions of "systems programming", yes. I would agree with that. However I don't think anybody is really marketing Go for that niche.
- wglb 15y agoOriginally they were targeting "systems programming", and, being roughly the contemporary of the most well-known go authors, "systems programming" used to mean compilers, assemblers, and the like. In this meaning, this would also include browsers, although Mozilla is going for Rust. Today, "systems programming" is more taken to mean "kernel programming", and I don't get the sense that is what was meant by the senior authors of go.
- rhizome 15y agoOriginally they were targeting "systems programming" Choose the greatest impediment and cite it as a primary goal.
- wglb 15y agoI am not quite sure if I follow you. Are you saying that "systems programming" is the greatest impediment?
- burgerbrain 15y agoTargeting systems programming is. The existing languages used there are rather firmly entrenched.
- acqq 15y agoI always believed "system programming" meant "programming operating system components or the whole operating system" and Wikipedia seems to agree: http://en.wikipedia.org/wiki/System_programming http://en.wikipedia.org/wiki/System_programming Last time I looked, inside of the Go libraries which had to do some tricky things there was some C code, meaning that even Go authors weren't able to write everything in Go. So Go can't be a substitute for C, and as long as most of the system programming is done in C, no go for Go.
- 4ad 15y agoThat's like saying C is not a system programming language because if you write a kernel you need to write parts of it in assembly, and you need to write parts of libc in assembly as well! Parts of the runtime are written in C and assembly, but that's because there is power in breaking abstractions: http://research.swtch.com/goabstract http://research.swtch.com/goabstract As it stands today, Go can be used to write operating systems. Yes, you will have assembly, yes you will likely also have C, so what?
- wglb 15y agoThat is what "system programming" means these days. It used to exclude operating system kernels, real-time components. I suspect that it isn't so much that they aren't able to write everything in Go, but more that it isn't a priority for now. It wouldn't surprise me if Go wasn't eventually self-hosting.
- delinka 15y agoI'd rather reply to wglb, but he's gone too deep... Anyway, "systems" in this case includes daemons and server processes. I'll update with a reference if I can find it in the Go context.
- burgerbrain 15y ago>"Anyway, "systems" in this case includes daemons and server processes." For that sense of "systems", Go excels and Java enjoys a great deal of popularity.
- reddit_clone 15y agoMe thinks Go's niche is to be an accessible, imperative Erlang. It is already well equipped to write distributed network servers, web servers, message queue servers and such.
- Symmetry 15y agoI don't know. Linus claims he can imagine writing an OS in Go (after they've spent a decade working the bugs out). Which is probably the most positive thing I've heard of him saying about writing kernels in other languages, and I'm inclined to trust his judgement over my own here. EDIT: My memory was almost correct, he said that (in sharp contrast to C++) he can imagine letting Go into the kernel but not for a long time. http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=110624&threadid=110549&roomid=2 http://www.realworldtech.com/beta/forums/index.cfm?action=de... EDIT2: s/Linux/Linus/
- odiroot 15y agoI believe you meant Linus.
- Tobu 15y agoYou're really misrepresenting that thread. Here[1] Linus says C is pretty readable in patch format, because it doesn't do overloading (unlike C++, which was the thread's conversation topic) and thus doesn't much depend on some outside context. Also, C gives the required level of control for kernel programming, in terms of memory model and concurrency (and those conditions implicitly exclude Go), but higher-level languages have something to offer for other problem domains; and in that context GC or concurrency primitives become interesting again. In answer to that last paragraph, someone asked about Go, which is where you got Linus's overall noncommittal answer. [1] http://www.realworldtech.com/beta/forums/index.cfm?action=detail&id=110618&threadid=110549&roomid=2 http://www.realworldtech.com/beta/forums/index.cfm?action=de...
- 4ad 15y agoGo allows the same of control over the memory layout as C, this differentiates it from most other garbage collected languages. Go is a perfectly fine language for kernel mode development, I am aware of at least three efforts of writing an operating system in Go (one such effort being mine). I do agree though that Go is not the right language to use in conjunction with the rest of the Linux kernel. While Go used for a kernel is perfectly fine, it forces you towards some design decisions and constraints that do not exist in the Linux kernel as it stands today.
- tzs 15y agoWhat do you find incompatible between GC and systems programming?
- tedunangst 15y agoI think people generally assume systems programming requires low latency and that using a GC implies high latency. That's mostly, but not strictly, true. If you're writing a web server, as opposed to a missile guidance system, the occasional GC pause is probably not a dealbreaker.
- tzs 15y agoHere's an article from IBM on their work on real-time Java, where they develop a GC that can provide a bound on latency, and on the amount of time spent doing GC: http://www.ibm.com/developerworks/java/library/j-rtj4/ http://www.ibm.com/developerworks/java/library/j-rtj4/ Based on that, I don't think I'd rule out the feasibility of doing a missile guidance system in a GC language.
- 4ad 15y agoI can, and in fact I do write an OS in Go, it's suitable enough for writing a kernel for me.
- derleth 15y ago> use syscalls directly(well, except on Windows, for obvious reasons) Not obvious to me. Please elucidate.
- koenigdavidmj 15y agoEven the Windows API `system calls', like CreateProcess, are just wrappers around NT system calls. There are other wrappers too, like the Subsystem for UNIX Applications (which implements a POSIX API on top of the same NT calls).
- wtracy 15y agoMicrosoft doesn't make the specs for the interface between the Windows kernel and the win32 libraries public.
- yuhong 15y agoNor it is been stable. Win8 for example changes this interface.
- xpaulbettsx 15y agoYou cannot call syscalls directly, as the syscall table is generated dynamically from the kernel source code on NT. The closest thing you can do is call the Nt* class of functions, which are often direct thunks to syscalls.
- sciurus 15y agoWhat makes this advantageous for Go? I imagine it takes a lot of knowledge to optimize a libc for different CPUs and kernels.
- 0xABADC0DA 15y agoIt's not an advantage at all. Google Go uses syscalls directly because its threads ("goroutines") were designed for a 32-bit architecture so their solution to not running out of virtual address space was to use small stacks that can grow. But that means it can't just call normal C function directly because there may not be enough stack, so they have to reinvent libc on every platform they port to. Meanwhile virtually every desktop is 64-bit and even ARMs will soon be 64-bit. Why design a new language around 32-bit computers? Good question.
- nikcub 15y agoI thought there were two implementations, a 32bit and a 64bit
- javert 15y agoInteresting. Is there a place you can point me to, to read up on this issue?
- 0xABADC0DA 15y agoFrom the horse's mouth: http://golang.org/doc/go_faq.html#goroutines http://golang.org/doc/go_faq.html#goroutines When they say "system resources" they mean stack space. It's limited in 32-bit because a stack large enough to be useful takes up too many virtual address space. For instance an 8 MiB stack takes up 1/512 of the 32-bit address space so you can only have max 512 threads, but in 64-bit you can have 33 million (current CPUs limited to 2^48 address space) So they segment the stack in Google Go to get more than some small number of threads. Even though Linux (edit: the kernel) only uses 4k or 8k per thread some OSes have severe limits, so they compound the segmented stack problem (making C interop slow and cumbersome) with userspace threading (M:N). A collection of links why that's a bad idea: http://www.kegel.com/c10k.html#1:1 http://www.kegel.com/c10k.html#1:1 Eventually they'll concede that this wasn't a good idea, but I wouldn't bet on when.
- caf 15y agoThat means that a Go program is exactly as close to the metal as a C program, not closer (the C runtime and stdlib use syscalls directly, too - the C runtime is libc).
- haberman 15y ago> in a way a Go program is "closer to the metal" than a C program. It's amusing how often people try to one-up C with their favorite language, and how these attempts are almost never successful. You can write C that doesn't use libc, that has no access to any system services, or indeed that runs under no operating system at all. For example, an operating system kernel itself. In no way is a Go program "closer to the metal" than a C program.
- luriel 15y agoI was referring to a 'standard' program using the language's corresponding stdlib. And while not as useful this days C's "stdlib" is incredibly thick and complex. Go's stdlib is probably comparable to Plan 9's basic C libraries in complexity, but is portable and provides much more functionality. Also note that Go can do all the things you mention, including writing a kernel. Just to be clear, the real issue with C is not the language so much as the horrible libraries that have been built over decades of clumsily piling up complexity. And the people who suggest glib is the answer to C's library needs are scary and depressing, glib just adds another layer of (very unportable!) crud on top of libc for no real gain other than keeping people from learning how to properly write C (data structures in particular).
- haberman 15y ago> I was referring to a 'standard' program Though you probably didn't mean "standard" literally, writing C programs that have no access to the standard library is explicitly mentioned in the standard, which calls this a "freestanding implementation." > Also note that Go can do all the things you mention, including writing a kernel. You can't write memory management code in a language that provides automatic memory management. You just can't. And while I can believe that people who like Go are experimenting with using Go for most of an OS kernel (with a C kernel underneath it to handle things like memory management and probably interrupts), it's not the same as C where the whole kernel can be in C with the exception of highly hardware-specific code (booting, context switching code, syscall gates, etc). Aside from that, I don't think the performance of GC will ever be acceptable for a high-performance kernel. > Just to be clear, the real issue with C is not the language so much as the horrible libraries that have been built over decades of clumsily piling up complexity. Wait, now C is bad because some people wrote some bad libraries for it? Then don't use those libraries? No one's forcing you to use glib.