5 ms·

Go uses a lot less memory than Java, according to most comparisons. There's a lot of work going on in the cloud space with Go applications (docker, kubernetes,

by NateDad 11y ago

Go uses a lot less memory than Java, according to most comparisons. There's a lot of work going on in the cloud space with Go applications (docker, kubernetes, etc), so there's a lot of new libraries for networked webservers getting written. But mostly, you may find you just enjoy writing Go more than Java. It writes a lot like python... I switched from mainly writing C# to almost exclusively writing Go, and whoo boy, I'm not going back. No more huge class hierarchies, no more "everything has to be in a class"... no more "anything I call may throw and jump me out of my function in the middle and I have no idea if it will or not". There's just a lot of niceties of writing Go that don't exist in Java. Sure, there's a ton you can do in Java that you can't do in Go, but once you stop focusing on what Go can't do, you realize, it still can do pretty much whatever you want.

vvanders 11y ago
Java memory usage is not really that high if a bar to beat. Dropbox just rewrote parts of their Go infra into Rust explicitly because of the memory savings they needed.
- NateDad 11y ago
  Well.. yes, exactly. The question was "why should I learn Go if I know Java?" That's a pretty good reason.
- ngrilly 11y ago
  Yes, but the rewrite would have happened ever sooner if the original code had been written in Java instead of Go. The Dropbox case is really very specific and very low-level.
golergka 11y ago
Anything you call in go can panic, what's the difference?
- danieldk 11y ago
  And nearly anything you can call in any language could theoretically exit(3). The difference is that exceptions are a normal control structure in C#, Java, or even C++, while the use of panic should be exceptional. It's not considered the regular way to report an error. Of course, if you have checked exceptions (which are for some unfathomable reason considered bad nowadays), nothing just throws an exception. Moreover, you don't know for sure whether a Go library correctly handles errors, because it's so easy to ignore them.
  - NateDad 11y ago
    The problem with checked exceptions is that your code trends towards having every method marked as 'throws Exception' (or whatever your application's top level exception is). Any time a low level method changes to throw a new exception, every method that calls it has to update their exception spec... or they need to have their catch clauses updated to catch the additional exception and either deal with it - unlikely - or wrap it and rethrow it as one of their other expected exceptions.... or they're already catching Exception, which is also bad. At my last job, very few methods in the application ended up throwing a specific list of exceptions, except the most leaf-ward modules. Anything anywhere near the application logic just threw our top level generic exception, because there was too much below them that could throw a variety of exceptions, and there generally was nothing the middle-tier code could do about it if they failed. It's really not that easy to ignore errors in Go in practice... and you might as well worry that a library correctly handles the result of string.Split() incorrectly. Either one is a bug. Hopefully your tests would find either one, and there are tools to detect errors you didn't handle.
    - danieldk 11y ago
      Any time a low level method changes to throw a new exception, You don't do that in API-stable code, period. If you are working with API-unstable code - that's the point of static typing. The code won't compile because the intention is exactly to signal that something has changed. If you change the return type of a low-level Go function, you will have to modify its callers as well. Anything anywhere near the application logic just threw our top level generic exception, Bad codebase = bad. Sure. I never encountered that problem in the Java codebases I worked on at various employers. (And I'd be quite happy to complain about Java, I don't like it.) It's really not that easy to ignore errors in Go in practice... It is. The compiler will not emit a warning when you ignore the return value of a function/method. Here: fmt.Println("Hello world") I have just ignored an error. The compiler is happy. There are quite some Go packages in the wild that do not deal with errors when they need to.

by NateDad 11y ago

vvanders 11y ago

Java memory usage is not really that high if a bar to beat. Dropbox just rewrote parts of their Go infra into Rust explicitly because of the memory savings they needed.

NateDad 11y ago
Well.. yes, exactly. The question was "why should I learn Go if I know Java?" That's a pretty good reason.
ngrilly 11y ago
Yes, but the rewrite would have happened ever sooner if the original code had been written in Java instead of Go. The Dropbox case is really very specific and very low-level.

golergka 11y ago

Anything you call in go can panic, what's the difference?

danieldk 11y ago
And nearly anything you can call in any language could theoretically exit(3). The difference is that exceptions are a normal control structure in C#, Java, or even C++, while the use of panic should be exceptional. It's not considered the regular way to report an error. Of course, if you have checked exceptions (which are for some unfathomable reason considered bad nowadays), nothing just throws an exception. Moreover, you don't know for sure whether a Go library correctly handles errors, because it's so easy to ignore them.
- NateDad 11y ago
  The problem with checked exceptions is that your code trends towards having every method marked as 'throws Exception' (or whatever your application's top level exception is). Any time a low level method changes to throw a new exception, every method that calls it has to update their exception spec... or they need to have their catch clauses updated to catch the additional exception and either deal with it - unlikely - or wrap it and rethrow it as one of their other expected exceptions.... or they're already catching Exception, which is also bad. At my last job, very few methods in the application ended up throwing a specific list of exceptions, except the most leaf-ward modules. Anything anywhere near the application logic just threw our top level generic exception, because there was too much below them that could throw a variety of exceptions, and there generally was nothing the middle-tier code could do about it if they failed. It's really not that easy to ignore errors in Go in practice... and you might as well worry that a library correctly handles the result of string.Split() incorrectly. Either one is a bug. Hopefully your tests would find either one, and there are tools to detect errors you didn't handle.
  - danieldk 11y ago
    Any time a low level method changes to throw a new exception, You don't do that in API-stable code, period. If you are working with API-unstable code - that's the point of static typing. The code won't compile because the intention is exactly to signal that something has changed. If you change the return type of a low-level Go function, you will have to modify its callers as well. Anything anywhere near the application logic just threw our top level generic exception, Bad codebase = bad. Sure. I never encountered that problem in the Java codebases I worked on at various employers. (And I'd be quite happy to complain about Java, I don't like it.) It's really not that easy to ignore errors in Go in practice... It is. The compiler will not emit a warning when you ignore the return value of a function/method. Here: fmt.Println("Hello world") I have just ignored an error. The compiler is happy. There are quite some Go packages in the wild that do not deal with errors when they need to.