5 ms·

> 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

> 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.
    - eropple 10y ago
      To add to this: Go's inexpressivity (hi, generics!) makes common patterns that I see in Kotlin, Java, and Scala (as well as Rust, off-JVM) makes error handling a complete bear, to the point where my eyebrows are really raised at vertex-four being downvoted for this. The use of please-check-this error conditions instead of something like a Try<T, E> (Result<V, E> in Rust) and an inability to just map over these as 0- or 1-element collections is such a huge pain, and it certainly does matter when you're piling up multiple error-handling cases. Even more when you'd otherwise use Scala's `recover` to get back on a happy path. Go's inexpressivity directly impinges on one's ability to get things done. (Food for thought: forgetting to handle the error case from Rust's Result<V, E> is a compiler error. Is "if err != nil" really that good an idea in such a universe?)
      - chrismorgan 10y ago
        Not using a Result is a warning, not an error: https://is.gd/U43rdG https://is.gd/U43rdG
        eropple 10y ago
        Sorry, yes (I compile with warnings as errors), good catch.
      - mratzloff 10y ago
        You must explicitly ignore errors in Go. result, _ := someFunc()
        kasey_junk 10y ago
        Not if they are the only return value. You should use an analysis tool to avoid this but nothing about the language requires it.
        mratzloff 10y ago
        Ah, you are right.
  - ThrustVectoring 10y ago
    I'd use a different analogy - there are definitely circumstance where you'd want the screwdriver over the electric drill. Screwdrivers can't run out of batteries, are lighter weight, and give you more feedback and control while being used. If I was going to be in a crawlspace for three hours doing wiring and knew that I'd need to drive in a screw at some point, I'd rather have the screwdriver on me than lug around or go back for the drill.
  - johndifool 10y ago
    Nothing wrong using a screwdriver when you do cabinet work as opposed to using electric drills for carpentry. A manual and more precise work calls for a different tool. Electric drills will strip the head of the screws over time. And every tiem I need to use an electric drill, its battery needs to be charged first, sending me back to the manual screwdriver.
weberc2 10y ago
> especially when you have to unlearn sound and proven practices, which Go often requires to do. Such as? I'm not really sure what "sound and proven practices" a Java developer would have to "unlearn" to adopt Go. Most of the differences between Go and Java amount to removing features that 20 years of Java experience have proved to be unsound or unnecessary (inheritance and exceptions, for example). From a feature perspective, Go is mostly a subset of Java. The features Go adds are mostly related to concurrency, and I've not heard anyone say Java does concurrency better than Go.
- jonathankoren 10y ago
  > ost of the differences between Go and Java amount to removing features that 20 years of Java experience have proved to be unsound or unnecessary (inheritance and exceptions, for example). We'll just have to disagree about this point.
- eropple 10y ago
  I'll say that Java doesn't do currency worse than Go, that's for sure. It has all of the primitives in whatever arrangement you want to put them (Javaflow and now Coroutines if you want go-I'm-sorry-coroutines, native threads if you want those, and Go channels can be implemented in maybe two dozen lines), more flexible, battle-tested abstractions (such as Akka offering you an asynchronous, message-passing actor model, which could be written in Go but seems in practice to be passed up in favor of channels), and tooling around these that I find to be head-and-shoulders better than anything Go has (like multi-threaded debugging). I've basically (willingly or unwillingly) turned into a Ruby person over the last few years, as neither Go nor the JVM really have a ton to offer me right now, but I don't think a fair comparison of concurrency-related stuff, either in terms of tooling, libraries, or the language itself (I'd give Go this, except that you can't build an unbounded buffered channel and at that point the use of channels for what I write rapidly approaches zero), is nearly as clear as you assert.
  - weberc2 10y ago
    Debugging is definitely a valid counter-point. Go's debugging story is rapidly evolving, but it's not particularly friendly or settled at this point. Goroutines are subtly different than coroutines, mostly in that goroutines are not bound to the OS thread they're created on, and also that they don't need to be explicitly yielded--any I/O or lock-blocking (including reading or writing on channels) are potential interrupt points. Channels are probably also less easy than you might think, particularly the nuances around Go's `select` keyword. I'm not sure where exactly Java stands on all of this. I've heard that the Quasar library comes close to bringing Go's concurrency tools to the JVM, but it's not widely used and any non-Quasar I/O is likely going to block your OS thread. At any rate, while I agree that Java can theoretically come very close to matching Go's concurrency story, it falls very short in practice. > you can't build an unbounded buffered channel and at that point the use of channels for what I write rapidly approaches zero If you're using Ruby, I'm guessing you don't need thread safety, so you probably just want a slice. > I don't think a fair comparison of concurrency-related stuff ... is nearly as clear as you assert Like I said, I think libraries like Quasar have a lot of potential, but they're not widely used. If it was the de-facto solution for concurrency in Java, I would agree that "concurrency in Java is no worse than in Go" (and I would have to, since Quasar's stated purpose is to bring Go-like concurrency to Java).

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.
  - eropple 10y ago
    To add to this: Go's inexpressivity (hi, generics!) makes common patterns that I see in Kotlin, Java, and Scala (as well as Rust, off-JVM) makes error handling a complete bear, to the point where my eyebrows are really raised at vertex-four being downvoted for this. The use of please-check-this error conditions instead of something like a Try<T, E> (Result<V, E> in Rust) and an inability to just map over these as 0- or 1-element collections is such a huge pain, and it certainly does matter when you're piling up multiple error-handling cases. Even more when you'd otherwise use Scala's `recover` to get back on a happy path. Go's inexpressivity directly impinges on one's ability to get things done. (Food for thought: forgetting to handle the error case from Rust's Result<V, E> is a compiler error. Is "if err != nil" really that good an idea in such a universe?)
    - chrismorgan 10y ago
      Not using a Result is a warning, not an error: https://is.gd/U43rdG https://is.gd/U43rdG
      - eropple 10y ago
        Sorry, yes (I compile with warnings as errors), good catch.
    - mratzloff 10y ago
      You must explicitly ignore errors in Go. result, _ := someFunc()
      - kasey_junk 10y ago
        Not if they are the only return value. You should use an analysis tool to avoid this but nothing about the language requires it.
        mratzloff 10y ago
        Ah, you are right.
- ThrustVectoring 10y ago
  I'd use a different analogy - there are definitely circumstance where you'd want the screwdriver over the electric drill. Screwdrivers can't run out of batteries, are lighter weight, and give you more feedback and control while being used. If I was going to be in a crawlspace for three hours doing wiring and knew that I'd need to drive in a screw at some point, I'd rather have the screwdriver on me than lug around or go back for the drill.
- johndifool 10y ago
  Nothing wrong using a screwdriver when you do cabinet work as opposed to using electric drills for carpentry. A manual and more precise work calls for a different tool. Electric drills will strip the head of the screws over time. And every tiem I need to use an electric drill, its battery needs to be charged first, sending me back to the manual screwdriver.

weberc2 10y ago

> especially when you have to unlearn sound and proven practices, which Go often requires to do. Such as? I'm not really sure what "sound and proven practices" a Java developer would have to "unlearn" to adopt Go. Most of the differences between Go and Java amount to removing features that 20 years of Java experience have proved to be unsound or unnecessary (inheritance and exceptions, for example). From a feature perspective, Go is mostly a subset of Java. The features Go adds are mostly related to concurrency, and I've not heard anyone say Java does concurrency better than Go.

jonathankoren 10y ago
> ost of the differences between Go and Java amount to removing features that 20 years of Java experience have proved to be unsound or unnecessary (inheritance and exceptions, for example). We'll just have to disagree about this point.
eropple 10y ago
I'll say that Java doesn't do currency worse than Go, that's for sure. It has all of the primitives in whatever arrangement you want to put them (Javaflow and now Coroutines if you want go-I'm-sorry-coroutines, native threads if you want those, and Go channels can be implemented in maybe two dozen lines), more flexible, battle-tested abstractions (such as Akka offering you an asynchronous, message-passing actor model, which could be written in Go but seems in practice to be passed up in favor of channels), and tooling around these that I find to be head-and-shoulders better than anything Go has (like multi-threaded debugging). I've basically (willingly or unwillingly) turned into a Ruby person over the last few years, as neither Go nor the JVM really have a ton to offer me right now, but I don't think a fair comparison of concurrency-related stuff, either in terms of tooling, libraries, or the language itself (I'd give Go this, except that you can't build an unbounded buffered channel and at that point the use of channels for what I write rapidly approaches zero), is nearly as clear as you assert.
- weberc2 10y ago
  Debugging is definitely a valid counter-point. Go's debugging story is rapidly evolving, but it's not particularly friendly or settled at this point. Goroutines are subtly different than coroutines, mostly in that goroutines are not bound to the OS thread they're created on, and also that they don't need to be explicitly yielded--any I/O or lock-blocking (including reading or writing on channels) are potential interrupt points. Channels are probably also less easy than you might think, particularly the nuances around Go's `select` keyword. I'm not sure where exactly Java stands on all of this. I've heard that the Quasar library comes close to bringing Go's concurrency tools to the JVM, but it's not widely used and any non-Quasar I/O is likely going to block your OS thread. At any rate, while I agree that Java can theoretically come very close to matching Go's concurrency story, it falls very short in practice. > you can't build an unbounded buffered channel and at that point the use of channels for what I write rapidly approaches zero If you're using Ruby, I'm guessing you don't need thread safety, so you probably just want a slice. > I don't think a fair comparison of concurrency-related stuff ... is nearly as clear as you assert Like I said, I think libraries like Quasar have a lot of potential, but they're not widely used. If it was the de-facto solution for concurrency in Java, I would agree that "concurrency in Java is no worse than in Go" (and I would have to, since Quasar's stated purpose is to bring Go-like concurrency to Java).