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

181–190 of 233 posts

Re: Why I’m Frustrated with Go

#181

Post by coldtea »

vince14 wrote: post #108
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 +…

>Node is single threaded You can still utilize all of your cores in Nodejs. So which problem are you encountering?

That the utilitization of the cores is sub-par, and at a crude coarse level (node process).

Re: Why I’m Frustrated with Go

#182

Post by coldtea »

wott wrote: post #179
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…

For me, it goes like this: 1. What the heck is this thing everybody keeps talking about, with an impressive fancy name? It must a major step forward, after all this time, I should finally have a look at it. and then 2.a. Oh, it's just a big shiny name for something I accidentally kinda do sometimes, I didn't know it bore a name. Why is it suddenly a fad to base everything on this? or 2.b. Hmmm... right... so in C it…

Sounds like a case of the blub.

Re: Why I’m Frustrated with Go

#183

Post by masklinn »

krakensden wrote: post #144
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.

People say this, but it isn't really true- you could use the sort.Interface interface like everyone else. Consumer wants to use your custom map with their custom type? Make sure it supports Less. Speaking of sort.Interface, people say they want generics, but I think there is an implicit ask for operator overloading, too. Or the code they are asking to not write is probably still going to be there.

> People say this, but it isn't really true- you could use the sort.Interface interface like everyone else. Consumer wants to use your custom map with their custom type? Make sure it supports Less.

1. So you have a map of sort.Interface, and that's just as absolutely-not-convenient-or-type-safe as a map of interface{}

2. TFA does not want a sorted map, they want an ordered map, so sort.Interface has no relevance whatsoever: the order of iteration of an ordered map is the order of insertion, not the sort order of the elements.

> Speaking of sort.Interface, people say they want generics, but I think there is an implicit ask for operator overloading, too. Or the code they are asking to not write is probably still going to be there.

Not really. Java does OK without operator overloading. Having to use methods instead of operators can be annoying in some cases (mostly when working with non-built-in numerics e.g. decimals or infinite-precision integrals) but it doesn't limit you much if it does at all.

Re: Why I’m Frustrated with Go

#184

Post by masklinn »

nine_k wrote: post #135
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.

> Channels, maps, and arrays are generic in Go.

Pointers and slices as well, and of course the various builtin operators or functions used to work on them (make, range, len, close, …).

Re: Why I’m Frustrated with Go

#185

Post by fauigerzigerk »

japano1se wrote: post #175
fauigerzigerk wrote: post #169

Earlier quoted context omitted.

Limiting mutability is not new and it's not a fad. It is at the very core of every single principle of modularity and dependency management ever invented by mankind, even beyond programming. Almost 30 years ago when I first learned C one of the first design principles I was taught was to avoid mutable global variables. And ever since that time I haven't found anything as key to avoiding bugs as knowing and controllin…

Don't move the goalposts. Global state is not the same issue as immutable data. And even if it was, Go has the `const` keyword anyway, making it entirely irrelevant to the OP article. This fad of using immutability everywhere and treating it like a silver bullet absolutely is new and is a fad.

The article isn't advocating "immutability everywhere". It complains about Go making it difficult to create immutable (or otherwise customized) data structures at all. So it is you who is moving the goalposts.

I mentioned global mutable state as an anecdote and also as an example on one extreme end of the spectrum that should make it clear what the problem is in principle: Not knowing what code changes what state.

But I see that you have decided to avoid debating the core issue entirely.

Your mention of Go's const keyword in this context leaves me scratching my head as you probably know that it doesn't allow you to define immutable maps, global or otherwise.

Re: Why I’m Frustrated with Go

#186

Post by justin66 »

It's an interesting point of view that regards those four items as necessary requirements for a data structure, and then regards the 24 lines of code needed to implement it as a massive "explosion of code." It would be interesting to know what language is considered the ideal tool for someone who looks at things that way. Something functional?

Re: Why I’m Frustrated with Go

#187

Post by japano1se »

fauigerzigerk wrote: post #185
japano1se wrote: post #175

Earlier quoted context omitted.

Don't move the goalposts. Global state is not the same issue as immutable data. And even if it was, Go has the `const` keyword anyway, making it entirely irrelevant to the OP article. This fad of using immutability everywhere and treating it like a silver bullet absolutely is new and is a fad.

The article isn't advocating "immutability everywhere". It complains about Go making it difficult to create immutable (or otherwise customized) data structures at all. So it is you who is moving the goalposts. I mentioned global mutable state as an anecdote and also as an example on one extreme end of the spectrum that should make it clear what the problem is in principle: Not knowing what code changes what state. Bu…

Thanks for the "no u".

One thing you're correct about: I have avoided debating it, because debating concepts like this is pointless and has nothing to do with real-world code. Which brings me back to the point I made on the article: why does he care so much that he can't have an immutable map? What problem can he not solve as a result of it? The example he's given is a toy problem, and the constraints that make him want such a thing are left unspecified.

Re: Why I’m Frustrated with Go

#188

Post by fnord123 »

sametmax wrote: post #76
seanwilson wrote: post #23

Earlier quoted context omitted.

> This is especially true when your system is interacting with external data - like user input and a database. I did C# and Java for years. These interactions are, at best, painful with static languages. Why? I find when you're importing external data or user input, that's exactly where you want strong types as that's the most likely place unexpected values are going to be generated (e.g. unexpected null values, stri…

Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict. As for data validation, the hard part of it is not checking type but that the value is safe and coherent. And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful. See marshmallow for Python: https://marshmall…

> Most modern dynamic languages have strong types. In Python you will get a TypeError if you try to add a string and an int or use > on a tuple and a dict.

>>> (1,2) > {1: 2} True

>And dynamic languages excel at that because they make complex declarative schema descriptions easy while powerful.

Marshmallow looks like it works the same way as existing systems in statically types languages. e.g. Serde in Rust:

https://serde.rs/

This validates at compile time.

Re: Why I’m Frustrated with Go

#189

Post by wott »

coldtea wrote: post #182
wott wrote: post #179

Earlier quoted context omitted.

For me, it goes like this: 1. What the heck is this thing everybody keeps talking about, with an impressive fancy name? It must a major step forward, after all this time, I should finally have a look at it. and then 2.a. Oh, it's just a big shiny name for something I accidentally kinda do sometimes, I didn't know it bore a name. Why is it suddenly a fad to base everything on this? or 2.b. Hmmm... right... so in C it…

Sounds like a case of the blub.

That's a reference to " rel="nofollow">http://wiki.c2.com/?BlubParadox>?

Possibly. But I use other languages, and I sometimes use a few of those other features in those languages, but I don't miss them at all when I come back to, let's say, C. They don't fit, or don't bring benefit, etc.

Re: Why I’m Frustrated with Go

#190

Post by fauigerzigerk »

japano1se wrote: post #187
fauigerzigerk wrote: post #185

Earlier quoted context omitted.

The article isn't advocating "immutability everywhere". It complains about Go making it difficult to create immutable (or otherwise customized) data structures at all. So it is you who is moving the goalposts. I mentioned global mutable state as an anecdote and also as an example on one extreme end of the spectrum that should make it clear what the problem is in principle: Not knowing what code changes what state. Bu…

Thanks for the "no u". One thing you're correct about: I have avoided debating it, because debating concepts like this is pointless and has nothing to do with real-world code. Which brings me back to the point I made on the article: why does he care so much that he can't have an immutable map? What problem can he not solve as a result of it? The example he's given is a toy problem, and the constraints that make him w…

>I have avoided debating it, because debating concepts like this is pointless and has nothing to do with real-world code.

It does have everything to do with my real world code. There is not a single piece of code I have ever written that let me get away with not keeping track of all the mutations that could possibly occur.

Let's leave aside complete immutability for a moment and consider a closely related issue that you can see in his code. He needs a map with defined iteration order, something I have needed occasionally in real world code.

He uses Go's builtin map type and a slice to define such a map. Now, how do you keep these two data structures in sync without restricting mutation? I think it's obvious that controlling mutation is a requirement here.

Go even admits that restricting access to data (i.e encapsulation) is necessary, and obviously preventing inconsistent mutation is a key reason why that is needed.

But then Go turns around and says, oh but you can't define fully featured data structures (i.e supporting range loops, type safety and indexing expressions) of your own that use encapsulation.

I have defended Go many times before, but the only way I can defend it is to say, yes it's true, this is a major weakness. We just don't know how to fix it without creating a lot of complexity elsewhere.

Post reply on HN