Comment by atombender | Hacker News Reader

Comment by atombender | Hacker News Reader

Parent Full thread

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.

Personally 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.

This 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.

Forgive 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?

Perhaps, but the advantages of a large third-party ecosystem around LLVM outweighed any performance differences between GCC and LLVM.

At 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-clan...

Of course, benchmarks, yada yada, but at least is some sort of comparison axis where the improvement over the years is clear.

Thanks for the link. I was probably thinking about some older phoronix benchmarks when I made my post

Thanks 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.

I 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.

Slow 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.

Isn't Cranelift going to be usable for that?

If 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.

What are you talking about? Plan 9 doesn't even use $path. At least not consistently -- binaries live in /bin.

It'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.

Go 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.

The 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.

I don't think Linux actually guarantees syscall-level compatibility, so no need to single it out, it's just like everyone else.

It 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.

It very much does, explicitly, in a way that every other operating system does not.

It'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.

You are extremely wrong, so it's probably worth thinking for a moment about how you became so misinformed and why you feel so strongly that you're not misinformed.

https://www.kernel.org/doc/Documentation/ABI/README

  Most interfaces (like syscalls) are expected to never change and always be available.

https://www.kernel.org/doc/Documentation/ABI/stable/syscalls

  This interface matches much of the POSIX interface and is based
  on it and other Unix based interfaces.  It will only be added to
  over time, and not have things removed from it.

This is literally an explicit promise of the Linux kernel; distros have no influence over the Linux syscall ABI whatsoever.

I think you're perhaps extremely confused about the difference between the userspace syscall -> kernel interface, and kernelspace API/ABI such as out-of-tree kernel modules might use. About the latter, yes, there are no API/ABI guarantees in vanilla Linux.

Expecting something is not a promise, just an attitude they want to have towards it at the moment. I think you are also confusing who is even in a position to promise what. Kernel is not an OS people can use, but only something an OS (distro) itself can use and, given the license, in any way it wants. And so kernel cannot promise or force ABI compatibility or anything really on behalf of any OS that uses it. It's up to the OS, but OSes modify kernels, backport things, build with various ABIs and so on. Look for example at the mess around x32 ABI, some distros had it, some didn't, some had it and dropped it, some had and promised ABI compatibility for some time, but Linus wants to drop it from the kernel (don't know if he actually did it), so they are in a pickle. Read RedHat's application compatibility guide if you want an example on what the best a linux distro can promise wrt ABI compatibility.

> platforms without a stable syscall ABI and a very strong push for dynamic linking (…so macOS)

That's an even better description of Windows. The macOS system call table isn't officially stable, but it's at least slow to change. The Windows equivalent has been known to change from service pack to service pack.

Plan9/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.

Reply on news.ycombinator.com