I began my career writing Java and PHP a long time ago. Now, I mostly write Go. I am a devops engineer by day and I also write tools for tabletop role-playing games.
Now, to my reply.
Java's verbosity is its fatal flaw for me. I can write a command line program in Go that is 10% of the size of the same program in Java with a smaller memory footprint and a faster runtime.
This is not to say that Java is always the wrong choice. If a business is already using Java, then it makes sense to continue to use Java. But I will never recommend it for a new project.
This is what always gets me too, and is why I have always avoided Java. It still takes much longer than it should to read Java code because simple things require so much code. Even C#, which was originally based on Java, manages to be a lot more concise.
I’m glad to hear you say Go doesn’t have this problem. I’ve looked at Go briefly, several years ago, but haven’t spent a lot of time with it. I got the impression the error-handling in Go makes it really verbose. But I heard that’s supposed to get better in Go 2.
Error handling in Go is verbose. That's true. However, the verbosity of error handling in Go is a little different, in that it forces you to acknowledge potential fail states in your code. Also, if you really want to, you can completely ignore error handling entirely in favor of concise code. That makes me twitch, but it's possible.
Aren't checked exceptions in the same area as "forcing developer to acknowledge potential fail states", while allowing developers to ignore them if they want to, and also allowing developers to purposely going with unchecked exceptions if they prefer?
Hasn't features like Type-Inference (var), lambdas, new APIs in the Collections Framework, and recently Records and pattern matching helped in any form to reduce the verbosity?
I mean, this is a possibility with Java 15:
publicrecordPerson(Stringname,intage){}publicclassProcess{publicvoidprocess(){varp0=newPerson("a",18);varp1=...;varlist=List.of(p0,p1);// sum all ageslist.stream().mapToInt(Person::age).sum();}}
Yup, glad to see those advances. It’s taken much, much too long IMO for the language to catch up and introduce things like that. I gave up on it before those were part of the language, and that was after 15 years of waiting.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
First, some context on my reply:
I began my career writing Java and PHP a long time ago. Now, I mostly write Go. I am a devops engineer by day and I also write tools for tabletop role-playing games.
Now, to my reply.
Java's verbosity is its fatal flaw for me. I can write a command line program in Go that is 10% of the size of the same program in Java with a smaller memory footprint and a faster runtime.
This is not to say that Java is always the wrong choice. If a business is already using Java, then it makes sense to continue to use Java. But I will never recommend it for a new project.
This is what always gets me too, and is why I have always avoided Java. It still takes much longer than it should to read Java code because simple things require so much code. Even C#, which was originally based on Java, manages to be a lot more concise.
I’m glad to hear you say Go doesn’t have this problem. I’ve looked at Go briefly, several years ago, but haven’t spent a lot of time with it. I got the impression the error-handling in Go makes it really verbose. But I heard that’s supposed to get better in Go 2.
Error handling in Go is verbose. That's true. However, the verbosity of error handling in Go is a little different, in that it forces you to acknowledge potential fail states in your code. Also, if you really want to, you can completely ignore error handling entirely in favor of concise code. That makes me twitch, but it's possible.
To be clear, I wasn’t implying I like to ignore error handling. Just that I like it to be concise.
Aren't checked exceptions in the same area as "forcing developer to acknowledge potential fail states", while allowing developers to ignore them if they want to, and also allowing developers to purposely going with unchecked exceptions if they prefer?
Hasn't features like Type-Inference (var), lambdas, new APIs in the Collections Framework, and recently Records and pattern matching helped in any form to reduce the verbosity?
I mean, this is a possibility with Java 15:
Yup, glad to see those advances. It’s taken much, much too long IMO for the language to catch up and introduce things like that. I gave up on it before those were part of the language, and that was after 15 years of waiting.