3 ms·

I have barely touched Go, but, from what I've seen, I think I might be able to add a couple more to that: Java is more intimidating to get in to. It starts wit

I have barely touched Go, but, from what I've seen, I think I might be able to add a couple more to that: Java is more intimidating to get in to. It starts with "Oh dear, which JDK do I use?", proceeds to, "Oh dear, now I have to pick a build tool and every single one has a near-vertical learning curve by modern standards." Then you're on to, "I want to do X. Why are there 28 competing libraries for X, and why are the most popular ones invariably the most hated?" And so on. There's a strong case to be made that procedural is a better paradigm than object-oriented for a lot of the niche that Go targets. You mentioned concurrency ergonomics, but I just wanted to emphasize that I doubt that Java's concurrency story can ever be a match for Go's. There's too much legacy baggage that can never be unloaded.

azth 4y ago
> but I just wanted to emphasize that I doubt that Java's concurrency story can ever be a match for Go's Project Loom is already targeted for preview for JDK19. Not only does it match golang's concurrency story, it is superior to it.
- mumblemumble 4y ago
  It's technically very impressive and I'm looking forward to it. But my point around ergonomics still stands. There will still always be all the legacy stuff, and there's not necessarily any way around having to understand how that works, too, because there's generally going to be some pre-existing library or legacy code or whatever that forces you to.
  - azth 4y ago
    The whole point of Loom is to keep using legacy (blocking) calls, and the JVM will automatically take care of things for you. > and there's not necessarily any way around having to understand how that works Same with golang, you have to understand how things work. The entire narrative that golang is "simple" is just not true. The moment things start to go wrong, you're going to have to understand how things are working behind the scenes.
kaba0 4y ago
While I think it is overstated how hard it is to choose a JDK (pretty much just get the first OpenJDK release you see, which is packaged everywhere), I do see the advantage of a default build tool. Though for beginner use cases both maven and gradle is just a copy-pastable few lines and you are ready to .. java (sorry for the joke). I don’t really agree about the 28 competing library thing though. First of all, Java has a really good standard library. Sure, it shows its age at some places but it’s not like you have to grab a new dependency for everything, I pretty much only grab deps for very specialized tasks, and in case of Java I now there will always be a match. The only difference in go here is that a bit more network-related code is in the standard library than in java, but that’s hardly that big of an advantage. Regarding concurrency: the most unique feature of go is unarguably go routines, but the language has an otherwise quite dumb concurrency model hindering its usefulness. Sure, locking should not be the primary mechanism here, but it is painfully bad with defer being function scoped, not block scoped — while java has synchronized blocks since forever. And with the already mentioned coming of Loom, the JVM platform will again rise to the top with regards to concurrency.
- mumblemumble 4y ago
  > it is overstated how hard it is to choose a JDK It's not hard to choose if you know Java well, but this sort of thing is a huge barrier to entry for someone who is just getting into it, or trying to decide what platform to use. The community doesn't help here. If you go Googling to try to figure it out, you'll find a mess of conflicting advice being argued with varying levels of passion. By definition, a newcomer doesn't have enough background knowledge to make their own decision, and they aren't necessarily in a position to know whether or not they really need to wade through all that dreck before deciding. re: frameworks, it's a similar story. Java has a pretty big standard library compared to a lot of smaller programming languages, but it's really not much different here from other platforms that punch in its same weight class, and I believe that includes golang. But the standard library is background noise; if Go's on the table then I've clearly got a job to do, and that job is probably something like writing Web services. And 28 is probably an undercount of the number of Java service and microservice frameworks out there. With a lot of vigorous discussion among proponents of each. It's got to be just stupidly intimidating to face down when you're first getting started. By contrast, I wouldn't be surprised if, by choosing Go, one could have the whole job done in less time than it would take to compile a list of all the information it seems like you have to read before you can even dip a toe into Java. Disclaimer, I don't think this translates into "Go is good, Java is bad." Personally, I would absolutely pick Java if it were a project I were getting paid to do. For several reasons, but mostly because I already know Java quite well and I know it can get the job done. And I suspect that Java has more general-purpose value than Golang does. But I don't think "Is Java a good platform?" was really the question. It was, "Why might someone choose Go over Java?" and that's a very peculiar question; one that I think you can only answer in an interesting way if you put yourself in the shoes of someone for whom it's a real decision to make - most likely someone who isn't too familiar with either.

azth 4y ago

> but I just wanted to emphasize that I doubt that Java's concurrency story can ever be a match for Go's Project Loom is already targeted for preview for JDK19. Not only does it match golang's concurrency story, it is superior to it.

mumblemumble 4y ago
It's technically very impressive and I'm looking forward to it. But my point around ergonomics still stands. There will still always be all the legacy stuff, and there's not necessarily any way around having to understand how that works, too, because there's generally going to be some pre-existing library or legacy code or whatever that forces you to.
- azth 4y ago
  The whole point of Loom is to keep using legacy (blocking) calls, and the JVM will automatically take care of things for you. > and there's not necessarily any way around having to understand how that works Same with golang, you have to understand how things work. The entire narrative that golang is "simple" is just not true. The moment things start to go wrong, you're going to have to understand how things are working behind the scenes.

kaba0 4y ago

While I think it is overstated how hard it is to choose a JDK (pretty much just get the first OpenJDK release you see, which is packaged everywhere), I do see the advantage of a default build tool. Though for beginner use cases both maven and gradle is just a copy-pastable few lines and you are ready to .. java (sorry for the joke). I don’t really agree about the 28 competing library thing though. First of all, Java has a really good standard library. Sure, it shows its age at some places but it’s not like you have to grab a new dependency for everything, I pretty much only grab deps for very specialized tasks, and in case of Java I now there will always be a match. The only difference in go here is that a bit more network-related code is in the standard library than in java, but that’s hardly that big of an advantage. Regarding concurrency: the most unique feature of go is unarguably go routines, but the language has an otherwise quite dumb concurrency model hindering its usefulness. Sure, locking should not be the primary mechanism here, but it is painfully bad with defer being function scoped, not block scoped — while java has synchronized blocks since forever. And with the already mentioned coming of Loom, the JVM platform will again rise to the top with regards to concurrency.

mumblemumble 4y ago
> it is overstated how hard it is to choose a JDK It's not hard to choose if you know Java well, but this sort of thing is a huge barrier to entry for someone who is just getting into it, or trying to decide what platform to use. The community doesn't help here. If you go Googling to try to figure it out, you'll find a mess of conflicting advice being argued with varying levels of passion. By definition, a newcomer doesn't have enough background knowledge to make their own decision, and they aren't necessarily in a position to know whether or not they really need to wade through all that dreck before deciding. re: frameworks, it's a similar story. Java has a pretty big standard library compared to a lot of smaller programming languages, but it's really not much different here from other platforms that punch in its same weight class, and I believe that includes golang. But the standard library is background noise; if Go's on the table then I've clearly got a job to do, and that job is probably something like writing Web services. And 28 is probably an undercount of the number of Java service and microservice frameworks out there. With a lot of vigorous discussion among proponents of each. It's got to be just stupidly intimidating to face down when you're first getting started. By contrast, I wouldn't be surprised if, by choosing Go, one could have the whole job done in less time than it would take to compile a list of all the information it seems like you have to read before you can even dip a toe into Java. Disclaimer, I don't think this translates into "Go is good, Java is bad." Personally, I would absolutely pick Java if it were a project I were getting paid to do. For several reasons, but mostly because I already know Java quite well and I know it can get the job done. And I suspect that Java has more general-purpose value than Golang does. But I don't think "Is Java a good platform?" was really the question. It was, "Why might someone choose Go over Java?" and that's a very peculiar question; one that I think you can only answer in an interesting way if you put yourself in the shoes of someone for whom it's a real decision to make - most likely someone who isn't too familiar with either.