5 ms·
A lot of the insularity and weirdness comes from the Plan 9 heritage. Go's authors (Rob Pike, Ken Thompson, and Russ Cox) cannibalized/ported a bunch of their o
by atombender 7y ago
A lot of the insularity and weirdness comes from the Plan 9 heritage. Go's authors (Rob Pike, Ken Thompson, and Russ Cox) cannibalized/ported a bunch of their own Plan 9 stuff during initial development. For example, I believe the original compiler was basically a rewrite of the Inferno C compiler.
This is a large part of why Go is not based on GCC or LLVM, why it has its own linker, its own assembly language, its own syscall interface, its own debug format, its own runtime (forgoing libc), and so on. Clearly Go's designers were more than a little contrarian in their way of doing things, but that's not the whole answer.
Being able to repurpose existing code is an efficiency multiplier during the bootstrapping phase. But when bootstrapping is done, you have to consider the ROI of going back and redoing some things or keep a design that works pretty well. The Go team is undoubtedly aware of some of these issues, but probably don't consider them to be a priority.
In some cases the tools are a benefit. Go's compiler and linker are extremely fast, which I appreciate as a developer. A possible compromise would be to offer a slower build pipeline for production builds, which made use of LLVM and its many man-years of code optimizations.
- eikenberry 7y agoPersonally I more wish Rust would take this approach. Rust desperately needs a fast, developer oriented compiler. The slow compile times is potentially Rusts biggest flaw, to the point where I find it keeps me off the language for anything non-trivial. Even better might be a Rust interpreter, so you'd get REPL and fast development cycles.
- mixedCase 7y agoIsn't Cranelift going to be usable for that?
- pcwalton 7y agoThis is why Cranelift is being worked on. There is also a Rust interpreter, miri. I think starting with LLVM was the right decision (and one that was I was primarily responsible for). Rust would lose most of its benefits if it didn't produce code with performance on par with C++. LLVM is not the fastest compiler in the world (though it's not like it's horribly slow either), but its optimization pipeline is unmatched. I don't see replicating LLVM's code quality as feasible without a large team and a decade of work. Middling code gen performance is an acceptable price to pay until we get Cranelift; the alternative, developing our own backend, would mean not being able to deploy Rust code at all in many scenarios.
- eikenberry 7y agoThanks for the pointer! I was unfamiliar with Cranelift and it seems like a promising tech. I'll keep an eye on it in hopes that once it is stable I'll be able to put together a development environment that allows for the fast turnaround I prefer.
- voldacar 7y agoForgive me if this is ignorant, since I havent done any benchmarks on this in a while, but doesnt GCC produce slightly faster code on average across a wide set of benchmarks compared to clang/LLVM?
- pcwalton 7y agoPerhaps, but the advantages of a large third-party ecosystem around LLVM outweighed any performance differences between GCC and LLVM.
- oscargrouch 7y agoAt least in these benchmarks that phoronix run time-to-time, (so they at least can be compared to their older self) LLVM, in its Clang incarnation, is finally getting some parity in execution times with GCC https://www.phoronix.com/scan.php?page=article&item=gcc-clang-3960x&num=7 https://www.phoronix.com/scan.php?page=article&item=gcc-clan... Of course, benchmarks, yada yada, but at least is some sort of comparison axis where the improvement over the years is clear.
- voldacar 7y agoThanks for the link. I was probably thinking about some older phoronix benchmarks when I made my post
- MarkSweep 7y agoI have not used rust for anything very large, but the using an editor that supports the rust language server mitigates the compile time problem. In VSCode it show you the compiler warnings and errors as you are editing a file. There is a little lag in updating but the workflow is faster than switching to a terminal to do a full compile.
- ComputerGuru 7y agoSlow compile is a developer problem. Big binaries is a problem for both developers and users. Typically, developers can afford to throw more cores and more ram at their build machines.
- saagarjha 7y agoGo has had to walk back on some of its choices recently; most notably on platforms without a stable syscall ABI and a very strong push for dynamic linking (…so macOS) they link against the system libraries.
- naniwaduni 7y agoThe only popular platform with a stable syscall ABI is Linux. This is a product of the historical accident that Linux doesn't control a libc and ensuing drama. Almost everyone else doesn't have a stable ABI below the (C) linker level.
- zzzcpan 7y agoI don't think Linux actually guarantees syscall-level compatibility, so no need to single it out, it's just like everyone else.
- nneonneo 7y agoIt does - the syscalls are part of the official userspace interface which the Linux kernel promises not to break. They can add new syscalls, options or flags, but can’t break existing ones.
- loeg 7y agoIt very much does, explicitly, in a way that every other operating system does not.
- zzzcpan 7y agoIt's still not an explicit guarantee. Actually, Linux the kernel doesn't guarantee or promise anything, it's only distros that try, and those that do promise some compatibility, don't promise all that much. The best promise you can find is like a promise of ABI compatibility within a couple of future releases.
- 7y ago
- ljm 7y agoIf you need any other evidence for this, just look at GOPATH and similar. That was plan9 through and through; they wanted to delegate work to the filesystem. No need for a package manager or anything, just pull down URIs and they'll be where Go wants them to be.
- ori_b 7y agoWhat are you talking about? Plan 9 doesn't even use $path. At least not consistently -- binaries live in /bin.
- p_l 7y agoIt's derived from convention of /n/sources and /n/contrib and the like. Sources mounted from network fileservers from various places, etc. The git support was added to make it a bit easier outside plan9.
- anthk 7y agoPlan9/9front uses u.h and libc.h, among nc and nl as the compiler and linkers, being n the architecture. That allowed free cross-compiling, as plan9/9front does since your base install and now, OFC, Go.