3 ms·

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. Y

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.

pjmlp 8y ago
Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. Android team also makes use of Go for their OpenGL/Vulkan debugger. Now, lack of generics is really a big pain point.
- deleted 8y ago
  [deleted]
- kllrnohj 8y ago
  > Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. > Android team also makes use of Go for their OpenGL/Vulkan debugger. Neither of those examples disagree with what I said. Fuschia's usage is the perfect example of agreement - Go specializes in IO (server workloads) and is then being used to do IO. That's a great usage of Go's particular blend of capabilities. The use of GO in GAPID would be more interesting if it had any meaningful constraints on it, but it doesn't. It's an offline debugger for something that ran on a device with a fraction of the speed. RenderDoc would be the meatier Vulkan debugger, and it's C++.
  - pjmlp 8y ago
    GAPID is an online debugger and a TCP/IP stack needs to be really fast. As early C++ adopter I always find ironic how people give examples of C++'s code generation performance. Back in the old days, tying to use C++ would generate exactly the same kind of performance bashing.
naikrovek 8y ago
Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe. When Go 1.8 released, it measured < 1ms garbage collection times on an 18GB heap, and that number has improved in the 2 years and 4 releases since then. I don't believe that "it uses garbage collection" is a valid complaint against Go anymore, except in a real-time application, and I don't know of any real-time applications written in Go. I'm sure there are some, I just don't know of them.
- apta 8y ago
  > Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe. Fastest by what measure? I benchmarked some key value store implementation written in golang and ran into large (> 1 sec) latency spikes because the golang gc couldn't keep up with the large (10GB+) heap space. Java would have allowed me to select a GC algorithm that's best for my use case and I wouldn't have run into that issue. golang's gc is tuned for latency at the expense of throughput, that's basically it. It's not some magic bullet that solved the gc issue, contrary to what the golang marketing team wants people to believe.
- kllrnohj 8y ago
  A fast GC doesn't mean the code wouldn't have been faster without a GC. GC's prevent you from doing a huge range of techniques to improve cache locality or reduce allocation/free churn. A simple example would be games will do things like have just a big allocation for all a frame's temporary data, and they just bump-pointer allocate from it. Then when the frame is over, they reset back to zero. It is already The Perfect GC. Bump pointer allocation, zero pause time, and perfectly consistent memory usage. No matter how good Go's GC gets it will always be slower than that. At the other end of things you have things like LLVM's PointerUnion, where alignment requirements are (abused) to cram a type id into the lower bits of the pointer itself. Type-safe variant in the size of a void*.
  - pjmlp 8y ago
    > GC's prevent you from doing a huge range of techniques to improve cache locality or reduce allocation/free churn. This is only true in languages which don't provide other means of memory allocation. D, Modula-3, Mesa/Cedar, Oberon variants, Eiffel, .NET all provide features for such techniques.

pjmlp 8y ago

Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. Android team also makes use of Go for their OpenGL/Vulkan debugger. Now, lack of generics is really a big pain point.

deleted 8y ago
[deleted]
kllrnohj 8y ago
> Fuchsia team thinks otherwise, where kernel level stuff like the TCP/IP stack and IO volume handling are written in Go. > Android team also makes use of Go for their OpenGL/Vulkan debugger. Neither of those examples disagree with what I said. Fuschia's usage is the perfect example of agreement - Go specializes in IO (server workloads) and is then being used to do IO. That's a great usage of Go's particular blend of capabilities. The use of GO in GAPID would be more interesting if it had any meaningful constraints on it, but it doesn't. It's an offline debugger for something that ran on a device with a fraction of the speed. RenderDoc would be the meatier Vulkan debugger, and it's C++.
- pjmlp 8y ago
  GAPID is an online debugger and a TCP/IP stack needs to be really fast. As early C++ adopter I always find ironic how people give examples of C++'s code generation performance. Back in the old days, tying to use C++ would generate exactly the same kind of performance bashing.

naikrovek 8y ago

Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe. When Go 1.8 released, it measured < 1ms garbage collection times on an 18GB heap, and that number has improved in the 2 years and 4 releases since then. I don't believe that "it uses garbage collection" is a valid complaint against Go anymore, except in a real-time application, and I don't know of any real-time applications written in Go. I'm sure there are some, I just don't know of them.

apta 8y ago
> Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe. Fastest by what measure? I benchmarked some key value store implementation written in golang and ran into large (> 1 sec) latency spikes because the golang gc couldn't keep up with the large (10GB+) heap space. Java would have allowed me to select a GC algorithm that's best for my use case and I wouldn't have run into that issue. golang's gc is tuned for latency at the expense of throughput, that's basically it. It's not some magic bullet that solved the gc issue, contrary to what the golang marketing team wants people to believe.
kllrnohj 8y ago
A fast GC doesn't mean the code wouldn't have been faster without a GC. GC's prevent you from doing a huge range of techniques to improve cache locality or reduce allocation/free churn. A simple example would be games will do things like have just a big allocation for all a frame's temporary data, and they just bump-pointer allocate from it. Then when the frame is over, they reset back to zero. It is already The Perfect GC. Bump pointer allocation, zero pause time, and perfectly consistent memory usage. No matter how good Go's GC gets it will always be slower than that. At the other end of things you have things like LLVM's PointerUnion, where alignment requirements are (abused) to cram a type id into the lower bits of the pointer itself. Type-safe variant in the size of a void*.
- pjmlp 8y ago
  > GC's prevent you from doing a huge range of techniques to improve cache locality or reduce allocation/free churn. This is only true in languages which don't provide other means of memory allocation. D, Modula-3, Mesa/Cedar, Oberon variants, Eiffel, .NET all provide features for such techniques.