6 ms·

I'm personally not a big fan of Go due to the weak type system, with lack of generics as the main offender. And as a result, the ubiquitous `interface{}` patte

I'm personally not a big fan of Go due to the weak type system, with lack of generics as the main offender. And as a result, the ubiquitous `interface{}` pattern, stringly typed annotations, ... BUT Go offers simplicity, incredibly easy concurrency, decent performance, a good standard library for networking/http services, very quick compile times and a stricter type system than many other languages like Python/PHP. For many teams, especially coming from more dynamic languages, Go fills a sweet spot of performance, concurrency, type safety and ease of use. I love Rust, but it is much more complex, boilerplate heavy, adds more friction, is harder to learn, and concurrency is much harder to get right, even with the upcoming async/await feature. Not to mention the immature ecosystem, that will still need years of catching up to achieve parity with Go. Kotlin is also a great language, but has it's own downsides. You need to learn and understand Java (due to the many Java dependencies that you will pull in), there often will be a mismatch between Java libraries and idiomatic Kotlin code, concurrency is harder than in Go, and the JVM is a much more complex beast then the minimally tunable Go runtime. Go definitely has a place, even though it often wouldn't be my own first choice.

kpcyrd 7y ago
async/await is async io, this is something js is known for since it doesn't actually require parallelism. Getting concurrency _with_ parallelism right is a lot easier in rust than it is in go. You need to write thread safe code in both of them, but you get zero support from your compiler in go.
- foldr 7y ago
  Go provides channels for safe communication between goroutines (which are distributed across multiple threads).
  - twic 7y ago
    You can use channels to pass mutable objects, which are then shared between threads. The passing itself may be safe, but the resulting situation isn't. The Rust compiler won't let you do that.
    - foldr 7y ago
      You can mutate objects from multiple threads in Go without using channels.
      - twic 7y ago
        The Rust compiler won't let you do that either!
        foldr 7y ago
        I know. I just didn't see why you were bringing channels into it. It's not as if it's some loophole involving channels that's the issue here.
- the_duke 7y ago
  Rust prevents data races with the `Send` and `Sync` markers, but that's a long way from making concurrency and parallelism easy. In Go, as long as you are not sharing data, you don't really have to care about whether something is concurrent or parallel, the runtime takes care of it for you. You just use goroutines, IO transparently happens on a dedicated threadpool, CPU heavy tasks are spread out over the available cores. As long as you restrict sharing to sending owned data over channels, you are mostly in the clear. Of course sometimes performance concerns etc mandate more traditional tools (atomics, mutexes, etc) and there the compiler won't help you anymore, but I'd argue that is the exception in Go rather than the norm. You can often solve problems with a actor-system inspired design. (learning Erlang/Elixir will probably make you a better Go developer!) In Rust, you still have to care a lot about what you do. Things like tokio::fs can handle file system IO for you, but you need to ensure that code you are calling does no synchronous IO. Also, CPU heavy workloads should be offloaded to a dedicated CPU thread pool, since the tokio runtime is not intended for juggling CPU intensive tasks in addition to the async IO. This is fine for Rust, a language that wants to give you insight and control, but it is still much more demanding of the developer.
  - pcwalton 7y ago
    > You just use goroutines, IO transparently happens on a dedicated threadpool, CPU heavy tasks are spread out over the available cores. In Rust you can do that too! Just use threads. That's what Go does: it just uses threads. Async I/O is there if you need better performance than what Rust—or Go—can provide. If you don't need that performance, then don't use async I/O.
    - foldr 7y ago
      Go uses async IO under the hood (for network IO at least). The exposed API is blocking, but the underlying implementation uses async IO and transparently schedules Goroutines across different OS threads. As you know, Rust doesn't currently have stable support for a similarly high-level interface to async IO. See e.g. the following reddit thread from 3 months ago: https://www.reddit.com/r/rust/comments/ausuld/what_is_the_current_state_of_async_io_in_rust/ https://www.reddit.com/r/rust/comments/ausuld/what_is_the_cu...
0815test 7y ago
People who think Rust is "complex" and "boilerplate-heavy" have never had to deal with C++, or heck, even Java. (Though I'd guess we would actually find plenty of C++/Java code within Google itself.) The only reason one could fairly give for that sort of statement is that Rust - the language itself, not just the ecosystem! - is still quite far from mature. But it's going to have a great future once some of the "tweaks" that are in the pipeline right now reach stability. Async is one of those of course, but there are more. Edit: And to be clear, I'm not a Go-hater! In fact, Go comes out-of-the-box with a very nice, high-performance concurrent GC that makes it highly appropriate for some scenarios where Rust would not be a good fit at all.
enneff 7y ago
> the ubiquitous `interface{}` pattern I’m totally biased because I’ve worked on and with go for a decade, including reviewing all sorts of Go we write at Google, but I just don’t get this criticism. It’s just not something I see in the code bases I work on. I admit that I may be working on different kinds of programs to what some others do, and I don’t want to deny anyone their legitimate experiences, but my personal experience has been that this is rarely a thing, if ever.
- the_duke 7y ago
  It can be found in many libraries in the ecosystem, and is common enough in the standard library. The lack of generics just severely restricts the expressiveness of the type system. I think the best way to work around this is use of code generation, which is a great tool for internal, controlled environments, but very cumbersome for open source libraries.
  - enneff 7y ago
    I don’t see much, if any, generated Go code at Google. Not to say that it doesn’t happen but it’s not on my radar.
    - zigara 7y ago
      Here is an example: https://github.com/google/gvisor https://github.com/google/gvisor - https://github.com/google/gvisor/tree/master/tools/go_generics https://github.com/google/gvisor/tree/master/tools/go_generi... It was useful enough that someone made a standalone package: https://github.com/mmatczuk/go_generics https://github.com/mmatczuk/go_generics
    - pjmlp 7y ago
      Kubernetes makes heavy use of generated code, as workaround for lack of generics. They even gave a FOSDEM talk about this, with a very interesting title. https://fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...
    - 7y ago
darkr 7y ago
> the ubiquitous `interface{}` pattern Ubiquitous where? It's the equivalent of `Any` in Scala (and other similar strongly typed languages with unified type hierarchy) and should be strongly discouraged in production code.
- ben0x539 7y ago
  Standard library APIs like context.Context's WithValue/Value, sync's Map/Value/Pool, stuff like the sort or container/heap packages. Some of them are obvious "really wanted generics, but wasn't important enough to get the special built-in treatment" cases, some aren't. Most logging libraries I've seen follow the pattern from fmt.Println etc to accept arbitrary `interface{}` values to be logged instead of actually using some Stringer or Formatter interface in their actual method signatures.
  - saturn_vk 7y ago
    Context's WithValue will be an interface even if go supported generics. It stores anything, not values of a specified type. Same with fmt
    - ben0x539 7y ago
      Yeah, that's what I meant with "some aren't", I was mostly listing stuff to support the idea that `interface{}` itself is ubiquitous and not some super-niche edge case that never shows up in real code.
NateDad 7y ago
I've worked on a million line Go code base and a dozen open source projects and many typical backend services, and interface{} is actually quite rare outside of something like json serialization or string printing - i.e. fmt.Printf(msg string, args ...interface{}) I almost never see code that application developers write using it, and usually if someone is writing that code, it's wrong, and I help them figure out how to avoid it. Usually you can avoid it by using closures or interfaces.
- hombre_fatal 7y ago
  Just depends on the person. Some people like to copy and paste 50 times, some people use interface{}.
  - NateDad 7y ago
    Functions are a thing. Interfaces are a thing. I have literally never, in 6 years of full time go development, just copied and pasted code for the purpose of making it work with a different type. Nor has anyone I have worked with in that time (to my knowledge). I have seen two or three libraries written that use interface{}, but these are by far the exception.
  - sacado2 7y ago
    Just depends on your application domain. I never copy/pasted code and could count the number of times I wrote `interface{}` on a single hand.
- gerbilly 7y ago
  > I've worked on a million line Go code base Oh so somebody has finally managed to implement fizz buzz in Go. Right on!
mmargerum 7y ago
I've written 100k+ loc in go and i've had to use interface{} once. I would like a coalesce operator though.

kpcyrd 7y ago

async/await is async io, this is something js is known for since it doesn't actually require parallelism. Getting concurrency _with_ parallelism right is a lot easier in rust than it is in go. You need to write thread safe code in both of them, but you get zero support from your compiler in go.

foldr 7y ago
Go provides channels for safe communication between goroutines (which are distributed across multiple threads).
- twic 7y ago
  You can use channels to pass mutable objects, which are then shared between threads. The passing itself may be safe, but the resulting situation isn't. The Rust compiler won't let you do that.
  - foldr 7y ago
    You can mutate objects from multiple threads in Go without using channels.
    - twic 7y ago
      The Rust compiler won't let you do that either!
      - foldr 7y ago
        I know. I just didn't see why you were bringing channels into it. It's not as if it's some loophole involving channels that's the issue here.
the_duke 7y ago
Rust prevents data races with the `Send` and `Sync` markers, but that's a long way from making concurrency and parallelism easy. In Go, as long as you are not sharing data, you don't really have to care about whether something is concurrent or parallel, the runtime takes care of it for you. You just use goroutines, IO transparently happens on a dedicated threadpool, CPU heavy tasks are spread out over the available cores. As long as you restrict sharing to sending owned data over channels, you are mostly in the clear. Of course sometimes performance concerns etc mandate more traditional tools (atomics, mutexes, etc) and there the compiler won't help you anymore, but I'd argue that is the exception in Go rather than the norm. You can often solve problems with a actor-system inspired design. (learning Erlang/Elixir will probably make you a better Go developer!) In Rust, you still have to care a lot about what you do. Things like tokio::fs can handle file system IO for you, but you need to ensure that code you are calling does no synchronous IO. Also, CPU heavy workloads should be offloaded to a dedicated CPU thread pool, since the tokio runtime is not intended for juggling CPU intensive tasks in addition to the async IO. This is fine for Rust, a language that wants to give you insight and control, but it is still much more demanding of the developer.
- pcwalton 7y ago
  > You just use goroutines, IO transparently happens on a dedicated threadpool, CPU heavy tasks are spread out over the available cores. In Rust you can do that too! Just use threads. That's what Go does: it just uses threads. Async I/O is there if you need better performance than what Rust—or Go—can provide. If you don't need that performance, then don't use async I/O.
  - foldr 7y ago
    Go uses async IO under the hood (for network IO at least). The exposed API is blocking, but the underlying implementation uses async IO and transparently schedules Goroutines across different OS threads. As you know, Rust doesn't currently have stable support for a similarly high-level interface to async IO. See e.g. the following reddit thread from 3 months ago: https://www.reddit.com/r/rust/comments/ausuld/what_is_the_current_state_of_async_io_in_rust/ https://www.reddit.com/r/rust/comments/ausuld/what_is_the_cu...

0815test 7y ago

People who think Rust is "complex" and "boilerplate-heavy" have never had to deal with C++, or heck, even Java. (Though I'd guess we would actually find plenty of C++/Java code within Google itself.) The only reason one could fairly give for that sort of statement is that Rust - the language itself, not just the ecosystem! - is still quite far from mature. But it's going to have a great future once some of the "tweaks" that are in the pipeline right now reach stability. Async is one of those of course, but there are more. Edit: And to be clear, I'm not a Go-hater! In fact, Go comes out-of-the-box with a very nice, high-performance concurrent GC that makes it highly appropriate for some scenarios where Rust would not be a good fit at all.

enneff 7y ago

> the ubiquitous `interface{}` pattern I’m totally biased because I’ve worked on and with go for a decade, including reviewing all sorts of Go we write at Google, but I just don’t get this criticism. It’s just not something I see in the code bases I work on. I admit that I may be working on different kinds of programs to what some others do, and I don’t want to deny anyone their legitimate experiences, but my personal experience has been that this is rarely a thing, if ever.

the_duke 7y ago
It can be found in many libraries in the ecosystem, and is common enough in the standard library. The lack of generics just severely restricts the expressiveness of the type system. I think the best way to work around this is use of code generation, which is a great tool for internal, controlled environments, but very cumbersome for open source libraries.
- enneff 7y ago
  I don’t see much, if any, generated Go code at Google. Not to say that it doesn’t happen but it’s not on my radar.
  - zigara 7y ago
    Here is an example: https://github.com/google/gvisor https://github.com/google/gvisor - https://github.com/google/gvisor/tree/master/tools/go_generics https://github.com/google/gvisor/tree/master/tools/go_generi... It was useful enough that someone made a standalone package: https://github.com/mmatczuk/go_generics https://github.com/mmatczuk/go_generics
  - pjmlp 7y ago
    Kubernetes makes heavy use of generated code, as workaround for lack of generics. They even gave a FOSDEM talk about this, with a very interesting title. https://fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...
  - 7y ago

darkr 7y ago

> the ubiquitous `interface{}` pattern Ubiquitous where? It's the equivalent of `Any` in Scala (and other similar strongly typed languages with unified type hierarchy) and should be strongly discouraged in production code.

ben0x539 7y ago
Standard library APIs like context.Context's WithValue/Value, sync's Map/Value/Pool, stuff like the sort or container/heap packages. Some of them are obvious "really wanted generics, but wasn't important enough to get the special built-in treatment" cases, some aren't. Most logging libraries I've seen follow the pattern from fmt.Println etc to accept arbitrary `interface{}` values to be logged instead of actually using some Stringer or Formatter interface in their actual method signatures.
- saturn_vk 7y ago
  Context's WithValue will be an interface even if go supported generics. It stores anything, not values of a specified type. Same with fmt
  - ben0x539 7y ago
    Yeah, that's what I meant with "some aren't", I was mostly listing stuff to support the idea that `interface{}` itself is ubiquitous and not some super-niche edge case that never shows up in real code.

NateDad 7y ago

I've worked on a million line Go code base and a dozen open source projects and many typical backend services, and interface{} is actually quite rare outside of something like json serialization or string printing - i.e. fmt.Printf(msg string, args ...interface{}) I almost never see code that application developers write using it, and usually if someone is writing that code, it's wrong, and I help them figure out how to avoid it. Usually you can avoid it by using closures or interfaces.

hombre_fatal 7y ago
Just depends on the person. Some people like to copy and paste 50 times, some people use interface{}.
- NateDad 7y ago
  Functions are a thing. Interfaces are a thing. I have literally never, in 6 years of full time go development, just copied and pasted code for the purpose of making it work with a different type. Nor has anyone I have worked with in that time (to my knowledge). I have seen two or three libraries written that use interface{}, but these are by far the exception.
- sacado2 7y ago
  Just depends on your application domain. I never copy/pasted code and could count the number of times I wrote `interface{}` on a single hand.
gerbilly 7y ago
> I've worked on a million line Go code base Oh so somebody has finally managed to implement fizz buzz in Go. Right on!

mmargerum 7y ago

I've written 100k+ loc in go and i've had to use interface{} once. I would like a coalesce operator though.