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

Why I’m Frustrated with Go

dev.to

Post reply on HN
Print view View original

131–140 of 233 posts

Re: Why I’m Frustrated with Go

#131

Post by andreasgonewild »

tonetheman wrote: post #100

I asked this same question on reddit. And I am not trying to be snarky. I have programmed a long time and I cannot think of a single time where I thought, "this would be easier with generics." Where is the list of problems that are easier to solve with generics?

You don't mention your level of experience with generic type systems, but I find it's mostly the case that I can't imagine any use for techniques I'm not yet familiar with.

Here is a random example from my recent adventures, a channel implementation in C++ which uses generics to provide value-semantics for user-specified message types:

https://github.com/andreas-gone-wild/snackis/blob/master/src...

And here is a column class that uses generics to inject both record type and value type into the implementation:

https://github.com/andreas-gone-wild/snackis/blob/master/src...

Doing any of these without generics would mean either erasing types or writing duplicate code. Go provides generic channels, slices and maps; but it doesn't extend that power to user-code since users are supposedly not smart enough to be trusted with power.

Re: Why I’m Frustrated with Go

#132

Post by yupyup »

rebolek wrote: post #45
jmaa wrote: post #31

Go was explicitly designed to be a simple language, without a rich tapestry of data structures to suit every use case. Languages are like tools. If you need a saw, use a saw, instead of complaining about the knife you are using.

No, languages are like toolboxes, they provide you with set of tools.

No, languages are like Ogres, they have layers.

Re: Why I’m Frustrated with Go

#133

Post by codegladiator »

meesterdude wrote: post #122
codegladiator wrote: post #117

Earlier quoted context omitted.

They count 24 lines of code as "infuriating amount of code to write". Why do you think they would interested in writing a web server ?

To be fair, 24 lines for something you know should be doable in only a few (or one!) is pretty darn frustrating.

I was counting less the 50 lines as "few lines".

Re: Why I’m Frustrated with Go

#134

Post by Ar-Curunir »

ue_ wrote: post #93
masklinn wrote: post #30

Earlier quoted context omitted.

Rust bounds-checks indexes by default (there exist indexing methods which bypass that, they are unsafe).

If by "bounds-checks indexes" you mean "panics when given an out of bounds index, even if it's a compile time constant" then sure. I'm not sure why people talk about Rust being safe when this sort of thing happens and it can't catch it at compile time. At least C compilers have sanitizers that pick up things like that.

You mean, compared to C, which silently allows you to read data beyond the end of the array?

Sanitizers also exist for rust.

Furthermore, often time the bounds check can be elided when using standard constructs like iterators.

Re: Why I’m Frustrated with Go

#135

Post by nine_k »

tonetheman wrote: post #100

I asked this same question on reddit. And I am not trying to be snarky. I have programmed a long time and I cannot think of a single time where I thought, "this would be easier with generics." Where is the list of problems that are easier to solve with generics?

Channels, maps, and arrays are generic in Go. They solve a lot if key problems.

The problem is that you can't create your own generic structure. Try building a statically type-safe red-black tree, or something like that, without copy-pastig the implementation for each new node data type.

Higher-order functions are also basically impossible.

Re: Why I’m Frustrated with Go

#136

Post by ejcx »

latch wrote: post #11

I did Go for years, but stopped doing any serious work in it about a year ago. In general, I found it a chore to maintain Go-based systems. There's a lot to like about Go. But it doesn't seem pragmatic for the types of applications I see people using it for. For example, the entire error thing is absurd. Anders Hejlsberg got this right many years ago: 9 out of 10 errors are "handled" by a central error handler (log +…

Wat. OpenResty as an alternative to go? Wat?

Please, nobody write full fledged WebApps or all of your middleware in lua. Trust me that's a horrible idea. I have seen about everything you can do in lua/nginx and it does not turn out pretty.

Re: Why I’m Frustrated with Go

#137

Post by nine_k »

dboreham wrote: post #110
japano1se wrote: post #74

Of course the problem he has is that it doesn't follow the hot new immutability fad, and of course he doesn't explain what he needs it for, just links to a stack exchange question which essentially says that it might be useful for some cases. It seems a lot of these articles, and programming language theory in general, is just complaining about features without any thought as to why they matter. What is this "problem…

Spot on. As a card-carrying dinosaur I've found myself from time to time needing to read up on some "new" (usually turns out to have been invented in the 60's) coding thing. Once I figure out what it is, I ask myself what problem it solves (the literature typically doesn't say). The answer tends to be one of: 1. Saves some typing. 2. Saves some work when refactoring. 3. Avoids some class of bug. 4. Highly useful in a…

"Saves some typing" is not that important as "saves some reading", which is one of the most important activities people do with source code.

Re: Why I’m Frustrated with Go

#138

Post by dboreham »

japano1se wrote: post #127
dboreham wrote: post #110

Earlier quoted context omitted.

Spot on. As a card-carrying dinosaur I've found myself from time to time needing to read up on some "new" (usually turns out to have been invented in the 60's) coding thing. Once I figure out what it is, I ask myself what problem it solves (the literature typically doesn't say). The answer tends to be one of: 1. Saves some typing. 2. Saves some work when refactoring. 3. Avoids some class of bug. 4. Highly useful in a…

Absolutely. With respect to this article and immutability, the strongest arguments I've seen for it are for concurrent programming, like the very successful Erlang solutions used at Ericsson, which I generally don't have an interest in. So, it is reason #4 on your list. For the types of program and the types of problem I need to solve, it's a moot point - people have been getting along just fine without immutable sta…

Also, sometimes the people making the argument for language feature X don't fully understand the existing solutions to the problem, or how much of a practical problem it is. E.g. the "less typing" concern -- when you write code day in day out a bit less typing really isn't in your top 10 list of concerns. That list would more likely include things like "easy to understand what the code does" and "easy to debug".

Re: Why I’m Frustrated with Go

#139

Post by oelmekki »

falcolas wrote: post #94
oelmekki wrote: post #72

Out of curiosity, what is the use case for immutable structs? (asking as I'm a ruby/js/go dev and as such I've never used such idiom)

It's a code safety thing. If you create it and the compiler makes it immutable, then you can't screw it up later with an accidental mutation. Basically, something that takes coder discipline in Ruby/JS/Go is handled a compiler/runtime enforced restriction.

Oh, I see, thanks. I get now how it can be a problem when you're used to rely on it and it's not in the language.

Re: Why I’m Frustrated with Go

#140

Post by nine_k »

falcolas wrote: post #98
PeterisP wrote: post #57

Earlier quoted context omitted.

The author discounts this as a good solution because you'd have to re-implement the structure and functions for every single type you might put in the map; i.e. that would be a valid solution iff Go supported generics, but it does not.

Go's introspection tools do provide enough support to offset the lack of generics, at the cost of having to write your own type checks, and at the cost of having runtime instead of compile time type checking. But it can be done.

Anything Turing-complete could by definition be run on a Turing machine. But Brainf*k, a straightforward Turing machine implementation, seems less productive than almost any other language.
Post reply on HN