7 ms·

I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younge

by yanilkr 10y ago

I once tried to convince an enterprise java developer to give golang a try. The guy passionately hated it and the reasons were very very petty. The other younger engineers who did not have prior bias loved golang and they were productive so fast. The person truly had a java supremacy attitude that was very difficult to deal with. Golang is a kind of shift in thinking that you have to first unlearn your existing ways of thinking and then you will have a place for it. Some people are not willing to take that leap of faith unfortunately.

kmiroslav 10y ago
That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.
- yanilkr 10y ago
  This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.
  - kmiroslav 10y ago
    > There is no universal best language nor there will ever be the one. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones.
    - yanilkr 10y ago
      javascript and python would disagree with you.
      - gagege 10y ago
        A lot of people are perfectly happy if Javascript and Python disagree with them.
      - Jtsummers 10y ago
        Parent's claim: Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones. Your response: javascript and python would disagree with you. My question: How so? Since the claim is about the advantages of static type systems, I'll respond on that claim alone. The primary advantage of static type systems, particularly expressive ones, but even of less expressive ones like C, is that a large class of errors can never occur in run-time code. You cannot, possibly, without deliberate effort to defeat the type checker do the following in a statically typed language without at least a compile time warning (to permit C and its weak type system and occasional implicit casting): Define a function in your language of type: int -> int -> int [or (int, int) -> int]. Pass in something that is not an int to either parameter. Python will happily accept this code: def add(a,b): a + b ... some context add("aoeu", 3) And not tell you until that add call occurs. A run-time error. Could be very infrequent, which makes it really hard to reproduce. In C: int add(int a, int b) { return a+b; } ... some context add("aoeu",3); the add call won't even make it past the compiler. JavaScript is even worse: You won't get an error at all! function add(a,b) { return a + b; } ... some context add("aoeu",3) // results in "aoeu3" as the return! Dynamic and weak typing! This doesn't mean python and javascript are bad. But it does mean they possess disadvantages relative to statically typed languages. Their type systems mean that significant testing has to be put in to verify/validate your program for guarantees that are baked into statically typed languages (caveat for implicit conversions of certain types, again, in languages like C, but this usually gets at least a warning if not an error).
        yanilkr 10y ago
  - jdmichal 10y ago
    > Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. I find the opposite for practical arts: The better the practitioner, the more reliable their tools must be, not less. A beginner painter might not be able to point out a bad brush from a good one; a master absolutely will. Furthermore, a bad brush won't necessarily hinder a beginner painter, but it will absolutely hinder a master painter. There are simply some techniques that the master will not be able to execute unless the brush is of a good enough quality.
  - rdtsc 10y ago
    > There is no universal best language nor there will ever be the one. But there are better languages for some task than others. Having a better type systems suites many types of tasks and environments. So making that observation seems rather rational.
  - kmiroslav 10y ago
    > If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. That's a flawed analogy. Here is a better one: If you need to drill something, do you consider a screwdriver and an electric drill equally?
    - elbear 10y ago
      I don't agree with this analogy, because languages overlap a lot more. You could choose one of several different languages to build a web app (Python, JavaScript, Ruby, PHP, etc.). Only particular tasks have languages that fit best. Many other tasks can be solved in multiple languages. In that case, the best tool for the job is the language you know best.
kmiroslav 10y ago
> you have to first unlearn your existing ways of thinking and then you will have a place for it. Unlearning is not always acceptable, especially when you have to unlearn sound and proven practices, which Go often requires to do. I think it really depends where you're coming from: people coming from dynamically typed languages like Python and Ruby are quite happy with Go since it's a small ramp up on the type ladder, but anyone who's used to static types and generics will usually see Go as a step back and refuse to take that step (for good reasons in my opinion). To draw an analogy, imagine a Go developer is being asked to switch to Python and in order to convince them, you tell them they just need to unlearn a few things. To them, you are asking them to give up types and other practices that makes their code more robust, so it's not an acceptable argument.
- yanilkr 10y ago
  The good programmers I know are not attached to their tools. They prefer to use the right tool for the job. Many other programmers want to solve the problems using tools they know. There is nothing wrong with that. A company with good programmers who could do similar things more efficiently will add to competitive advantage.
  - kmiroslav 10y ago
    Again, we all agree about the motto. If you need to screw something and you have a choice between 1. A screwdriver 2. Electric drill A 3. Electric drill B you will certainly look funny at someone considering the screwdriver over the alternatives. Someone who automatically narrows this choice between the two electric drills is not "attached to their tools", as you say. They are just picking the better tool.
    - vertex-four 10y ago
      So as someone who's written some Go, I'd argue that Go is the screwdriver - it's one of the only modern languages which explicitly refuses to tackle the error handling problem, which has resulted in some of my code being more about the failure case than the success case. Of course, others will disagree - fine. But to argue that e.g. Java is definitely the screwdriver is a subjective judgement.
kasey_junk 10y ago
I program go full time and have for a couple of years. My biggest complaint about it is that there is some magical shift in thinking required to use it. The only shift I've found is moving on when the Golang way isn't as good as other tools you are used to. Because the ecosystem & language really are not on par with other environments I've worked in.
- eropple 10y ago
  Agreed--the culture always strikes me as a weird one and, having just had to dip back into Go for a project recently, your observations ring really true. I feel like there is a strong sense of epistemic closure around Go advocates (as separate from the Go team, I've had interesting and good conversations with a couple) that lead to contortions like "magical shifts of thinking" rather than an acceptance of problems and a desire to fix them. The advantages of a tool that is unmistakably disadvantaged in some areas (like Go's not-great ecosystem and relatively weak expressiveness compared to many of its competitors) may outweigh those disadvantages, but the amount of aggressive you-don't-need-thatting and the insistence that the emperor has the finest clothes is...weird.
Lewisham 10y ago
Bad programmers are always going to be bad programmers, no matter what their age. Bad programmers are inflexible and unadaptable; unable to keep up with new languages or idioms. Ken Thompson is about as old school as they come and he wrote much of Go.
- airless_bar 10y ago
  I think dismissing anything invented after 1960/not invented at Google counts as "inflexible and unadaptable; unable to keep up with new languages or idioms".
  - weberc2 10y ago
    Many folks come to Go from "modern" languages, Python and Java in particular. I don't think this can be considered "dismissing".
    - airless_bar 10y ago
      I don't think anyone considers Python or Java modern. Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years.
      - weberc2 10y ago
        > I don't think anyone considers Python or Java modern. This is why I put "modern" in quotes; these languages are "modern" relative to the 1960s-era languages. > Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years. Precisely. The OP implied that Go programmers are "bad programmers" because they can't adapt to post-1960s languages. I countered his hypothesis by pointing out that the lion's share of Go developers were previously competent Python, Ruby, JavaScript, or Java developers. If his hypothesis were correct, one would expect the Go community to be primarily C expats. For whatever reason, a large swath of developers find the features Go adds to be more useful than the "advancements" Go omits (or perhaps they just find value in the omission of those "advancements" altogether). At any rate, Go's popularity can't be reasonably attributed to graybeard developers who can't grok Java.
Zergy 10y ago
I've been running into this phenomenon a lot and its not isolated to java developers. We recently had a class on Clojure 101 and the main audience was Obj-C/Swift developers. A lot of the developers went into the class actively trying to prove Clojure was dumb and the way they were doing it was better. I think any language one it reaches a critical mass attracts people who are not problem solvers but memorizers. There is a correlation between people who rely on copy pasting existing code and SO answers and people heavily invested in their language. Point being most people who have trouble adopting other languages tend to be memorizers vs problem solvers and become insecure when working in a poorly defined environment. Pulling them into something new after others have solved the hard problems and created best practices tends to be easier and more productive for everybody.
readams 10y ago
This is because using Go feels very much like going back in time to Java 4.
- Matthias247 10y ago
  Not necessarily. I think by providing native slice and map types Go reduces the need for generics already by a large margin. Other things that often use generics (higher order functions, future types, ...) are no idiomatic Go which leans more to the imperative way of doing things. In total I have not really missed generics in Go up to now (but I have up to now only written about 20kloc in it) - while I certainly missed them in early Java and C# versions.
  - readams 10y ago
    As long as your needs are sufficiently basic that you never need to create data structures then what's in Go can be ok. People who are fans of Go seem to be people who don't know what they're missing in more advanced languages. This seems to include C programmers and dynamic language programmers. Programmers used to better type systems are generally not happy with Go.
    - mratzloff 10y ago
      This comment is patronizing and implies that liking Go makes someone a "junior varsity" programmer, or ignorant of alternative programming models. It doesn't. I'm well-versed in half a dozen other languages, many of which include generics. I like Go just fine. Yes, there are cases where it is not the best choice. That's fine, too. How much Go have you written, out of curiosity?
      - idobai 10y ago
        > This comment is patronizing and implies that liking Go makes someone a "junior varsity" programmer, or ignorant of alternative programming models. Because that's the truth and that was intentional at its design. > I'm well-versed in half a dozen other languages, many of which include generics. It depends in which languages.
Chris2048 10y ago
Consider there may be an existential bias - people who are open to new languages are more likely to move away from Java.
takeda 10y ago
IMO switching an enterprise developer from language such as Java to Go is like asking someone who has very developed vocabulary in English to try Toki Pona[1]. Yes, it is simple, and you can learn it fast, you also can also communicate with it, but you will often have to fight with the language to express what you want. That person generally won't be satisfied. Go's shortcomings wouldn't be so bad if in exchange, the language would ensure that your code is less prone to errors, but that doesn't seem to be true. In fact Go programs from my experience appear to be slightly below average in terms of stability and robustness compared to other statically typed languages. [1] https://en.wikipedia.org/wiki/Toki_Pona https://en.wikipedia.org/wiki/Toki_Pona
- yanilkr 10y ago
  Your opinion on this is couple of standard deviations away from popular one. Is there a specific example where a program written in golang lacked compared to other statically typed languages?
  - takeda 10y ago
    Well, it's small sample but I used things like InfluxDB, Consul, there were some command line tools (that I no longer remember) as well.
- weberc2 10y ago
  Your analogy seems weak at best. Go is mostly a subset of Java, so there's almost no difficulty in a Java developer learning Go. A Java developer can immediately read 90% of Go programs, and within a couple of hours, he can write real, interesting programs. I'm not sure that a good analogy could be made incorporating English, nor do I think there's value in doing so.
  - takeda 10y ago
    I don't think you understood my analogy. Go supposed to be Toki Pona. I'm saying that once you are used to a language that's more powerful you feel constrained. I know many languages and some bring interesting things to the table, go doesn't really deliver (at least based on the hype). The concurrency supposed to be the killer feature, but it is limited to specific cases. BTW: The Go is not subset of Java if anything it's very similar to Algol-68 (http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/)

by yanilkr 10y ago

kmiroslav 10y ago

That's odd. I think the absence of generics in Go is a reasonable answer for a JVM developer to justify they are not interested. No need to go petty.

yanilkr 10y ago
This feeds into language supremacy mindset. There is no universal best language nor there will ever be the one. Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers.
- kmiroslav 10y ago
  > There is no universal best language nor there will ever be the one. I never made that claim, I just emphasized the widely accepted fact that having types is better than not having them. To a Java developer, Go feels like the Java of ten years ago in that respect, so you will encounter some justified push back. > Right tool for the job is a better flexible mindset Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones.
  - yanilkr 10y ago
    javascript and python would disagree with you.
    - gagege 10y ago
      A lot of people are perfectly happy if Javascript and Python disagree with them.
    - Jtsummers 10y ago
      Parent's claim: Of course, but not all tools are equal. In programming languages, languages that have a static type system have an insurmountable advantage of dynamically typed ones. Your response: javascript and python would disagree with you. My question: How so? Since the claim is about the advantages of static type systems, I'll respond on that claim alone. The primary advantage of static type systems, particularly expressive ones, but even of less expressive ones like C, is that a large class of errors can never occur in run-time code. You cannot, possibly, without deliberate effort to defeat the type checker do the following in a statically typed language without at least a compile time warning (to permit C and its weak type system and occasional implicit casting): Define a function in your language of type: int -> int -> int [or (int, int) -> int]. Pass in something that is not an int to either parameter. Python will happily accept this code: def add(a,b): a + b ... some context add("aoeu", 3) And not tell you until that add call occurs. A run-time error. Could be very infrequent, which makes it really hard to reproduce. In C: int add(int a, int b) { return a+b; } ... some context add("aoeu",3); the add call won't even make it past the compiler. JavaScript is even worse: You won't get an error at all! function add(a,b) { return a + b; } ... some context add("aoeu",3) // results in "aoeu3" as the return! Dynamic and weak typing! This doesn't mean python and javascript are bad. But it does mean they possess disadvantages relative to statically typed languages. Their type systems mean that significant testing has to be put in to verify/validate your program for guarantees that are baked into statically typed languages (caveat for implicit conversions of certain types, again, in languages like C, but this usually gets at least a warning if not an error).
      - yanilkr 10y ago
- jdmichal 10y ago
  > Right tool for the job is a better flexible mindset. If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. I find the opposite for practical arts: The better the practitioner, the more reliable their tools must be, not less. A beginner painter might not be able to point out a bad brush from a good one; a master absolutely will. Furthermore, a bad brush won't necessarily hinder a beginner painter, but it will absolutely hinder a master painter. There are simply some techniques that the master will not be able to execute unless the brush is of a good enough quality.
- rdtsc 10y ago
  > There is no universal best language nor there will ever be the one. But there are better languages for some task than others. Having a better type systems suites many types of tasks and environments. So making that observation seems rather rational.
- kmiroslav 10y ago
  > If you are a master painter, you could paint something amazing with anything you have got. Same thing applies to programmers. That's a flawed analogy. Here is a better one: If you need to drill something, do you consider a screwdriver and an electric drill equally?
  - elbear 10y ago
    I don't agree with this analogy, because languages overlap a lot more. You could choose one of several different languages to build a web app (Python, JavaScript, Ruby, PHP, etc.). Only particular tasks have languages that fit best. Many other tasks can be solved in multiple languages. In that case, the best tool for the job is the language you know best.

kmiroslav 10y ago

> you have to first unlearn your existing ways of thinking and then you will have a place for it. Unlearning is not always acceptable, especially when you have to unlearn sound and proven practices, which Go often requires to do. I think it really depends where you're coming from: people coming from dynamically typed languages like Python and Ruby are quite happy with Go since it's a small ramp up on the type ladder, but anyone who's used to static types and generics will usually see Go as a step back and refuse to take that step (for good reasons in my opinion). To draw an analogy, imagine a Go developer is being asked to switch to Python and in order to convince them, you tell them they just need to unlearn a few things. To them, you are asking them to give up types and other practices that makes their code more robust, so it's not an acceptable argument.

yanilkr 10y ago
The good programmers I know are not attached to their tools. They prefer to use the right tool for the job. Many other programmers want to solve the problems using tools they know. There is nothing wrong with that. A company with good programmers who could do similar things more efficiently will add to competitive advantage.
- kmiroslav 10y ago
  Again, we all agree about the motto. If you need to screw something and you have a choice between 1. A screwdriver 2. Electric drill A 3. Electric drill B you will certainly look funny at someone considering the screwdriver over the alternatives. Someone who automatically narrows this choice between the two electric drills is not "attached to their tools", as you say. They are just picking the better tool.
  - vertex-four 10y ago
    So as someone who's written some Go, I'd argue that Go is the screwdriver - it's one of the only modern languages which explicitly refuses to tackle the error handling problem, which has resulted in some of my code being more about the failure case than the success case. Of course, others will disagree - fine. But to argue that e.g. Java is definitely the screwdriver is a subjective judgement.

kasey_junk 10y ago

I program go full time and have for a couple of years. My biggest complaint about it is that there is some magical shift in thinking required to use it. The only shift I've found is moving on when the Golang way isn't as good as other tools you are used to. Because the ecosystem & language really are not on par with other environments I've worked in.

eropple 10y ago
Agreed--the culture always strikes me as a weird one and, having just had to dip back into Go for a project recently, your observations ring really true. I feel like there is a strong sense of epistemic closure around Go advocates (as separate from the Go team, I've had interesting and good conversations with a couple) that lead to contortions like "magical shifts of thinking" rather than an acceptance of problems and a desire to fix them. The advantages of a tool that is unmistakably disadvantaged in some areas (like Go's not-great ecosystem and relatively weak expressiveness compared to many of its competitors) may outweigh those disadvantages, but the amount of aggressive you-don't-need-thatting and the insistence that the emperor has the finest clothes is...weird.

Lewisham 10y ago

Bad programmers are always going to be bad programmers, no matter what their age. Bad programmers are inflexible and unadaptable; unable to keep up with new languages or idioms. Ken Thompson is about as old school as they come and he wrote much of Go.

airless_bar 10y ago
I think dismissing anything invented after 1960/not invented at Google counts as "inflexible and unadaptable; unable to keep up with new languages or idioms".
- weberc2 10y ago
  Many folks come to Go from "modern" languages, Python and Java in particular. I don't think this can be considered "dismissing".
  - airless_bar 10y ago
    I don't think anyone considers Python or Java modern. Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years.
    - weberc2 10y ago
      > I don't think anyone considers Python or Java modern. This is why I put "modern" in quotes; these languages are "modern" relative to the 1960s-era languages. > Nevertheless, this isn't about where adoption comes from, it's about how the language design was influenced by the advancements in language design in the last 40 years. Precisely. The OP implied that Go programmers are "bad programmers" because they can't adapt to post-1960s languages. I countered his hypothesis by pointing out that the lion's share of Go developers were previously competent Python, Ruby, JavaScript, or Java developers. If his hypothesis were correct, one would expect the Go community to be primarily C expats. For whatever reason, a large swath of developers find the features Go adds to be more useful than the "advancements" Go omits (or perhaps they just find value in the omission of those "advancements" altogether). At any rate, Go's popularity can't be reasonably attributed to graybeard developers who can't grok Java.

Zergy 10y ago

I've been running into this phenomenon a lot and its not isolated to java developers. We recently had a class on Clojure 101 and the main audience was Obj-C/Swift developers. A lot of the developers went into the class actively trying to prove Clojure was dumb and the way they were doing it was better. I think any language one it reaches a critical mass attracts people who are not problem solvers but memorizers. There is a correlation between people who rely on copy pasting existing code and SO answers and people heavily invested in their language. Point being most people who have trouble adopting other languages tend to be memorizers vs problem solvers and become insecure when working in a poorly defined environment. Pulling them into something new after others have solved the hard problems and created best practices tends to be easier and more productive for everybody.

readams 10y ago

This is because using Go feels very much like going back in time to Java 4.

Matthias247 10y ago
Not necessarily. I think by providing native slice and map types Go reduces the need for generics already by a large margin. Other things that often use generics (higher order functions, future types, ...) are no idiomatic Go which leans more to the imperative way of doing things. In total I have not really missed generics in Go up to now (but I have up to now only written about 20kloc in it) - while I certainly missed them in early Java and C# versions.
- readams 10y ago
  As long as your needs are sufficiently basic that you never need to create data structures then what's in Go can be ok. People who are fans of Go seem to be people who don't know what they're missing in more advanced languages. This seems to include C programmers and dynamic language programmers. Programmers used to better type systems are generally not happy with Go.
  - mratzloff 10y ago
    This comment is patronizing and implies that liking Go makes someone a "junior varsity" programmer, or ignorant of alternative programming models. It doesn't. I'm well-versed in half a dozen other languages, many of which include generics. I like Go just fine. Yes, there are cases where it is not the best choice. That's fine, too. How much Go have you written, out of curiosity?
    - idobai 10y ago
      > This comment is patronizing and implies that liking Go makes someone a "junior varsity" programmer, or ignorant of alternative programming models. Because that's the truth and that was intentional at its design. > I'm well-versed in half a dozen other languages, many of which include generics. It depends in which languages.

Chris2048 10y ago

Consider there may be an existential bias - people who are open to new languages are more likely to move away from Java.

takeda 10y ago

IMO switching an enterprise developer from language such as Java to Go is like asking someone who has very developed vocabulary in English to try Toki Pona[1]. Yes, it is simple, and you can learn it fast, you also can also communicate with it, but you will often have to fight with the language to express what you want. That person generally won't be satisfied. Go's shortcomings wouldn't be so bad if in exchange, the language would ensure that your code is less prone to errors, but that doesn't seem to be true. In fact Go programs from my experience appear to be slightly below average in terms of stability and robustness compared to other statically typed languages. [1] https://en.wikipedia.org/wiki/Toki_Pona https://en.wikipedia.org/wiki/Toki_Pona

yanilkr 10y ago
Your opinion on this is couple of standard deviations away from popular one. Is there a specific example where a program written in golang lacked compared to other statically typed languages?
- takeda 10y ago
  Well, it's small sample but I used things like InfluxDB, Consul, there were some command line tools (that I no longer remember) as well.
weberc2 10y ago
Your analogy seems weak at best. Go is mostly a subset of Java, so there's almost no difficulty in a Java developer learning Go. A Java developer can immediately read 90% of Go programs, and within a couple of hours, he can write real, interesting programs. I'm not sure that a good analogy could be made incorporating English, nor do I think there's value in doing so.
- takeda 10y ago
  I don't think you understood my analogy. Go supposed to be Toki Pona. I'm saying that once you are used to a language that's more powerful you feel constrained. I know many languages and some bring interesting things to the table, go doesn't really deliver (at least based on the hype). The concurrency supposed to be the killer feature, but it is limited to specific cases. BTW: The Go is not subset of Java if anything it's very similar to Algol-68 (http://cowlark.com/2009-11-15-go/ http://cowlark.com/2009-11-15-go/)