Live data from Hacker News

Go Is a Shop-Built Jig

robnapier.net

11–20 of 110 posts

Re: Go Is a Shop-Built Jig

#11
post #7

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.

> 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. What is with you? The article is talking about languages , not the category of problems people are trying to solve using those languages. (In principle, NASA could have written the Mars rover code in brainfuck). > enterprise features like exceptions and…

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 to reuse existing components much cleaner and exceptions allow you to handle errors in a consistent way across the system. You can build error handling classes but often handling errors explicitly doesn't scale.

Re: Go Is a Shop-Built Jig

#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 tiny community which hasn't even managed to get a Wikipedia page to stay up, but I'm barracking for it.

Re: Go Is a Shop-Built Jig

#13
post #7

Earlier quoted context omitted.

> 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. What is with you? The article is talking about languages , not the category of problems people are trying to solve using those languages. (In principle, NASA could have written the Mars rover code in brainfuck). > enterprise features like exceptions and…

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…

I don't see that implication at all.

Re: Go Is a Shop-Built Jig

#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

Re: Go Is a Shop-Built Jig

#15
post #7

Earlier quoted context omitted.

> 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. What is with you? The article is talking about languages , not the category of problems people are trying to solve using those languages. (In principle, NASA could have written the Mars rover code in brainfuck). > enterprise features like exceptions and…

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…

I read that to mean that other languages can solve both real and "non-real" problems, those where one can try ones tools for the inherent joy of using them, but that Go probably doesn't inspire one to do the latter and focuses solely on the real problems.

Re: Go Is a Shop-Built Jig

#16

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 you can't deploy your Go to iOS.

And? iOS and Android supports are on their way in case you're not following recent developments. In case you're interested in writing programs for mobile devices, there's already a supporting go.mobile repository with (mainly targeting Android at the moment).

> And it has generics, exceptions, macros, inheritance, and (optional, time-boxed) garbage-collection.

Sigh... this "where's my feature!" argument almost always comes up.

It is not reasonable to expect that feature X that is very important to you has to carry the same weight for other people.

Some people think that it is unthinkable to write programs without feature X. If you think that way, then Go is probably not a language for you. Note however that there are many people who do not think that absence of feature X is a crippling thing, and do enjoy writing programs in Go.

> It's a tiny community [...]

in total contrast with... Nimrod community?

Re: Go Is a Shop-Built Jig

#17
post #7

Earlier quoted context omitted.

> 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. What is with you? The article is talking about languages , not the category of problems people are trying to solve using those languages. (In principle, NASA could have written the Mars rover code in brainfuck). > enterprise features like exceptions and…

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 consistent way across the system.

Although I don't think "exceptions allow you to handle errors in a consistent way" (based on my long and still on-going experience with C++), I still don't see how exceptions and generics "ensure consistency across the platform".

> You can build error handling classes but often handling errors explicitly doesn't scale.

You don't build error handling classes in Go.

Re: Go Is a Shop-Built Jig

#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, well, you need some training wheels so we're gonna use Go for this project".

I don't know about you but I'd rather work with people that understand the tools they are using and when it's OK to do fun stuff and when it is important to exercise restraint and "dumb it down" for the good of the team. Using the language to solve the problem of uneven programmer ability feels a bit off. It's something out of 1984. You can't say "great" in Go you can only say "good++".

Post reply on HN