5 ms·

Since Go doesn't even have inheritance or getters and setters, they may have a point (though getters and setters are pretty easy to do I guess if you want them,

Since Go doesn't even have inheritance or getters and setters, they may have a point (though getters and setters are pretty easy to do I guess if you want them, it's not part of the culture). Culture is really important in programming languages and I'm not sure it is something you can ever separate from the language itself, as for example the standard library dictates in large part the structure of your own code. I do agree though that there is no great reason Java has to be more verbose or more confusing than say Go.

jimbokun 7y ago
> I do agree though that there is no great reason Java has to be more verbose or more confusing than say Go. Not a Go developer, but two things off the top of my head: 1. Do not need to explicitly declare interfaces a struct conforms to. 2. Do not need to declare types of variables inferred on initialization. 3. Syntax for slice, map and struct literals. I'm sure there's more...
- throwaway894345 7y ago
  I'm generally of the opinion that Go is less verbose than Java as well, but I'm of the impression that a lot has changed in Java since I last used it. It now has lambdas and other niceties, for example. Go has error boilerplate and lacks generics. Personally, I think Go's boilerplate is less of a big deal in general (Java's generics, lambdas, and exception handling come with their own issues which are often more significant than Go's boilerplate). Mostly I just don't think a debate about which language has less boilerplate will be very enlightening.
- nine_k 7y ago
  With Lmobok, you can use `var` for local variables, and it will infer the type for you. It also can produce default constructors of various kinds. Can't have nice syntax for object literals, maps, slices, etc, though :( I mean, I have no hope for it to be introduced to the language any time soon, even if the desire is there among the language stewards.
  - apta 7y ago
    > With Lmobok, you can use `var` for local variables `var` is part of standard Java, you don't have to use Lombok. > Can't have nice syntax for object literals Could you elaborate on what you mean by object literals in this context?
    - nine_k 7y ago
      Some shops are still not Java 10, but Lombok helps you use `var` even there.
    - nine_k 7y ago
      Object literals: think JavaScript. const foo = new Bar a = 1, b = 2 } With a default constructor or a builder (both provided by Lombok, maybe with other libraries, too) this level of succinctness is quite achievable in Java, too.
- apta 7y ago
  > Do not need to explicitly declare interfaces a struct conforms to. Which comes with its own (sometimes dangerous) downsides. > 2. Do not need to declare types of variables inferred on initialization. Java has `var` for quite some time now: var foo = new Foo<Bar>(); is valid. > Syntax for slice, map and struct literals I assume you mean overloading `[]` for slices and maps. This is a nice feature (C# and Kotlin already do this). But it doesn't reduce boilerplate by much in practice.
  - throwaway894345 7y ago
    > Which comes with its own (sometimes dangerous) downsides. I don't buy this. I've heard the theoretical arguments to the contrary, but I've never (in 7 years of consistent Go use) heard of anyone being bit by this in practice--certainly not to any significant consequence. On the other hand, implicit interfaces materially benefit nearly every project in the Go ecosystem. I would make this tradeoff all day every day.
    - apta 7y ago
      There was an actual bug in the golang standard library precisely due to this feature, so it's far from theoretical. Secondly, I found that in practice, it doesn't buy you much, and on the contrary, makes working with code more difficult (even with an IDE). It's valuable information to know what interface(s) a type implements, not to mention finding all types down the hierarchy that implement a given interface (much more tedious and resource hungry with golang).
      - throwaway894345 7y ago
        One incident doesn't make it "far from theoretical". I concede that it's "vanishingly small", however. > Secondly, I found that in practice, it doesn't buy you much, and on the contrary, makes working with code more difficult (even with an IDE). I don't know about you, but I don't like having to write boilerplate to make a third party class implement a first party interface. > It's valuable information to know what interface(s) a type implements, not to mention finding all types down the hierarchy that implement a given interface (much more tedious and resource hungry with golang). How is that information valuable? The only thing I can think of is "I want to change the interface and consequently I need to update the implementations". In which case, just change the interface and the compiler will tell you what broke. As for "resource hungry", who cares? I'll trade 50ms of computing time per search (note that this is a generous figure) if it means developers don't need to maintain "implements" annotations and the corresponding boilerplate discussed above.
- grey-area 7y ago
  Personally I think Java is more verbose because of culture and one big feature go does not have - inheritance. Indeed some regret has been expressed by the Java authors on inheritance. The things you mention don’t bother me as much as pointless ceremony like getters, factories, and insane object hierarchies, all of which are really optional. I quite like Go and use it a lot, but it is not IMO radically different from Java in syntax, except perhaps in what it leaves out (inheritance, exceptions, explicit declarations), and its culture of radical simplicity.
Sohcahtoa82 7y ago
> Since Go doesn't even have inheritance or getters and setters Does Go have objects with functions? If so, it has getters and setters, Go programmers just choose not to use them. I could absolutly write Python code like this: class MyObject(object): def set_foo(this, foo): this.foo = foo def get_foo(this): return this.foo The thing is...Java doesn't have getters and setters. There's nothing about the language that requires them. This is perfectly legal Java code: class MyObject { public int foo; } Look at it! It's a public member! You can read/write to it without a getter/setter! You know, something every language has, but for some reason, it's considered verboten in Java. Java is a perfectly fine language. It's Java programmers that are awful for sticking to these unnecessary paradigms that necessitate ridiculous amounts of boilerplate.
- deleted 7y ago
  [deleted]
- throwaway894345 7y ago
  I agree with your point, but the snark here is unwarranted (pretty sure the parent isn't even contesting your point) and very likely to derail the otherwise interesting conversation (IMHO).
  - Sohcahtoa82 7y ago
    Re-reading the other comment and my response, yeah, you're probably right. Java programmers are a source of frustration for me. I don't write Java professionally, but I do application security which involves reading a lot of Java code. And because the developers are sticking so strictly to the typical Java paradigms, the code is very difficult to read. Testing things locally is a nightmare, since stack traces are a ridiculous stacks of .invoke, as if Java programmers are afraid of directly calling functions. I let my frustration get the better of me and I apologize.
- hota_mazi 7y ago
  > for some reason, it's considered verboten in Java. It's not just "for some reason". There are plenty of reasons why getters are a superior approach to naked fields, and these have been documented to death for the past twenty years. If your field is not final, you should hide it behind a getter/setter.
nine_k 7y ago
In my opinion, if Go does one thing exactly right, it's the "OOP". That is, interfaces and explicit receiver arguments in functions. Interfaces are extendable, classes are not, because there are no classes per se, let alone abstract classes. Maybe conforming to an interface without explicitly declaring it (like you declare an instance of a typeclass in Haskell) may look like a controversial decision. I still think it does more good by removing boilerplate than bad by accepting an object as conforming to an interface in a rare case when you did not mean it.
- throwaway894345 7y ago
  I agree with all of this, but Go also has a pretty great standard library, tooling, and deployment story that you're overlooking. Notably, Go's tools are fast (no need to run a daemon because CLIs take too long to start up), there's no imperative DSL for its build system, there's a builtin/standard test runner, there's a standard formatter, documentation is simple and comes out of the box (no special javadoc syntax, just comments above functions; no need to write a CI job to build and publish docs nor a webserver to host them), profiling and benchmarking are builtin. That said, the thing I like about Java is that its JIT compiler and bytecode system allow for efficient metaprogramming; Go's runtime package works, but it's not fast at all. These use cases are few and far between, but it would be nice if Go had a good web framework story (e.g. rails, django, spring, etc). > Maybe conforming to an interface without explicitly declaring it (like you declare an instance of a typeclass in Haskell) may look like a controversial decision. I still think it does more good by removing boilerplate than bad by accepting an object as conforming to an interface in a rare case when you did not mean it. Yeah, I hear this objection pretty frequently, but I've literally never heard of a single instance of this resulting in a real production bug. If it's a rare case, it's vanishingly rare, while it's no exaggeration to say that virtually every project benefits from the advantages.
  - nine_k 7y ago
    Go has a brilliant ecosystem, even if it has slight problems still (package vendoring, etc). The language may be lacking here and there, but the tooling around it is good, and the runtime of it is great (sub-ms garbage collection, etc).

jimbokun 7y ago

> I do agree though that there is no great reason Java has to be more verbose or more confusing than say Go. Not a Go developer, but two things off the top of my head: 1. Do not need to explicitly declare interfaces a struct conforms to. 2. Do not need to declare types of variables inferred on initialization. 3. Syntax for slice, map and struct literals. I'm sure there's more...

throwaway894345 7y ago
I'm generally of the opinion that Go is less verbose than Java as well, but I'm of the impression that a lot has changed in Java since I last used it. It now has lambdas and other niceties, for example. Go has error boilerplate and lacks generics. Personally, I think Go's boilerplate is less of a big deal in general (Java's generics, lambdas, and exception handling come with their own issues which are often more significant than Go's boilerplate). Mostly I just don't think a debate about which language has less boilerplate will be very enlightening.
nine_k 7y ago
With Lmobok, you can use `var` for local variables, and it will infer the type for you. It also can produce default constructors of various kinds. Can't have nice syntax for object literals, maps, slices, etc, though :( I mean, I have no hope for it to be introduced to the language any time soon, even if the desire is there among the language stewards.
- apta 7y ago
  > With Lmobok, you can use `var` for local variables `var` is part of standard Java, you don't have to use Lombok. > Can't have nice syntax for object literals Could you elaborate on what you mean by object literals in this context?
  - nine_k 7y ago
    Some shops are still not Java 10, but Lombok helps you use `var` even there.
  - nine_k 7y ago
    Object literals: think JavaScript. const foo = new Bar a = 1, b = 2 } With a default constructor or a builder (both provided by Lombok, maybe with other libraries, too) this level of succinctness is quite achievable in Java, too.
apta 7y ago
> Do not need to explicitly declare interfaces a struct conforms to. Which comes with its own (sometimes dangerous) downsides. > 2. Do not need to declare types of variables inferred on initialization. Java has `var` for quite some time now: var foo = new Foo<Bar>(); is valid. > Syntax for slice, map and struct literals I assume you mean overloading `[]` for slices and maps. This is a nice feature (C# and Kotlin already do this). But it doesn't reduce boilerplate by much in practice.
- throwaway894345 7y ago
  > Which comes with its own (sometimes dangerous) downsides. I don't buy this. I've heard the theoretical arguments to the contrary, but I've never (in 7 years of consistent Go use) heard of anyone being bit by this in practice--certainly not to any significant consequence. On the other hand, implicit interfaces materially benefit nearly every project in the Go ecosystem. I would make this tradeoff all day every day.
  - apta 7y ago
    There was an actual bug in the golang standard library precisely due to this feature, so it's far from theoretical. Secondly, I found that in practice, it doesn't buy you much, and on the contrary, makes working with code more difficult (even with an IDE). It's valuable information to know what interface(s) a type implements, not to mention finding all types down the hierarchy that implement a given interface (much more tedious and resource hungry with golang).
    - throwaway894345 7y ago
      One incident doesn't make it "far from theoretical". I concede that it's "vanishingly small", however. > Secondly, I found that in practice, it doesn't buy you much, and on the contrary, makes working with code more difficult (even with an IDE). I don't know about you, but I don't like having to write boilerplate to make a third party class implement a first party interface. > It's valuable information to know what interface(s) a type implements, not to mention finding all types down the hierarchy that implement a given interface (much more tedious and resource hungry with golang). How is that information valuable? The only thing I can think of is "I want to change the interface and consequently I need to update the implementations". In which case, just change the interface and the compiler will tell you what broke. As for "resource hungry", who cares? I'll trade 50ms of computing time per search (note that this is a generous figure) if it means developers don't need to maintain "implements" annotations and the corresponding boilerplate discussed above.
grey-area 7y ago
Personally I think Java is more verbose because of culture and one big feature go does not have - inheritance. Indeed some regret has been expressed by the Java authors on inheritance. The things you mention don’t bother me as much as pointless ceremony like getters, factories, and insane object hierarchies, all of which are really optional. I quite like Go and use it a lot, but it is not IMO radically different from Java in syntax, except perhaps in what it leaves out (inheritance, exceptions, explicit declarations), and its culture of radical simplicity.

Sohcahtoa82 7y ago

> Since Go doesn't even have inheritance or getters and setters Does Go have objects with functions? If so, it has getters and setters, Go programmers just choose not to use them. I could absolutly write Python code like this: class MyObject(object): def set_foo(this, foo): this.foo = foo def get_foo(this): return this.foo The thing is...Java doesn't have getters and setters. There's nothing about the language that requires them. This is perfectly legal Java code: class MyObject { public int foo; } Look at it! It's a public member! You can read/write to it without a getter/setter! You know, something every language has, but for some reason, it's considered verboten in Java. Java is a perfectly fine language. It's Java programmers that are awful for sticking to these unnecessary paradigms that necessitate ridiculous amounts of boilerplate.

deleted 7y ago
[deleted]
throwaway894345 7y ago
I agree with your point, but the snark here is unwarranted (pretty sure the parent isn't even contesting your point) and very likely to derail the otherwise interesting conversation (IMHO).
- Sohcahtoa82 7y ago
  Re-reading the other comment and my response, yeah, you're probably right. Java programmers are a source of frustration for me. I don't write Java professionally, but I do application security which involves reading a lot of Java code. And because the developers are sticking so strictly to the typical Java paradigms, the code is very difficult to read. Testing things locally is a nightmare, since stack traces are a ridiculous stacks of .invoke, as if Java programmers are afraid of directly calling functions. I let my frustration get the better of me and I apologize.
hota_mazi 7y ago
> for some reason, it's considered verboten in Java. It's not just "for some reason". There are plenty of reasons why getters are a superior approach to naked fields, and these have been documented to death for the past twenty years. If your field is not final, you should hide it behind a getter/setter.

nine_k 7y ago

In my opinion, if Go does one thing exactly right, it's the "OOP". That is, interfaces and explicit receiver arguments in functions. Interfaces are extendable, classes are not, because there are no classes per se, let alone abstract classes. Maybe conforming to an interface without explicitly declaring it (like you declare an instance of a typeclass in Haskell) may look like a controversial decision. I still think it does more good by removing boilerplate than bad by accepting an object as conforming to an interface in a rare case when you did not mean it.

throwaway894345 7y ago
I agree with all of this, but Go also has a pretty great standard library, tooling, and deployment story that you're overlooking. Notably, Go's tools are fast (no need to run a daemon because CLIs take too long to start up), there's no imperative DSL for its build system, there's a builtin/standard test runner, there's a standard formatter, documentation is simple and comes out of the box (no special javadoc syntax, just comments above functions; no need to write a CI job to build and publish docs nor a webserver to host them), profiling and benchmarking are builtin. That said, the thing I like about Java is that its JIT compiler and bytecode system allow for efficient metaprogramming; Go's runtime package works, but it's not fast at all. These use cases are few and far between, but it would be nice if Go had a good web framework story (e.g. rails, django, spring, etc). > Maybe conforming to an interface without explicitly declaring it (like you declare an instance of a typeclass in Haskell) may look like a controversial decision. I still think it does more good by removing boilerplate than bad by accepting an object as conforming to an interface in a rare case when you did not mean it. Yeah, I hear this objection pretty frequently, but I've literally never heard of a single instance of this resulting in a real production bug. If it's a rare case, it's vanishingly rare, while it's no exaggeration to say that virtually every project benefits from the advantages.
- nine_k 7y ago
  Go has a brilliant ecosystem, even if it has slight problems still (package vendoring, etc). The language may be lacking here and there, but the tooling around it is good, and the runtime of it is great (sub-ms garbage collection, etc).