5 ms·

Any decent programmer should be able to switch between {C,Java,Go,Python} without too much difficulty. They each have their own differences and learning curve,

Any decent programmer should be able to switch between {C,Java,Go,Python} without too much difficulty. They each have their own differences and learning curve, but as long as a programmer doesn't identify themselves too tightly as a specific language developer (e.g. some people say "I'm a Java programmer", implying they couldn't possibly learn something else) then it's not hard to pick up Go.

tptacek 11y ago
If you took "C" out of that list, I'd agree with it.
- dsymonds 11y ago
  Yeah, C is probably the hardest to learn in that set.
eropple 11y ago
I think that's reductive. I'm a "decent programmer". (I think I'm a little better than that, if I'm being honest.) I regularly use Ruby, Scala, C#, and enough bash to choke a horse. Some C++ too, when I have to, but it's not something I ever want to touch. I can't deal with Go. And I don't think it's me--I don't do Haskell because of me, I don't do Go because of it. I find it almost impossible to think in Go. I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." This wouldn't bother me, in a very "you do you" sense, if I wasn't stuck debugging faddishly-designed tools like Docker and Terraform written in it. To this end I think Go is a regression for the open source community, because what I see as veneration of stump-dumb languages makes it harder, not easier, to be smart about problems.
- dsymonds 11y ago
  That wasn't what I was replying to. aaggarwal was asking how easy it was to move to it. I was saying that it's easy. If you find it too primitive, well, that's a fair opinion, but it's still easy to move to. I think it's hyperbole to claim that you can't work in it.
  - eropple 11y ago
    No, something that's as primitive as Go is quite hard to move to. I understand the language, but I can't think in it and so using it is very far from easy.
- danieldk 11y ago
  I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? What are you missing in Go compared to C besides manual memory management? To me, Go seems to have about the same amount of expressiveness as C and Java. The difference being that it's safer than C and more UNIXy/less OO than Java. To this end I think Go is a regression for the open source community, because what I see as veneration of stump-dumb languages makes it harder, not easier, to be smart about problems. A lot of open source UNIX software was written in C. To me it seems that if C was acceptable, Go is acceptable (if the application can live with a GC and slightly lower performance). And as the article argues, it lowers the bar for contribution, because it restricts overengineering.
  - eropple 11y ago
    > Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? That's a clever way to attempt to constrain the conversation away from the elephant in the room. "Other than the bullet in your stomach, how are you feeling?" Not having at least Java-style "dumb" generics, in 2015, is unacceptable; the existence of `go generate` should mortify everybody involved with Go. Not having better than that--consider what you can do with Scala even before you get to something like Shapeless--is not quite unacceptable but short-sighted and limiting because suddenly I as a human have to do what a moderately smart compiler can do around type checking and leveraging types to solve problems. Go's general ignorance, and the community's general ignorance, to really basic functional programming that so hugely improves your life is probably borne out of the stupid type system; things like composition (Try monads) for error handling, so I'm not vomiting `if err != nil` everywhere, things like functional transforms for data structures so I'm not writing for loops until my eyes bleed. And you can't really do that in a statically typed language without either blind casts (which Go partisans recommend, because clearly everything should be `interface {}`, remember the days when java.util.ArrayList just gave you Objects?) or generics. It's just...dumb, written for the lowest common denominator, and I guess the lowest common denominator is dishearteningly low. Good for them, but having more and more core tools written in this junk makes my job a lot harder because it obfuscates potential problems under a sea of boilerplate and line noise. > To me, Go seems to have about the same amount of expressiveness as C and Java. I agree with that assessment. Go's roughly equivalent in expressiveness to Java. That is a criticism, not a defense. Go being a somewhat more terse Java 1.4 is not an endorsement of the language or the environment. I stopped using Java quite some time ago because my frustrations with "coding with gloves on" outstripped any benefits of the language. (Not the virtual machine. The JVM is fantastic, I love using it. But Java-the-language is Newspeak: if I can't coherently describe a solution in its syntax and semantics, I have to resort to worse solutions. Go's actually worse for this, surprisingly enough...) Michael O. Church discusses the problems of Java and the problems if the Java shop very well in one of his articles, and in my experience the Go people I have worked with and talked to almost universally fit into that mold (echoing the normal Java ignorance of the outside world, a neat sense of epistemic closure, and the weird desire to rewrite the world into it). https://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/ https://michaelochurch.wordpress.com/2012/04/13/java-shop-po... > if C was acceptable, Go is acceptable Should C be acceptable? I don't think so. C is, in 2015 and in truth in 2000, too stupid to live. For a very long time we had no other alternatives, and it is an effective lingua franca because it's dumb enough that you can knock out a language binding in short order, but it's a bad language. No memory safety, no type safety (seriously, just review the rules for implicit pointer casting, you have no types to speak of), and nothing, anywhere, to help you not do things that are damaging. Like, I'm not a C++ fan because it has many warts and creeping features, but if you literally limit yourself to C with classes, std::string/std::vector, and use pointers only in a last resort (preferring references), you have just solved probably eighty percent of the correctness and security problems caused by our reliance on C. (And you cannot practically implement many of those solutions in C without a level of developer discipline that essentially does not exist in the wild. Just having ctors/dtors is literally transformative to writing safe, smart code.) Rust will solve more, better, and I'm a huge fan of what they're trying to do, but isn't there yet. > And as the article argues, it lowers the bar for contribution, because it restricts overengineering. That's an argument. I'd say that it restricts engineering. Which is not a fatal flaw of a tool, there are lots of problems where grunting and bashing your way through it makes sense, but engineering problems often require being able to actually write what you mean, not write what you need to address the symptoms of the inexpressive language before you get to write what you sort of mean if you squint through the garbage it forces upon you. Lowering the bar for contribution is only a plus if it doesn't moronize people who are cool with clearing a higher bar. For most of the stuff that I deal with, four novices don't replace one expert. When using Go, I very strongly feel that I can't do my job intelligently because I don't have the tools, and so not only will I do my job more slowly, but I increase the likelihood of doing my job wrong.
- deleted 11y ago
  [deleted]

tptacek 11y ago

If you took "C" out of that list, I'd agree with it.

dsymonds 11y ago
Yeah, C is probably the hardest to learn in that set.

eropple 11y ago

I think that's reductive. I'm a "decent programmer". (I think I'm a little better than that, if I'm being honest.) I regularly use Ruby, Scala, C#, and enough bash to choke a horse. Some C++ too, when I have to, but it's not something I ever want to touch. I can't deal with Go. And I don't think it's me--I don't do Haskell because of me, I don't do Go because of it. I find it almost impossible to think in Go. I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." This wouldn't bother me, in a very "you do you" sense, if I wasn't stuck debugging faddishly-designed tools like Docker and Terraform written in it. To this end I think Go is a regression for the open source community, because what I see as veneration of stump-dumb languages makes it harder, not easier, to be smart about problems.

dsymonds 11y ago
That wasn't what I was replying to. aaggarwal was asking how easy it was to move to it. I was saying that it's easy. If you find it too primitive, well, that's a fair opinion, but it's still easy to move to. I think it's hyperbole to claim that you can't work in it.
- eropple 11y ago
  No, something that's as primitive as Go is quite hard to move to. I understand the language, but I can't think in it and so using it is very far from easy.
danieldk 11y ago
I find it incredibly primitive, well past the point of "stupid code is impossible to misunderstand" and into "stupid code because the language demands it." Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? What are you missing in Go compared to C besides manual memory management? To me, Go seems to have about the same amount of expressiveness as C and Java. The difference being that it's safer than C and more UNIXy/less OO than Java. To this end I think Go is a regression for the open source community, because what I see as veneration of stump-dumb languages makes it harder, not easier, to be smart about problems. A lot of open source UNIX software was written in C. To me it seems that if C was acceptable, Go is acceptable (if the application can live with a GC and slightly lower performance). And as the article argues, it lowers the bar for contribution, because it restricts overengineering.
- eropple 11y ago
  > Since the parent mentioned C and Java. What are you missing in Go compared to Java besides generics? That's a clever way to attempt to constrain the conversation away from the elephant in the room. "Other than the bullet in your stomach, how are you feeling?" Not having at least Java-style "dumb" generics, in 2015, is unacceptable; the existence of `go generate` should mortify everybody involved with Go. Not having better than that--consider what you can do with Scala even before you get to something like Shapeless--is not quite unacceptable but short-sighted and limiting because suddenly I as a human have to do what a moderately smart compiler can do around type checking and leveraging types to solve problems. Go's general ignorance, and the community's general ignorance, to really basic functional programming that so hugely improves your life is probably borne out of the stupid type system; things like composition (Try monads) for error handling, so I'm not vomiting `if err != nil` everywhere, things like functional transforms for data structures so I'm not writing for loops until my eyes bleed. And you can't really do that in a statically typed language without either blind casts (which Go partisans recommend, because clearly everything should be `interface {}`, remember the days when java.util.ArrayList just gave you Objects?) or generics. It's just...dumb, written for the lowest common denominator, and I guess the lowest common denominator is dishearteningly low. Good for them, but having more and more core tools written in this junk makes my job a lot harder because it obfuscates potential problems under a sea of boilerplate and line noise. > To me, Go seems to have about the same amount of expressiveness as C and Java. I agree with that assessment. Go's roughly equivalent in expressiveness to Java. That is a criticism, not a defense. Go being a somewhat more terse Java 1.4 is not an endorsement of the language or the environment. I stopped using Java quite some time ago because my frustrations with "coding with gloves on" outstripped any benefits of the language. (Not the virtual machine. The JVM is fantastic, I love using it. But Java-the-language is Newspeak: if I can't coherently describe a solution in its syntax and semantics, I have to resort to worse solutions. Go's actually worse for this, surprisingly enough...) Michael O. Church discusses the problems of Java and the problems if the Java shop very well in one of his articles, and in my experience the Go people I have worked with and talked to almost universally fit into that mold (echoing the normal Java ignorance of the outside world, a neat sense of epistemic closure, and the weird desire to rewrite the world into it). https://michaelochurch.wordpress.com/2012/04/13/java-shop-politics/ https://michaelochurch.wordpress.com/2012/04/13/java-shop-po... > if C was acceptable, Go is acceptable Should C be acceptable? I don't think so. C is, in 2015 and in truth in 2000, too stupid to live. For a very long time we had no other alternatives, and it is an effective lingua franca because it's dumb enough that you can knock out a language binding in short order, but it's a bad language. No memory safety, no type safety (seriously, just review the rules for implicit pointer casting, you have no types to speak of), and nothing, anywhere, to help you not do things that are damaging. Like, I'm not a C++ fan because it has many warts and creeping features, but if you literally limit yourself to C with classes, std::string/std::vector, and use pointers only in a last resort (preferring references), you have just solved probably eighty percent of the correctness and security problems caused by our reliance on C. (And you cannot practically implement many of those solutions in C without a level of developer discipline that essentially does not exist in the wild. Just having ctors/dtors is literally transformative to writing safe, smart code.) Rust will solve more, better, and I'm a huge fan of what they're trying to do, but isn't there yet. > And as the article argues, it lowers the bar for contribution, because it restricts overengineering. That's an argument. I'd say that it restricts engineering. Which is not a fatal flaw of a tool, there are lots of problems where grunting and bashing your way through it makes sense, but engineering problems often require being able to actually write what you mean, not write what you need to address the symptoms of the inexpressive language before you get to write what you sort of mean if you squint through the garbage it forces upon you. Lowering the bar for contribution is only a plus if it doesn't moronize people who are cool with clearing a higher bar. For most of the stuff that I deal with, four novices don't replace one expert. When using Go, I very strongly feel that I can't do my job intelligently because I don't have the tools, and so not only will I do my job more slowly, but I increase the likelihood of doing my job wrong.
deleted 11y ago
[deleted]