5 ms·

I've moved from Java to Go and I appreciate it very much. It's very practical for day-to-day development. The 2 killer features for me are: 1. the built-in too

by kitd 7y ago

I've moved from Java to Go and I appreciate it very much. It's very practical for day-to-day development. The 2 killer features for me are: 1. the built-in tooling (cross-platform building, profiling, formatting, test coverage, etc) 2. the standard library. I've written services that have convoluted TLS certificate handling, encryption and REST calls and never had to look elsewhere. The language itself is good, though 2 gripes for me: 1. x.Y. At first glance, it isn't obvious whether this is function Y in package x, or method Y on object x. Package::function would be better IMHO. 2. The ':=' assignment with inference operator has sometimes led to unintended variable shadowing. edit: another one comes to mind. The usual ... generics, pretty pls? BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be?

LandR 7y ago
> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? I think for certain use cases C# or Java will be faster. THere was a post here the other day about a network driver written in C, Rust, C#, Go, Java and a few others and The C# one was faster then Go. Can't remember if Java was faster or not.
- coder543 7y ago
  > The C# one was faster then Go As pointed out over here (https://news.ycombinator.com/item?id=20984503 https://news.ycombinator.com/item?id=20984503), Compared to C#, Go was faster (higher throughput) for smaller batch sizes, and it always had significantly lower latency. .NET Core is particularly good these days, so I'm sure there are times when C# is definitely faster than Go, but the network driver isn't a great example to support that.
  - joelfolksy 7y ago
    Are we looking at the same charts? Go and C# are practically on top of each other for smaller batch sizes, then C# pulls ahead significantly.
    - coder543 7y ago
      If you’re looking at the latency chart, higher is worse. The right hand side of the C# graph is not a good thing. The throughput graph doesn’t show C# pulling ahead significantly. Significant is how far behind Java is from Go and C# in that benchmark. Also be sure you’re not looking at JavaScript on the throughout graph, since it is colored very similarly to Go.
- specialist 7y ago
  [Another] keen observation on that network driver thread is performance is bound by memory copying. For which Java, C#, etc. can all be about the same. FWIW: Back in ~1998, I wrote a VRML browser that was faster (FPS and event loop) than Sony's. Benchmarks showed Sony's was then the fastest (publicly available). They used 'C'. I used Java (JDK 1.2). We both used same OpenGL stack. Same kind of deal as a network stack. Most of FPS was due the graphics card and use of OpenGL. Java's JNI added a minor performance penalty. As for the all the other stuff, like reading files, parsing, user interface, I just figured Sony's VRML team sucked (worse than me). Update: Others made the point about latencies.
rowanseymour 7y ago
Feel exactly the same about your two gripes! Seems odd that a language that considers it too risky to give devs things like ternary operators.. makes it so easy to accidentally shadow variables. And the package thing gets annoying because it's natural to call a package that deal with foos.. the `foos` package.. but that's also the natural name somewhere else for a slice of foos.
baby 7y ago
This, Rust is awesome but its standard library is truly lacking.
- Yoric 7y ago
  What do you miss in the standard library? Fwiw, Rust attempts, by design, to not be batteries included, as this would tie Rust to specific architectures, or operating systems – or even require Rust code to run on an operating system, which doesn't have to be the case. So, yeah, as a Rust dev, I pretty much always rely upon external crates. But hey, that's what they're here for :)
  - saagarjha 7y ago
    When I was playing with Rust a while back, I recall there being no easy to generate a random number in the standard library.
    - Communitivity 7y ago
      A lot of what you might find in the standard library of other languages is offloaded to crates, by design in order to keep the core Rust footprint small. For random numbers, there is the rand crate, described here in the Rust Cookbook: https://rust-lang-nursery.github.io/rust-cookbook/algorithms/randomness.html https://rust-lang-nursery.github.io/rust-cookbook/algorithms...
      - baby 7y ago
        The problem is that it is easy to trust standard libraries, but third party dependencies? For something basic you’d think rust could have included that in their std. It makes no sense to call a third party, and maybe a broken one, when you want to generate a random number. The worst part about rust is its standard library and thats not a secret.
  - baby 7y ago
    rand is the first thing that comes to mind, json parser, any crypto, etc. Take a look at the golang standard library.
bryanlarsen 7y ago
> 2. the standard library. I've written services that have convoluted TLS certificate handling, encryption and REST calls and never had to look elsewhere. Is this going to be an issue in a decade or two? http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...
- kitd 7y ago
  That's a good point. I suppose "usefulness" in today's world reflects the kind of problems being solved today. eg Java had CORBA support for years, just because in the late 90s, distributed objects were going to be a thing. XML/WS support is still there, but it took a while to get JSON/REST, etc. If you want to remove stdlib packages, I guess you would need Go to ship a tool that automatically rewrites sources to point those package imports to a standard "golang/x" location (or something) that provides the same package. Or alternatively, some kind of indirection via the go.mod file.
omegabravo 7y ago
> 2. The ':=' assignment with inference operator has sometimes led to unintended variable shadowing. I've been bitten by this once or twice? It is helpful for when declare and assign multiple return values. eg: g, ctx := errgroup.WithContext(ctx) there is of course a shadowed variable above. In practice it hasn't really been an issue for me, but I can see the foot gun. The thing I like most about Go is the resulting output is a lot easier to follow. Maybe that's just because I am more familiar with Go than Java. Java seems to have endless abstractions that are not intuitive to me
- NoodleIncident 7y ago
  In my experience, the multiple-return `, err` convention and the `:=` syntax sugar are constantly clashing. It's confusing because the `err` is reused, but still has to be created at some point; and because `:=` is allowed even if only one variable is being created, but forbidden if you're only assigning. It doesn't always lead to a bug, but it's always frustrating. Even when restricting the problem to a single (non-error) return value, there are 6 combinations to consider: * What do you do with the non-error return value? (none/assign/create) * Is it the first time you've checked an error? (yes/no) none, yes | err := f() none, no | err = f() assign, yes | var err error; r, err = f() assign, no | r, err = f() create, yes | r, err := f() create, no | r, err := f() The shadowing case comes up infrequently enough to surprise you when it does. You've been trained by the other examples to change `=` to `:=` when you see a certain error, and you don't always get a warning about the shadow this creates.
  - irq-1 7y ago
    This is annoying and should be fixed: err should be pre-declared along with the stack. := should both allow assignment without creation and NOT create shadow variables (which could still be made explicitly with var.) It would be a poor argument that var and := show where declaration happens. The := rules seem made for the clarity of the parser rather than the programmer.
    - NoodleIncident 7y ago
gengstrand 7y ago
> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? I very recently ran an evaluation that included load testing feature identical business focused microservices written in both Java and Go. These are IO bound processes. The results are that, in this context, Go is on par with Java when it comes to performance (i.e. throughput and latency). http://glennengstrand.info/software/architecture/microservice/golang http://glennengstrand.info/software/architecture/microservic...
apta 7y ago
> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? Not for any meaningful deployments. The amounts of optimizations done by HotSpot completely dominate anything that golang does (which isn't much). In golang, not even function parameters are optimized to be passed in registers, let alone aggressive interface devirtualization, etc.

by kitd 7y ago

LandR 7y ago

> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? I think for certain use cases C# or Java will be faster. THere was a post here the other day about a network driver written in C, Rust, C#, Go, Java and a few others and The C# one was faster then Go. Can't remember if Java was faster or not.

coder543 7y ago
> The C# one was faster then Go As pointed out over here (https://news.ycombinator.com/item?id=20984503 https://news.ycombinator.com/item?id=20984503), Compared to C#, Go was faster (higher throughput) for smaller batch sizes, and it always had significantly lower latency. .NET Core is particularly good these days, so I'm sure there are times when C# is definitely faster than Go, but the network driver isn't a great example to support that.
- joelfolksy 7y ago
  Are we looking at the same charts? Go and C# are practically on top of each other for smaller batch sizes, then C# pulls ahead significantly.
  - coder543 7y ago
    If you’re looking at the latency chart, higher is worse. The right hand side of the C# graph is not a good thing. The throughput graph doesn’t show C# pulling ahead significantly. Significant is how far behind Java is from Go and C# in that benchmark. Also be sure you’re not looking at JavaScript on the throughout graph, since it is colored very similarly to Go.
specialist 7y ago
[Another] keen observation on that network driver thread is performance is bound by memory copying. For which Java, C#, etc. can all be about the same. FWIW: Back in ~1998, I wrote a VRML browser that was faster (FPS and event loop) than Sony's. Benchmarks showed Sony's was then the fastest (publicly available). They used 'C'. I used Java (JDK 1.2). We both used same OpenGL stack. Same kind of deal as a network stack. Most of FPS was due the graphics card and use of OpenGL. Java's JNI added a minor performance penalty. As for the all the other stuff, like reading files, parsing, user interface, I just figured Sony's VRML team sucked (worse than me). Update: Others made the point about latencies.

rowanseymour 7y ago

Feel exactly the same about your two gripes! Seems odd that a language that considers it too risky to give devs things like ternary operators.. makes it so easy to accidentally shadow variables. And the package thing gets annoying because it's natural to call a package that deal with foos.. the `foos` package.. but that's also the natural name somewhere else for a slice of foos.

baby 7y ago

This, Rust is awesome but its standard library is truly lacking.

Yoric 7y ago
What do you miss in the standard library? Fwiw, Rust attempts, by design, to not be batteries included, as this would tie Rust to specific architectures, or operating systems – or even require Rust code to run on an operating system, which doesn't have to be the case. So, yeah, as a Rust dev, I pretty much always rely upon external crates. But hey, that's what they're here for :)
- saagarjha 7y ago
  When I was playing with Rust a while back, I recall there being no easy to generate a random number in the standard library.
  - Communitivity 7y ago
    A lot of what you might find in the standard library of other languages is offloaded to crates, by design in order to keep the core Rust footprint small. For random numbers, there is the rand crate, described here in the Rust Cookbook: https://rust-lang-nursery.github.io/rust-cookbook/algorithms/randomness.html https://rust-lang-nursery.github.io/rust-cookbook/algorithms...
    - baby 7y ago
      The problem is that it is easy to trust standard libraries, but third party dependencies? For something basic you’d think rust could have included that in their std. It makes no sense to call a third party, and maybe a broken one, when you want to generate a random number. The worst part about rust is its standard library and thats not a secret.
- baby 7y ago
  rand is the first thing that comes to mind, json parser, any crypto, etc. Take a look at the golang standard library.

bryanlarsen 7y ago

> 2. the standard library. I've written services that have convoluted TLS certificate handling, encryption and REST calls and never had to look elsewhere. Is this going to be an issue in a decade or two? http://pyfound.blogspot.com/2019/05/amber-brown-batteries-included-but.html http://pyfound.blogspot.com/2019/05/amber-brown-batteries-in...

kitd 7y ago
That's a good point. I suppose "usefulness" in today's world reflects the kind of problems being solved today. eg Java had CORBA support for years, just because in the late 90s, distributed objects were going to be a thing. XML/WS support is still there, but it took a while to get JSON/REST, etc. If you want to remove stdlib packages, I guess you would need Go to ship a tool that automatically rewrites sources to point those package imports to a standard "golang/x" location (or something) that provides the same package. Or alternatively, some kind of indirection via the go.mod file.

omegabravo 7y ago

> 2. The ':=' assignment with inference operator has sometimes led to unintended variable shadowing. I've been bitten by this once or twice? It is helpful for when declare and assign multiple return values. eg: g, ctx := errgroup.WithContext(ctx) there is of course a shadowed variable above. In practice it hasn't really been an issue for me, but I can see the foot gun. The thing I like most about Go is the resulting output is a lot easier to follow. Maybe that's just because I am more familiar with Go than Java. Java seems to have endless abstractions that are not intuitive to me

NoodleIncident 7y ago
In my experience, the multiple-return `, err` convention and the `:=` syntax sugar are constantly clashing. It's confusing because the `err` is reused, but still has to be created at some point; and because `:=` is allowed even if only one variable is being created, but forbidden if you're only assigning. It doesn't always lead to a bug, but it's always frustrating. Even when restricting the problem to a single (non-error) return value, there are 6 combinations to consider: * What do you do with the non-error return value? (none/assign/create) * Is it the first time you've checked an error? (yes/no) none, yes | err := f() none, no | err = f() assign, yes | var err error; r, err = f() assign, no | r, err = f() create, yes | r, err := f() create, no | r, err := f() The shadowing case comes up infrequently enough to surprise you when it does. You've been trained by the other examples to change `=` to `:=` when you see a certain error, and you don't always get a warning about the shadow this creates.
- irq-1 7y ago
  This is annoying and should be fixed: err should be pre-declared along with the stack. := should both allow assignment without creation and NOT create shadow variables (which could still be made explicitly with var.) It would be a poor argument that var and := show where declaration happens. The := rules seem made for the clarity of the parser rather than the programmer.
  - NoodleIncident 7y ago

gengstrand 7y ago

> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? I very recently ran an evaluation that included load testing feature identical business focused microservices written in both Java and Go. These are IO bound processes. The results are that, in this context, Go is on par with Java when it comes to performance (i.e. throughput and latency). http://glennengstrand.info/software/architecture/microservice/golang http://glennengstrand.info/software/architecture/microservic...

apta 7y ago

> BTW, the author claims Go is faster than Java. Is this true, because it didn't used to be? Not for any meaningful deployments. The amounts of optimizations done by HotSpot completely dominate anything that golang does (which isn't much). In golang, not even function parameters are optimized to be passed in registers, let alone aggressive interface devirtualization, etc.