23 ms·

For what it's worth I'm a semi-grey beard (20 years in) and I love golang. For me it was like going back to being 8 years old on my Commodore Plus/4 and reall

For what it's worth I'm a semi-grey beard (20 years in) and I love golang. For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. It needs close parenting. Java has been ruined by the push to include everyone's pet feature.

akerro 7y ago
>everyone's pet feature Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.
- th3iedkid 7y ago
  Generics was introduced in Java in 2004 with J2SE 5.0[0]. [0]: https://en.wikipedia.org/wiki/Java_version_history#J2SE_5.0 https://en.wikipedia.org/wiki/Java_version_history#J2SE_5.0
  - LeonidasXIV 7y ago
    The concept of generics/parametric polymorphism has existed decades prior to that in languages like SML and proven to work rather well.
    - raducu 7y ago
      Every time I get to edit pre-java 5 code is a reminder how useful generics actually are.
  - coldtea 7y ago
    Generics should have been in Java (and Go) from the beginning. Those surely are not the proof that Java adds "everybody's favorite feature". I think the parent means the newest Oracle projects (Valhalla, modules, value types, streams, and so on).
    - mcguire 7y ago
      (Technically, I think Java modules have been floating around in weird, likely broken suggestions since before Oracle bought Sun. As far as I could ever see, the primary design constraint was always, "NOT OSGi!")
  - akerro 7y ago
    Generics were added so late because they had to figure out how to do it properly, correctly, on the first time.
    - thechao 7y ago
      Generics in Java are giant hack from the early 2000’s to maintain backwards compatibility with 1990’s-vintage JVMs. C#’s generics we’re done right.
      - eropple 7y ago
        I'm of two minds of that, these days. I came from C# so of course reified generics were of course better, of course--but these days I would rather have them in Java more and in C# less. I often find myself wanting to write the moral equivalent of `IFoo<?>` in C# and end up having to have two separate interfaces, etc. just to have a way to handle a list of a thing that I end up working on in an abstract manner. (Though I'd caveat that that is more of a gamedev-related concern than in Java/Kotlin, which I write for work.) I do appreciate, though, that when Microsoft decided to do generics for C#, they did so decisively. These days, when C# gets a new feature, it seems like it's the complete opposite of decisively delivered.
        jimmaswell 7y ago
        You mean like this, right? class A {}; class A<T> : A {}; I don't mind that. It can even be an aid to organization - all the generic stuff goes in the generic class, all the stuff that doesn't rely on that can go in the base class. But it would be nice to use something like <?>. Too bad generics don't inherit implicit casts, like A<int> to A<object>.
        eropple 7y ago
        I do mean that, and I do mind it a lot when I'm so used to just being able to erase the generic. There are performance implications to type erasure, to be sure, but when our computers are mostly all future machines from beyond the moon, I'm more interested in minimizing the impedance between my brain and a solved problem.
- mieseratte 7y ago
  > It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.
  - read_if_gay_ 7y ago
    >I'll never forgive the addition of `var` to the language. I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?
    - bad_user 7y ago
      Misconceptions mostly. Java developers are some of the most conservative developers around. And there you have the answer to why Java hasn't evolved that much, or when it did, why it needed to care deeply about backwards compatibility at the source level. It's because Java developers want it that way. The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. Therefore I find it interesting when Java developers complain about Var, because the ecosystem has in my opinion bigger problems. Compared with annotations Var isn't a problem because Var is statically checked, so here we have a clear case of missing the forest from the trees.
      - mieseratte 7y ago
        > Java developers are some of the most conservative developers around. You're right, there are loads of conservative Java developers. It's one of the the things that makes me love using the language. > The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. > Misconceptions mostly. But drop the strawman argument and borderline ad hominem. It'll do you better.
- bunderbunder 7y ago
  > Java has only things that were proved to work in other languages. But they still somehow keep finding ways to make them not work so well when implemented in Java. C# may move faster, but its design team is also much more methodical about ensuring that new features have good ergonomics. In Java, I tend to feel surrounded by hacks that were hastily slapped on in an effort to keep up with C# and, increasingly, Kotlin.
  - emn13 7y ago
    Hmm, I do a lot of C# programming, including very language-y low-level stuff, and I'm not sure I completely agree. I appreciate that by moving faster they get more stuff into more hands faster, but they definitely have a lot of hackish solutions with poor ergnomics outside of the narrow scope they were originally intended for. If you will: the language features have a clear purpose but a general implementation; and outside of the narrow purpose the designs usually feel pretty poor. E.g.: - LINQ/expression trees don't support most of the C# language, and new language features are usually without equivalent expression tree. This isn't a full lisp or F# style quotation, but a pretty narrow window that's not easy to use outside of linq-to-sql style usages. - LINQ trees are again intrinsically inefficient, since the expression trees compile not to a statically shared expression, but to a bunch of constructors (i.e. looping over even a medium sized expression is bound to be slow); and they're not equatable, so it takes a lot of effort for a consumer to detect this case leading to overly complex (and hard to reproduce correctly) hacks inside stuff like EF. - LINQ is restricted, but the restrictions are fixed, not customizable. That makes it a poor fit for DSLs, including stuff like Entity Framework, because there are usually lots of expressions your DSL can't support, but there's no way of communicating that to the user. Also, if you use expressions as DSL, you need to follow C# semantics, which isn't trivial; witness gotchas in ORMs surround dealing with null and equality. - lambdas are either delegates or expressions; not both, and this isn't resolved via the normal type system, but by special compiler rules, making it hard to do both, and leading to type inference issues such as that var f = (int a) => a + 1; cannot compile. - Roslyn: very poorly documented, and ironically very dynamically typed to the point that many casts or type-switches are necessary but finding out what types there are and what they do is generally a matter of trial and error since the docs aren't great. Ergonomics are poor in other ways too; e.g. dotnet is xplat, but the build-api is not - i.e. it's clearly not dogfooded. Also: totally not integrated with expression trees, which is at least mildly surprising. - string interpolations are unfortunately quite restrictive (compare with e.g. javascript, where this was implememented much better), and intrinsically and unnecessarily inefficient (at least 2 extra heap allocations, and usually lots of boxing, and the parsing the compiler necessarily must do is not exposed in any kind of object tree, but instead reserialized to string.Format compatible syntax necessitating re-parsing at run-time). Also, like expression trees, this was really hacked into the language, so, e.g. you can't participate in other normal C# features like overload resolution the way you might expect, extension methods plain don't work, culture-sensitivity can be a gotcha: basically this works for immediately evaluated expression, but is tricky elsewhere. - razor (not strictly C#) is hugely complex, and has a very impractical underlying model. Compared with e.g. JSX which is trivial is (ab)use creatively, and which uses mostly language-native constructs for control flow, razor makes it impossible to use even basic features like methods to extract bits of common code; lots of basic programming features are reimplemented differently. Instead of passing a lambda or whatever, you have to deal with vaguely equivalent yet needlessly different stuff like partials + tag helpers. - optional parameters are kind of a mess (no way to enforce named args, no way to cleanly wrap optionals, restriction on compile-time constant, interaction with overloads can be suprising); tuples are too (names are dealt with differently than everything else in the language, no syntax for empty or 1-elem tuples, no way to interpret arg lists as tuples or vice-versa, no checks on nasty naming errors like swapping order); equality is a mess (how many kinds are there again?), lots of apis are disposable but should not be disposed but for others it's critical, no good way to compose disposables, huge ever expanding api without practical deprecation path is a pitfall for newbs, no partial type inference for generics, no unification of all the various func-and-action variations means billions of pointless overloads (and sometimes per-API ways around it); tuples and anonymous objects are sort of redundant, but not entirely; no good way of implementing equality/hashcode/comparability and yet easy way to detect misused non-equatable types. I mean, I respect their choices here, and there's a tradeoff with lots of benefit too: they're really quite fast-moving, and I want those new features ;-). But it's not without costs; they definitely aren't "much more methodical" or anything like that.
- jayd16 7y ago
  C#'s language is much better designed IMO. Can anyone compare LINQ and Java's streams and not pick LINQ? Feels much sloppier in Java and Java came second.
  - akerro 7y ago
    Yes, I personally prefer streams, LINQ seems to me like mixing SQL in C# and that feels wrong.
    - tracker1 7y ago
      I do like all of LINQ's extension methods, but not the syntax myself.
    - jayd16 7y ago
      That's probably what I like most about it. But that aside, the naming of tasks seems much more consistent in C# than Java. Java already had streams and maps and mangling those names makes searching for documentation a pain.
EtienneK 7y ago
"Java has been ruined by the push to include everyone's pet feature." Care to expand on this? Java is very careful to release new features.
- dullgiulio 7y ago
  It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) These different paradigms together make for code that does not read the same no matter who writes it. I love how Go code usually ends up being extremely similar, no matter who write is. (Actually, Kubernetes is a counter example for this: Go should have gone even further in forcing style.) If you think that "all code reads the same" is detrimental to developers, you are conflating the idea of developer (problem solver) to that of coder (keyboard typist.)
  - sgift 7y ago
    > Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) So, by adding a feature which works extremely well with OO and enhances the language they have no soul? That doesn't make any sense. Javas soul is being a blue collar language. It leaves the experiments to other (JVM) languages and takes the parts which have been shown in the field to be useful for many cases. Go on the other hand is a half-finished Java, produced for the sake of saying "We are Google, OF COURSE we have our own language".
    - glangdale 7y ago
      "Java, from Bell Labs"
      - pjmlp 7y ago
        That was Limbo actually, so it goes well with Go.
fnord77 7y ago
semi-grey beard here, too. Disagree about Java - it is stagnating because it hasn't kept pace with language innovation.
- pjmlp 7y ago
  Aka catching up with Common Lisp and Standard ML.
mgoetzke 7y ago
Hey ! Plus/4 ! Finally someone who knows it too :) Since it was missing the C64 sprite abilities it made it even more interesting to code something cool on it. Though at least it could play some games like Ricky Rockman. :)
baby 7y ago
So did the mess that C++ become.
meddlepal 7y ago
> For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. Your comment is the problem with the Go community. I have seen a number of comments from Golangers that they want a "fun" language that helps them reminisce about the past. They also want to write a lot of senseless boilerplate because for them more typing is somehow about them reliving their past. And tracking down nil pointers... and writing containers for every concrete type. The simple fact is software development has gotten more complex because business requirements have changed and Go does a poor job of addressing that with its limited feature set. The rest of the programming world has accepted that we need better tools whether it be toolchain stuff or language features. Hate on Java all you want but at least it, like most other non-Go languages, has realized the need for better tools in the toolbox.
- xyzzy_plugh 7y ago
  > we need better tools Sure, and the "right tool for the right job" is still my mantra. Go is a very good at solving for an incredible amount of tasks in many problem spaces. Users will always want to bend tools to work in new places, and that's okay -- sometimes it isn't a fit. Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements.
  - meddlepal 7y ago
    > Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements. That's such a cop out answer when our industry is basically doing fad-oriented engineering. It's great when you can greenfield build a project but when you're taking over a project the selection of language has usually been decided. Or you know the management team has decided for hirability reasons to use X. Or just legacy requirements don't match reality eventually. This is why we need more expressive languages than Go. Requirements change over the course of a projects life and what made sense in year 1 rarely makes sense several years later.

akerro 7y ago

>everyone's pet feature Isn't that C#? Java is very slow at adding new features, Java has only things that were proved to work in other languages.

th3iedkid 7y ago
Generics was introduced in Java in 2004 with J2SE 5.0[0]. [0]: https://en.wikipedia.org/wiki/Java_version_history#J2SE_5.0 https://en.wikipedia.org/wiki/Java_version_history#J2SE_5.0
- LeonidasXIV 7y ago
  The concept of generics/parametric polymorphism has existed decades prior to that in languages like SML and proven to work rather well.
  - raducu 7y ago
    Every time I get to edit pre-java 5 code is a reminder how useful generics actually are.
- coldtea 7y ago
  Generics should have been in Java (and Go) from the beginning. Those surely are not the proof that Java adds "everybody's favorite feature". I think the parent means the newest Oracle projects (Valhalla, modules, value types, streams, and so on).
  - mcguire 7y ago
    (Technically, I think Java modules have been floating around in weird, likely broken suggestions since before Oracle bought Sun. As far as I could ever see, the primary design constraint was always, "NOT OSGi!")
- akerro 7y ago
  Generics were added so late because they had to figure out how to do it properly, correctly, on the first time.
  - thechao 7y ago
    Generics in Java are giant hack from the early 2000’s to maintain backwards compatibility with 1990’s-vintage JVMs. C#’s generics we’re done right.
    - eropple 7y ago
      I'm of two minds of that, these days. I came from C# so of course reified generics were of course better, of course--but these days I would rather have them in Java more and in C# less. I often find myself wanting to write the moral equivalent of `IFoo<?>` in C# and end up having to have two separate interfaces, etc. just to have a way to handle a list of a thing that I end up working on in an abstract manner. (Though I'd caveat that that is more of a gamedev-related concern than in Java/Kotlin, which I write for work.) I do appreciate, though, that when Microsoft decided to do generics for C#, they did so decisively. These days, when C# gets a new feature, it seems like it's the complete opposite of decisively delivered.
      - jimmaswell 7y ago
        You mean like this, right? class A {}; class A<T> : A {}; I don't mind that. It can even be an aid to organization - all the generic stuff goes in the generic class, all the stuff that doesn't rely on that can go in the base class. But it would be nice to use something like <?>. Too bad generics don't inherit implicit casts, like A<int> to A<object>.
        eropple 7y ago
        I do mean that, and I do mind it a lot when I'm so used to just being able to erase the generic. There are performance implications to type erasure, to be sure, but when our computers are mostly all future machines from beyond the moon, I'm more interested in minimizing the impedance between my brain and a solved problem.
mieseratte 7y ago
> It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.
- read_if_gay_ 7y ago
  >I'll never forgive the addition of `var` to the language. I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?
  - bad_user 7y ago
    Misconceptions mostly. Java developers are some of the most conservative developers around. And there you have the answer to why Java hasn't evolved that much, or when it did, why it needed to care deeply about backwards compatibility at the source level. It's because Java developers want it that way. The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. Therefore I find it interesting when Java developers complain about Var, because the ecosystem has in my opinion bigger problems. Compared with annotations Var isn't a problem because Var is statically checked, so here we have a clear case of missing the forest from the trees.
    - mieseratte 7y ago
      > Java developers are some of the most conservative developers around. You're right, there are loads of conservative Java developers. It's one of the the things that makes me love using the language. > The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. > Misconceptions mostly. But drop the strawman argument and borderline ad hominem. It'll do you better.
bunderbunder 7y ago
> Java has only things that were proved to work in other languages. But they still somehow keep finding ways to make them not work so well when implemented in Java. C# may move faster, but its design team is also much more methodical about ensuring that new features have good ergonomics. In Java, I tend to feel surrounded by hacks that were hastily slapped on in an effort to keep up with C# and, increasingly, Kotlin.
- emn13 7y ago
  Hmm, I do a lot of C# programming, including very language-y low-level stuff, and I'm not sure I completely agree. I appreciate that by moving faster they get more stuff into more hands faster, but they definitely have a lot of hackish solutions with poor ergnomics outside of the narrow scope they were originally intended for. If you will: the language features have a clear purpose but a general implementation; and outside of the narrow purpose the designs usually feel pretty poor. E.g.: - LINQ/expression trees don't support most of the C# language, and new language features are usually without equivalent expression tree. This isn't a full lisp or F# style quotation, but a pretty narrow window that's not easy to use outside of linq-to-sql style usages. - LINQ trees are again intrinsically inefficient, since the expression trees compile not to a statically shared expression, but to a bunch of constructors (i.e. looping over even a medium sized expression is bound to be slow); and they're not equatable, so it takes a lot of effort for a consumer to detect this case leading to overly complex (and hard to reproduce correctly) hacks inside stuff like EF. - LINQ is restricted, but the restrictions are fixed, not customizable. That makes it a poor fit for DSLs, including stuff like Entity Framework, because there are usually lots of expressions your DSL can't support, but there's no way of communicating that to the user. Also, if you use expressions as DSL, you need to follow C# semantics, which isn't trivial; witness gotchas in ORMs surround dealing with null and equality. - lambdas are either delegates or expressions; not both, and this isn't resolved via the normal type system, but by special compiler rules, making it hard to do both, and leading to type inference issues such as that var f = (int a) => a + 1; cannot compile. - Roslyn: very poorly documented, and ironically very dynamically typed to the point that many casts or type-switches are necessary but finding out what types there are and what they do is generally a matter of trial and error since the docs aren't great. Ergonomics are poor in other ways too; e.g. dotnet is xplat, but the build-api is not - i.e. it's clearly not dogfooded. Also: totally not integrated with expression trees, which is at least mildly surprising. - string interpolations are unfortunately quite restrictive (compare with e.g. javascript, where this was implememented much better), and intrinsically and unnecessarily inefficient (at least 2 extra heap allocations, and usually lots of boxing, and the parsing the compiler necessarily must do is not exposed in any kind of object tree, but instead reserialized to string.Format compatible syntax necessitating re-parsing at run-time). Also, like expression trees, this was really hacked into the language, so, e.g. you can't participate in other normal C# features like overload resolution the way you might expect, extension methods plain don't work, culture-sensitivity can be a gotcha: basically this works for immediately evaluated expression, but is tricky elsewhere. - razor (not strictly C#) is hugely complex, and has a very impractical underlying model. Compared with e.g. JSX which is trivial is (ab)use creatively, and which uses mostly language-native constructs for control flow, razor makes it impossible to use even basic features like methods to extract bits of common code; lots of basic programming features are reimplemented differently. Instead of passing a lambda or whatever, you have to deal with vaguely equivalent yet needlessly different stuff like partials + tag helpers. - optional parameters are kind of a mess (no way to enforce named args, no way to cleanly wrap optionals, restriction on compile-time constant, interaction with overloads can be suprising); tuples are too (names are dealt with differently than everything else in the language, no syntax for empty or 1-elem tuples, no way to interpret arg lists as tuples or vice-versa, no checks on nasty naming errors like swapping order); equality is a mess (how many kinds are there again?), lots of apis are disposable but should not be disposed but for others it's critical, no good way to compose disposables, huge ever expanding api without practical deprecation path is a pitfall for newbs, no partial type inference for generics, no unification of all the various func-and-action variations means billions of pointless overloads (and sometimes per-API ways around it); tuples and anonymous objects are sort of redundant, but not entirely; no good way of implementing equality/hashcode/comparability and yet easy way to detect misused non-equatable types. I mean, I respect their choices here, and there's a tradeoff with lots of benefit too: they're really quite fast-moving, and I want those new features ;-). But it's not without costs; they definitely aren't "much more methodical" or anything like that.
jayd16 7y ago
C#'s language is much better designed IMO. Can anyone compare LINQ and Java's streams and not pick LINQ? Feels much sloppier in Java and Java came second.
- akerro 7y ago
  Yes, I personally prefer streams, LINQ seems to me like mixing SQL in C# and that feels wrong.
  - tracker1 7y ago
    I do like all of LINQ's extension methods, but not the syntax myself.
  - jayd16 7y ago
    That's probably what I like most about it. But that aside, the naming of tasks seems much more consistent in C# than Java. Java already had streams and maps and mangling those names makes searching for documentation a pain.

EtienneK 7y ago

"Java has been ruined by the push to include everyone's pet feature." Care to expand on this? Java is very careful to release new features.

dullgiulio 7y ago
It's not about being careful (they are--but always with the baggage of backwards compatibility), it's about not having a soul. Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) These different paradigms together make for code that does not read the same no matter who writes it. I love how Go code usually ends up being extremely similar, no matter who write is. (Actually, Kubernetes is a counter example for this: Go should have gone even further in forcing style.) If you think that "all code reads the same" is detrimental to developers, you are conflating the idea of developer (problem solver) to that of coder (keyboard typist.)
- sgift 7y ago
  > Java has made a U-turn in adding streams and related functional features on top of a language that used to be strongly for OOP (actually defining the meaning of OOP for a generation of developers.) So, by adding a feature which works extremely well with OO and enhances the language they have no soul? That doesn't make any sense. Javas soul is being a blue collar language. It leaves the experiments to other (JVM) languages and takes the parts which have been shown in the field to be useful for many cases. Go on the other hand is a half-finished Java, produced for the sake of saying "We are Google, OF COURSE we have our own language".
  - glangdale 7y ago
    "Java, from Bell Labs"
    - pjmlp 7y ago
      That was Limbo actually, so it goes well with Go.

fnord77 7y ago

semi-grey beard here, too. Disagree about Java - it is stagnating because it hasn't kept pace with language innovation.

pjmlp 7y ago
Aka catching up with Common Lisp and Standard ML.

mgoetzke 7y ago

Hey ! Plus/4 ! Finally someone who knows it too :) Since it was missing the C64 sprite abilities it made it even more interesting to code something cool on it. Though at least it could play some games like Ricky Rockman. :)

baby 7y ago

So did the mess that C++ become.

meddlepal 7y ago

> For me it was like going back to being 8 years old on my Commodore Plus/4 and really enjoying writing code again. Your comment is the problem with the Go community. I have seen a number of comments from Golangers that they want a "fun" language that helps them reminisce about the past. They also want to write a lot of senseless boilerplate because for them more typing is somehow about them reliving their past. And tracking down nil pointers... and writing containers for every concrete type. The simple fact is software development has gotten more complex because business requirements have changed and Go does a poor job of addressing that with its limited feature set. The rest of the programming world has accepted that we need better tools whether it be toolchain stuff or language features. Hate on Java all you want but at least it, like most other non-Go languages, has realized the need for better tools in the toolbox.

xyzzy_plugh 7y ago
> we need better tools Sure, and the "right tool for the right job" is still my mantra. Go is a very good at solving for an incredible amount of tasks in many problem spaces. Users will always want to bend tools to work in new places, and that's okay -- sometimes it isn't a fit. Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements.
- meddlepal 7y ago
  > Have some business requirements that make using Go a chore or a pain? Use a different language, or restructure the requirements. That's such a cop out answer when our industry is basically doing fad-oriented engineering. It's great when you can greenfield build a project but when you're taking over a project the selection of language has usually been decided. Or you know the management team has decided for hirability reasons to use X. Or just legacy requirements don't match reality eventually. This is why we need more expressive languages than Go. Requirements change over the course of a projects life and what made sense in year 1 rarely makes sense several years later.