4 ms·

It is easier to know that lowercase is package-specific, uppercase is exported, than knowing which field is private/public by default. Go reserved keywords: br

by adezxc 3y ago

It is easier to know that lowercase is package-specific, uppercase is exported, than knowing which field is private/public by default. Go reserved keywords: break, default, func, interface, select, case, defer, go, map, struct, chan, else, goto, package, switch, const, fallthrough, if, range, type, continue, for, import, return, var Java reserved keywords: abstract, continue, for, new, switch, assert, default, goto*, package, synchronized, boolean, do, if, private, this, break, double, implements, protected, throw, byte, else, import, public, throws, case, enum, instanceof, return, transient, catch, extends, int, short, try, char, final, interface, static, void, class, finally, long, strictfp, volatile, const, float, native, super, while.

kaba0 3y ago
You have conveniently left out types from go’s list.. with those removed it is hardly longer, and as has been shown (case-sensitive identifiers), not all language complexity lives within keywords.
- adezxc 3y ago
  https://go.dev/play/p/71I57QCycTr https://go.dev/play/p/71I57QCycTr This works, so how exactly did I leave them out?
- preseinger 3y ago
  the parent's point was to compare the set of reserved keywords in the two languages types do not enter the discussion
  - kaba0 3y ago
    They do if 1/3 of java’s keywords are there due to types.
    - preseinger 3y ago
      some keywords are types, but not all types are keywords, right? like, it's not as if the go type `float64` is also a go keyword but i guess the java type `byte` is a java keyword? according to https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...
za3faran 3y ago
This is why you can do const true = false in golang The number of reserved keywords is not a bad thing. For example, I constantly missed `final` when I worked in golang. Just because a keyword doesn't exist does not make its usecase disappear. Same with other features like `enum` (extremely useful) and visibility rules. golang only has package private and public, not nearly as granular as one needs in practice, not to mention generating large CL's when changing the visibility rules of a function, as opposed to simply having a 1 line change. Sure you can ignore those use cases, but it doesn't mean that their usefulness disappears.
- adezxc 3y ago
  > The number of reserved keywords is not a bad thing. I'm not saying reserved keywords are bad. I'm saying there's much more to learn about Java to learn programming, Go is limited with its' keywords and 'features', which often results in more LoC, but makes it super easy to get going, run into general programming problems like using a variable instead of a reference to it, etc. In Java, you spend much more time learning the features of the language itself, even simple things like (s)Strings are not easy to understand, then add classes, inheritance, UTF-16, adding other libraries, build tools, JUnit and many, many other things that are given to you with Go.
  - za3faran 3y ago
    When I had to learn golang, picking up the syntax was easy, but it has many gotchas that you end up having to spend time to learn them anyway, which don't exist in Java (e.g. the Java compiler requires final or effectively final vars to be passed into lambdas, golang happily complies ending up with race conditions). I don't see why learning language features is an issue. The language offers features to provide more correct and more expressive code. golang does not solve the variable vs reference issue at all by the way, and in fact, introduces weird edge cases, such as nil interface not being equal to nil. Why do you say Strings not easy to understand?
  - erik_seaberg 3y ago
    We should optimize for clear and concise code between experts. You’re going to be an expert for most of your career, and that’s when your time has the greatest value. A small learning curve is bad because you quickly run out of ways for tools to help you. I want to use the most powerful language I possibly can; the time investment pays off.

by adezxc 3y ago

kaba0 3y ago

You have conveniently left out types from go’s list.. with those removed it is hardly longer, and as has been shown (case-sensitive identifiers), not all language complexity lives within keywords.

adezxc 3y ago
https://go.dev/play/p/71I57QCycTr https://go.dev/play/p/71I57QCycTr This works, so how exactly did I leave them out?
preseinger 3y ago
the parent's point was to compare the set of reserved keywords in the two languages types do not enter the discussion
- kaba0 3y ago
  They do if 1/3 of java’s keywords are there due to types.
  - preseinger 3y ago
    some keywords are types, but not all types are keywords, right? like, it's not as if the go type `float64` is also a go keyword but i guess the java type `byte` is a java keyword? according to https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_keywords.html https://docs.oracle.com/javase/tutorial/java/nutsandbolts/_k...

za3faran 3y ago

This is why you can do const true = false in golang The number of reserved keywords is not a bad thing. For example, I constantly missed `final` when I worked in golang. Just because a keyword doesn't exist does not make its usecase disappear. Same with other features like `enum` (extremely useful) and visibility rules. golang only has package private and public, not nearly as granular as one needs in practice, not to mention generating large CL's when changing the visibility rules of a function, as opposed to simply having a 1 line change. Sure you can ignore those use cases, but it doesn't mean that their usefulness disappears.

adezxc 3y ago
> The number of reserved keywords is not a bad thing. I'm not saying reserved keywords are bad. I'm saying there's much more to learn about Java to learn programming, Go is limited with its' keywords and 'features', which often results in more LoC, but makes it super easy to get going, run into general programming problems like using a variable instead of a reference to it, etc. In Java, you spend much more time learning the features of the language itself, even simple things like (s)Strings are not easy to understand, then add classes, inheritance, UTF-16, adding other libraries, build tools, JUnit and many, many other things that are given to you with Go.
- za3faran 3y ago
  When I had to learn golang, picking up the syntax was easy, but it has many gotchas that you end up having to spend time to learn them anyway, which don't exist in Java (e.g. the Java compiler requires final or effectively final vars to be passed into lambdas, golang happily complies ending up with race conditions). I don't see why learning language features is an issue. The language offers features to provide more correct and more expressive code. golang does not solve the variable vs reference issue at all by the way, and in fact, introduces weird edge cases, such as nil interface not being equal to nil. Why do you say Strings not easy to understand?
- erik_seaberg 3y ago
  We should optimize for clear and concise code between experts. You’re going to be an expert for most of your career, and that’s when your time has the greatest value. A small learning curve is bad because you quickly run out of ways for tools to help you. I want to use the most powerful language I possibly can; the time investment pays off.