5 ms·

That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use

That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. 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.

steveklabnik 8y ago
> Rust has unsafe all over the place This does not match my experience nor numbers I’ve seen. What leads you to say this? (Also, other than LLVM, Rust is written in Rust. And when cranelift lands, you could remove that too.)
- deleted 8y ago
  [deleted]
kllrnohj 8y ago
> 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.
pcwalton 8y ago
> Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Yes, it is, because the language has the concept of safe code to begin with. The problem with C++ is that all C++ code could potentially be unsafe. > 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. This is a very confused comment. Rust is also written in Rust. If you're thinking of LLVM, sure, the Rust compiler uses that, but LLVM is nowhere to be found in products written in Rust that are shipped to users. What matters is how safe the runtime is, and there's no real difference between Go and Rust in this regard. Go might theoretically have some kind of edge over Rust in safety in that it calls syscalls directly instead of going through libc, but I highly doubt it matters in practice, because (a) the libc wrappers are a drop in the bucket compared to the complexity of the kernel; (b) Go only does that on Linux these days anyhow.
- naikrovek 8y ago
  I thought Rust was written in C++, apologies.
- piano 8y ago
  Yup, and besides, Go has the unsafe (https://golang.org/pkg/unsafe/ https://golang.org/pkg/unsafe/) package, which allows for basically the same sort of unsafety as Rust's unsafe. In fact, I would say Rust is typically more safe than Go, because in Rust you can mark any code as unsafe, it doesn't necessarily have to involve unsafe pointers. For example in Rust FFI functions are typically marked unsafe even if they don't involve pointers. There's no way to do that in Go. Another example is strings: Rust ensures that strings are always valid UTF-8 by marking any function that could break that as unsafe. OTOH in Go you strings can contain invalid UTF-8 if I recall correctly.
karavelov 8y ago
Apart from memory safety issues, there are type safety issues that can cause equal security harm. Go's approach of casting interface{} back and forth is as dangerous as allowing malloc/free. The worst part is that the language designers don't see this as a problem.
- platinumrad 8y ago
  interface{} is not great but it is not void *. Type assertions (casts) on interface{} are typechecked at runtime and failed type assertions on interface{} cannot violate memory safety.
  - pcwalton 8y ago
    Interface in Go can actually violate memory safety because of object slicing when racing on a variable concurrently from multiple goroutines (unless things have changed lately). It's two words (data and vtable) and so there is a tiny window in which one goroutine could change the data pointer while another goroutine is reading the two words, and so have a type mismatch that could probably cause arbitrary code execution in theory. I've never heard of this happening in practice, however.
    - platinumrad 8y ago
      Unless I'm misunderstanding you, you're just talking about a garden variety data race on any interface value in shared memory right? If that's the case, I don't see what it has to do with interface{} in particular (or interfaces at all) as any multiword value in shared memory is susceptible to this, which is the unfortunate price you pay when your language supports shared memory concurrency but doesn't have any allowances for it in its type system. Of course, data races are usually race conditions too, meaning that even if the memory corruption were prevented, there would probably still be a correctness bug to worry about, so I can understand why the Go authors chose the tradeoffs that they did. Edit: Reread your comment and I get the part that is specific to interfaces now. This seems harder to exploit than, for example, a read of a slice header being... sliced... resulting in an out of bounds access.
roca 8y ago
My project currently has 104366 lines of Rust code and 174 uses of 'unsafe' (many of which are somewhat spurious, like usage of `mmap` and other system calls that don't have safe wrappers in external crates). My project does a lot of low-level stuff (e.g. ptracing, sharing memory with C++ code in other processes) and has lots of crazy low-level optimizations but still only has one use of 'unsafe' per 600 lines of code. I haven't made any particular effort to reduce usage of 'unsafe' either. > it's no more safe if you use that keyword to do the same things that are done in C++ Sure, but using 'unsafe' everywhere that you would write unsafe C++ code simply isn't idiomatic Rust and except for very specific and limited situations, Rust developers don't do that.
IX-103 8y ago
Sorry. Until Go gets its head out of its ass and gets proper generics Go will still be painful to use and slow. Not to mention with all the extra code complexity from writing everything with interface{}{} and reflection there are bound to be plenty of exploitable vulnerabilities. I honestly think it is worse than pre-generic Java because switching over the type of the variable is encouraged. Most sane type-checked languages kinda expect you to know what type you're working with at compile time.
- naikrovek 8y ago
  Generics are slower, that's the trade-off. Developer time vs. execution time. Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.
  - fredmorcos 8y ago
    > Generics are slower, that's the trade-off. Developer time vs. execution time. You have no idea what you're talking about. > Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that. No it's not disrespectful, it is entirely true. Do consider the origins of Go, where it all started as an experiment in combining bad decisions into a single programming language to see what would happen. What those very people didn't realize upon releasing it to the world is the sheer amount of people who fell for it, it was supposed to be a joke, with a stupid looking mascot and all... Now they have to take it seriously - and Google has to choose between keeping it alive or getting a forever bad rep for killing it - because too many companies rely on it, and they are forced to retrofit useful features on top of the giant pile of garbage they've created.
    - johntyree 8y ago
      I don't know about the origin story, although frankly I hope it's true. Personally, I think Go is terrible. However, I can't imagine Google is even remotely considering scrapping Go. It is massively popular. It is used all over the place both externally and internally. It's a huge branding asset, community outreach tool, recruiting tool and provides leverage in the form of first party libraries over the direction that software development as a whole is going.

steveklabnik 8y ago

> Rust has unsafe all over the place This does not match my experience nor numbers I’ve seen. What leads you to say this? (Also, other than LLVM, Rust is written in Rust. And when cranelift lands, you could remove that too.)

deleted 8y ago
[deleted]

kllrnohj 8y ago

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

pcwalton 8y ago

> Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Yes, it is, because the language has the concept of safe code to begin with. The problem with C++ is that all C++ code could potentially be unsafe. > 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. This is a very confused comment. Rust is also written in Rust. If you're thinking of LLVM, sure, the Rust compiler uses that, but LLVM is nowhere to be found in products written in Rust that are shipped to users. What matters is how safe the runtime is, and there's no real difference between Go and Rust in this regard. Go might theoretically have some kind of edge over Rust in safety in that it calls syscalls directly instead of going through libc, but I highly doubt it matters in practice, because (a) the libc wrappers are a drop in the bucket compared to the complexity of the kernel; (b) Go only does that on Linux these days anyhow.

naikrovek 8y ago
I thought Rust was written in C++, apologies.
piano 8y ago
Yup, and besides, Go has the unsafe (https://golang.org/pkg/unsafe/ https://golang.org/pkg/unsafe/) package, which allows for basically the same sort of unsafety as Rust's unsafe. In fact, I would say Rust is typically more safe than Go, because in Rust you can mark any code as unsafe, it doesn't necessarily have to involve unsafe pointers. For example in Rust FFI functions are typically marked unsafe even if they don't involve pointers. There's no way to do that in Go. Another example is strings: Rust ensures that strings are always valid UTF-8 by marking any function that could break that as unsafe. OTOH in Go you strings can contain invalid UTF-8 if I recall correctly.

karavelov 8y ago

Apart from memory safety issues, there are type safety issues that can cause equal security harm. Go's approach of casting interface{} back and forth is as dangerous as allowing malloc/free. The worst part is that the language designers don't see this as a problem.

platinumrad 8y ago
interface{} is not great but it is not void *. Type assertions (casts) on interface{} are typechecked at runtime and failed type assertions on interface{} cannot violate memory safety.
- pcwalton 8y ago
  Interface in Go can actually violate memory safety because of object slicing when racing on a variable concurrently from multiple goroutines (unless things have changed lately). It's two words (data and vtable) and so there is a tiny window in which one goroutine could change the data pointer while another goroutine is reading the two words, and so have a type mismatch that could probably cause arbitrary code execution in theory. I've never heard of this happening in practice, however.
  - platinumrad 8y ago
    Unless I'm misunderstanding you, you're just talking about a garden variety data race on any interface value in shared memory right? If that's the case, I don't see what it has to do with interface{} in particular (or interfaces at all) as any multiword value in shared memory is susceptible to this, which is the unfortunate price you pay when your language supports shared memory concurrency but doesn't have any allowances for it in its type system. Of course, data races are usually race conditions too, meaning that even if the memory corruption were prevented, there would probably still be a correctness bug to worry about, so I can understand why the Go authors chose the tradeoffs that they did. Edit: Reread your comment and I get the part that is specific to interfaces now. This seems harder to exploit than, for example, a read of a slice header being... sliced... resulting in an out of bounds access.

roca 8y ago

My project currently has 104366 lines of Rust code and 174 uses of 'unsafe' (many of which are somewhat spurious, like usage of `mmap` and other system calls that don't have safe wrappers in external crates). My project does a lot of low-level stuff (e.g. ptracing, sharing memory with C++ code in other processes) and has lots of crazy low-level optimizations but still only has one use of 'unsafe' per 600 lines of code. I haven't made any particular effort to reduce usage of 'unsafe' either. > it's no more safe if you use that keyword to do the same things that are done in C++ Sure, but using 'unsafe' everywhere that you would write unsafe C++ code simply isn't idiomatic Rust and except for very specific and limited situations, Rust developers don't do that.

IX-103 8y ago

Sorry. Until Go gets its head out of its ass and gets proper generics Go will still be painful to use and slow. Not to mention with all the extra code complexity from writing everything with interface{}{} and reflection there are bound to be plenty of exploitable vulnerabilities. I honestly think it is worse than pre-generic Java because switching over the type of the variable is encouraged. Most sane type-checked languages kinda expect you to know what type you're working with at compile time.

naikrovek 8y ago
Generics are slower, that's the trade-off. Developer time vs. execution time. Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that.
- fredmorcos 8y ago
  > Generics are slower, that's the trade-off. Developer time vs. execution time. You have no idea what you're talking about. > Saying Go has it's head up it's ass is extremely disrespectful to the people that created it and are maintaining it. You lost all credibility when you chose the low road and said that. No it's not disrespectful, it is entirely true. Do consider the origins of Go, where it all started as an experiment in combining bad decisions into a single programming language to see what would happen. What those very people didn't realize upon releasing it to the world is the sheer amount of people who fell for it, it was supposed to be a joke, with a stupid looking mascot and all... Now they have to take it seriously - and Google has to choose between keeping it alive or getting a forever bad rep for killing it - because too many companies rely on it, and they are forced to retrofit useful features on top of the giant pile of garbage they've created.
  - johntyree 8y ago
    I don't know about the origin story, although frankly I hope it's true. Personally, I think Go is terrible. However, I can't imagine Google is even remotely considering scrapping Go. It is massively popular. It is used all over the place both externally and internally. It's a huge branding asset, community outreach tool, recruiting tool and provides leverage in the form of first party libraries over the direction that software development as a whole is going.