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

61–70 of 110 posts

Re: Go Is a Shop-Built Jig

#61

Post by lumpypua »

nl wrote: post #49
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…

I have a rule when I make project technology decisions: If we understand the domain and understand what we are building then we can afford to be innovative on the technology. If we are trying to be innovative in what we are building then we need to choose proven (aka boring) technology.

I liken this to Intel's "tick tock" development approach. If they're moving to a new microarchitecture they stay on the same process, and if they're doing a process shrink they use the same microarchitecture. Working out the kinks of a new process can be done with a microarchitecture that's solid, and vice versa.

Visually: http://www.adlinktech.com/solution/img/20131121-1.jpg

New domain => use known technology.

Known domain => play with new technology.

Re: Go Is a Shop-Built Jig

#62

Post by swah »

fineline wrote: post #12

But you can't deploy your Go to iOS. Or your Swift to Linux. I'm getting interested in Nimrod (or Nim as I think it's planning to become). Compiles to native binaries via C, C++ or ObjectiveC. Even compiles to JavaScript. So it will run on all consumer and server platforms, on microcontrollers and in browser. And it has generics, exceptions, macros, inheritance, and (optional, time-boxed) garbage-collection. It's a t…

But Go has Google.

Re: Go Is a Shop-Built Jig

#63

Post by spion »

nl wrote: post #50
lukasm wrote: post #14

I would switch from python to Go but - Type system needs to be improved e.g. generic code - Verbosity, duplication of code are painful - Lack of functional features - Tooling - Maturity

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.

Re: Go Is a Shop-Built Jig

#64

Post by spion »

metafex wrote: post #41

Lack of generics seems to always be the argument against Go. I have been coding in Go for over a year now nearly every day and it really became an annoyance only once: CRUD operations in a web-service expecting JSON-objects. That's literally the only time where the code-duplication was a problem for me. Now, not everything else has been all good (mostly minor issues with community libs), but the one thing that never…

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 = logit(FrobulatingMessage); err != nil {
      return err
  }
repeated over and over again and can't help it but cringe

Re: Go Is a Shop-Built Jig

#65

Post by lukasm »

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.

You can write map but it's a lot of boilerplate and you loose types

Map func(interface{}, func(interface{}) interface{}) []interface{}

Re: Go Is a Shop-Built Jig

#66

Post by nl »

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.

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?

Re: Go Is a Shop-Built Jig

#67

Post by anonymoushn »

threeseed wrote: post #5

What is with Go supporters ? I don't understand why if I don't use Go then I am not solving real world problems and instead building over engineered monstrosities. Working in the enterprise features like exceptions and generics makes it easier to ensure consistency across the platform and our 20+ developers.

Whoa now, one of the few good things about Go is that it doesn't have exceptions.

Re: Go Is a Shop-Built Jig

#68

Post by anonymoushn »

tagrun wrote: post #17
threeseed wrote: post #11

Earlier quoted context omitted.

From the article: "Go feels under-engineered because it only solves real problems" "and so you build real solutions rather than finding excuses to use your beautiful tools" The implication from reading the article is that those of us that rely on those so called exotic features aren't doing so for serious business and technical reasons. And it seems to be a common thread amongst many Go users. And generics allow you…

> The implication from reading the article is that [...] The implication you inferred from reading the article is that... I think there reason is that there a misunderstanding here caused by a cultural gap. The Practice of Programming is a very good read which I feel like recommending to every programmer. > And generics allow you to reuse existing components much cleaner and exceptions allow you to handle errors in a…

> You don't build error handling classes in Go.

I've encountered people doing this. When I said "If I had Maybe here then I could write 1/5 as much code," someone showed me a class that maintained whether it had encountered an error, and each method would do nothing and return the previous error if so. This allowed him to write 1/5 as much code in the method that actually does stuff, just as he would in Haskell or Swift. Unfortunately the approach of reducing every function full of noisy error checking to a bunch of calls on one object is pretty bad in general...

Re: Go Is a Shop-Built Jig

#69

Post by Pxtl »

anonymoushn wrote: post #67
threeseed wrote: post #5

What is with Go supporters ? I don't understand why if I don't use Go then I am not solving real world problems and instead building over engineered monstrosities. Working in the enterprise features like exceptions and generics makes it easier to ensure consistency across the platform and our 20+ developers.

Whoa now, one of the few good things about Go is that it doesn't have exceptions.

That incessant repetition of error-handling boilerplate shown in the article is not an argument in favor of this approach.

Re: Go Is a Shop-Built Jig

#70

Post by metafex »

spion wrote: post #64
metafex wrote: post #41

Lack of generics seems to always be the argument against Go. I have been coding in Go for over a year now nearly every day and it really became an annoyance only once: CRUD operations in a web-service expecting JSON-objects. That's literally the only time where the code-duplication was a problem for me. Now, not everything else has been all good (mostly minor issues with community libs), but the one thing that never…

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.

Post reply on HN