Hacker News Reader

Comment by yanilkr | Hacker News Reader

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.

View on HN

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.

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.

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?)

Not using a Result is a warning, not an error: https://is.gd/U43rdG

Sorry, yes (I compile with warnings as errors), good catch.

You must explicitly ignore errors in Go.

result, _ := someFunc()

Not if they are the only return value. You should use an analysis tool to avoid this but nothing about the language requires it.

Ah, you are right.

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.

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.

Reply on news.ycombinator.com