Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Is a Shop-Built Jig

robnapier.net

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Go Is a Shop-Built Jig

#71

Post by spion »

nl wrote: post #66
spion wrote: post #63

Earlier quoted context omitted.

No, they make the language weaker. For example, its impossible to write the `map` function in Go because of type restrictions. In python, every function is as generic as it can be.

That isn't the case at all. The problem is that the types restrict your functions, so you either have to write a Mao function for every type you want to support, or drop the types altogether. The situation where you drop the types is the equivalent to Python isn't it?

Its not because in Go you cannot reuse existing functions that you've written if you drop the types. In python, you can.

Re: Go Is a Shop-Built Jig

#72

Post by spion »

lukasm wrote: post #65
spion wrote: post #63

Earlier quoted context omitted.

No, they make the language weaker. For example, its impossible to write the `map` function in Go because of type restrictions. In python, every function is as generic as it can be.

You can write map but it's a lot of boilerplate and you loose types Map func(interface{}, func(interface{}) interface{}) []interface{}

You also loose the ability to pass existing functions with your implementation of Map

  Map([]string{"a", "b", "c", "d"}, ToUpper)

Re: Go Is a Shop-Built Jig

#73

Post by mononcqc »

The few things that bother me about this article are these apparent contradictions:

> And then, when it was all working, I refactored out the duplicated code. And I refactored again. And in the end, the whole thing was simpler and shorter than what I would have done with generics

And then:

> When writing the Go function, I started at the top and typed until I got to the bottom. And that was it. There aren’t very many ways to write this function in Go.

You don’t need generics, just refactor until it works; also, you don’t really need to think about how to rewrite thing, it should be obvious.

Other bits, like:

> So again, in the end, Go turned out to be a language for solving real problems rather than a language filled with beautiful tools, and so you build real solutions rather than finding excuses to use your beautiful tools. […] But if you’re trying to solve specific, practical problems in the forms professional developers typically encounter, Go is quite nice.

Seem to carry the implicit assumption that it’s a mutually exclusive problem, or that having beautiful tools leads to not solving the problem appropriately. That if you use fancy tools, the problem somehow doesn’t get fixed, masturbatory practices take place instead.

I’m not sure I can see myself agreeing.

Re: Go Is a Shop-Built Jig

#74

Post by tptacek »

dkarapetyan wrote: post #19

Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, we…

That's not at all what the author said. A shop-made jig isn't "training wheels for the shop".

Re: Go Is a Shop-Built Jig

#75

Post by jhawk28 »

bascule wrote: post #20

"Go feels under-engineered because it only solves real problems" This belies a multitude of real problems Go doesn't solve, like generics or preventing data races

How does go not prevent data races? It has a race detector, channels, and atomics.

Re: Go Is a Shop-Built Jig

#76

Post by polux »

tagrun wrote: post #9
sat wrote: post #2

Seriously, in good faith, I attempted to learn and write a simple web application in go. I found it hard coming from a world where IDE support was available in other languages that do autocompletion and things like that and development just moves faster. In go, there is some level of support in sublime text, go for vim etc, but it is not nearly as full featured as say, IntelliJ. Want to learn about the javadoc - Comm…

As you have discovered the hard way, trying to write Java in Go is not productive.

IDE support is not a prerogative of Java.

Re: Go Is a Shop-Built Jig

#77

Post by lmm »

zackbloom wrote: post #27
dkarapetyan wrote: post #19

Notice the author would still rather use Swift when he's doing fun stuff. I get this sentiment and more than once I've wished there were more constraints in the language to mitigate the damage some kid with a chip on their shoulder could do but it says something about the psychology of programmers, "I know personally I'm good enough to do magical, wizardly stuff with all the cool stuff that Swift gives me but you, we…

So you're saying you want programming to be hard because that means you get to work with smarter people? I think what Go is striving for is simplicity, not elegance. And that change makes the code easier to write and maintain for everybody involved. At 10AM I might feel like writing Swift, but at 3AM I'm sure as hell glad I used Go. Or, less anecdotally, I maintain about twelve services in Go, including web services,…

I don't think anyone disagrees that Go is an improvement over Javascript, or more reliable than Python. But I've been working in Scala for several years and could say the same thing about never being woken up.

Look at the examples on the page. Would you really rather see the Go one at 3AM? It's twice as long, and the superficial similarity of each if(err...) stanza obscures the important differences. On a large codebase that adds up. Maybe the "complexity" meant the Swift took longer to write (though I'd dispute that too) - but if it's more readable and more maintainable, that's a positive tradeoff.

Re: Go Is a Shop-Built Jig

#78

Post by mwcampbell »

spion wrote: post #63
nl wrote: post #50

Earlier quoted context omitted.

Hang on - you are coming from Python and complaining about the lack of generics? Why? Go types (without generics) are much stronger than in Python aren't they?

No, they make the language weaker. For example, its impossible to write the `map` function in Go because of type restrictions. In python, every function is as generic as it can be.

So, you don't write the map function in Go; you use a plain for loop. Again, Go only focuses on solving real problems, and does so in a mostly imperative style.

Re: Go Is a Shop-Built Jig

#79

Post by spion »

metafex wrote: post #70
spion wrote: post #64

Earlier quoted context omitted.

The funny thing is that adding generics will also improve error handling as you would be able to make that Result generic from Swift and implement flatMap for it. This would be as good as exceptions, if not better because its very explicit and can be made compatible with the existing mechanism. This is why I find it unbelieveable when Go users tell me "I never need generics". I look at their code and see if err = log…

You get used to that pattern ;-) Also, the "I never need generics" made me smile. Sure, one can get by without them, but sometimes, as I said above, it would be really nice to have them.

Getting used to it is not the point. What I find cringe-worthy is that that's a bewildering amount of noise. It actually makes it harder to figure out what a specific piece of code does.

Admittedly the error pattern is so common that I can imagine people getting very much used to it, but thats not the issue here. The problem is indicative of Go's lack of abstraction power, and its pervasive. There is no difference between `filter`, `map` and a regular foreach - every piece of code that wants to do things like that must re-implement the mechanics of creating new slices and assigning things to members which are accessed using a specific index. So many details - I can't see the forest from the trees!

I see the same kind of noise in legacy messy projects where a piece of code works on multiple abstraction levels and its impossible to think about what a it does without thinking about the mechanics of how it does it.

Given all this I really can't understand how someone can call Go code beautiful and clean. My gut reaction is "this will cause a mess couple of years down the line".

The cost of not having generics in Go is really understated, and it saddens me greatly. With them, Go would be an extremely interesting language. But apparently, the language designers believe that you (the user) are not to be trusted with writing sensible abstractions and therefore are forbidden to do it.

Re: Go Is a Shop-Built Jig

#80

Post by the_af »

zackbloom wrote: post #24
bascule wrote: post #20

"Go feels under-engineered because it only solves real problems" This belies a multitude of real problems Go doesn't solve, like generics or preventing data races

As he said in the article, neither seem to be problems which come up in practice. I maintain about twelve Go services running in production, and neither failure has cost me any significant amount of time.

What kills me is that generics (or any other programming language abstraction) are not problems, but problem-solving tools. Technically speaking, they are never needed, if your definition of "not needed" is "I can work without them".

You don't need anything beyond assembly language, really.

The thing with most tools and abstractions is that you don't appreciate them until you use them -- when you truly use them, not merely when you learn about them. Then you wonder how you ever lived without them. You don't know if failing to use an abstraction hasn't cost you a significant amount of time until you've embraced their use.

To me, this is a variant of the Blub paradox at work.

Post reply on HN