4 ms·

And yet it works, it's fast, it's reliable. I've tried to build clang and it aint pretty. Something something shipped is better than perfect. IMHO I'm quite g

• randomdata 7y ago
  Besides, one of Go's explicit goals was to not be bound to any one implementation. The language has been carefully documented to ensure that anyone could reimplement it without having to understand nuances of a specific toolchain. If you want to compile Go using LLVM, everything you need is there to make it happen. In fact, someone has already done a lot of the leg work for you[1]. And if GCC is more your thing[2]... [1] https://tinygo.org https://tinygo.org [2] https://golang.org/doc/install/gccgo https://golang.org/doc/install/gccgo
  • millstone 7y ago
    I think this is too facile. Go was conceived as suitable for systems programming tasks, like web browsers, databases, and operating systems. But Google's own web browsers, databases, and OSes do not use Go. It was also conceived as suitable for web servers, crawlers, and indexers; there it has been successful inside and outside Google. Why didn't it catch on for browsers, databases, OSes - while Rust did? I think it must be the GC primarily, but the lack of an advanced optimizing compiler is part of the story.
    • randomdata 7y ago
      I'm not sure where the idea Go hasn't caught on for databases comes from. * https://awesome-go.com/#database https://awesome-go.com/#database * https://github.com/rust-unofficial/awesome-rust#database https://github.com/rust-unofficial/awesome-rust#database Rust was invented specifically to write a web browser, so that is a bit of an unfair comparison, but I would suggest that Go's lack of seamless inter-op with C is its biggest limiting factor in integrating into existing browser codebases as well as greenfield GUI applications. Additionally, Go's runtime is not well suited to OS development. I doubt the lack of an advanced optimizing compiler ever crosses anyone's mind as by the time that might become an issue they have already ruled out Go for its many other limitations.
• arcticbull 7y ago
  They would have shipped Go years sooner if they didn't waste their time re-building all the basic plumbing of a compiler suite. To leverage LLVM would have been to implement a basic front-end just like LLGo did. They'd have received instant access to an optimizing mid-end, optimizing back-ends and all the architectures that LLVM supports today and will ever support in the future. Any optimizations they'd made to LLVM would have made all LLVM clients better off. Instead, they chose to buff up 9c. Is LLVM bigger? Yep. Slower? Probably. Is that because it's some wildly inefficient monstrosity? Nope. It does a lot more, with a lot more flexibly, and it does it a lot better than the Go toolchain. One day when Pike & Co get around to implementing all the optimization that LLVM has, it'll be just as big, and just as slow, mark my words.
  • tedunangst 7y ago
    Perhaps Pike & Co will stop short of implementing every optimization that LLVM has.
    • arcticbull 7y ago
      Why? Your users are the ones with the weak computers, developers usually have the beefiest machines. Why optimize for the developer, who'll build it a few hundred times, as compared to the end-user who will run it continuously for days/weeks/months/years on end? Just disable the expensive passes in a debug build, like "cargo check", "cargo build" and "cargo build --release".
      • eatonphil 7y ago
        Performance of Google software on Google servers doesn't seem like as serious an issue.