Why I’m Frustrated with Go • Hacker News Board

Re: Why I’m Frustrated with Go

#111

Post by dmit » Sun, Jul 23, 2017, 2:02 PM UTC

dvirsky wrote: post #67

pimeys wrote: post #38

Earlier quoted context omitted.

I would think having better safety guarantees is a big reason. Rustc can detect data races, which I'd say it's very useful with an Ethereum client.

Go can detect data races as well, not sure it's the reason. Probably performance.

Go may detect data races if your test suite triggers them and you opt in to use the race detector.

Rust rejects programs with data races unless you opt out by explicitly marking code in question as unsafe.

Quite a bit of a difference there.

Re: Why I’m Frustrated with Go

#112

Post by pebers » Sun, Jul 23, 2017, 2:03 PM UTC

> You know how much code I’d have to write if this were C++, C#, or Java? None. They all have reusable notions of an immutable, ordered map.

Java doesn't do that well at all though; its immutable maps can be used in place of mutable maps, since there's no way of having a Map interface that extends ImmutableMap to add extra operations, so you can get nasty runtime surprises if you've got the wrong one. Conversely, if you want a mutable map keyed on a non-trivial structure, you have to do just as much boilerplate as the author complains about to set up private members, setters, builders, etc.

Obviously C++ can do it quite readily, but nobody accused it of lacking features.

This is really just another use case for generics, and the discussion there is well-trodden. Go probably isn't the language for you if you value generics more highly than fast compile times, native binaries, etc, but I'm not sure why that still seems to come as a surprise.

Re: Why I’m Frustrated with Go

#113

Post by pebers » Sun, Jul 23, 2017, 2:06 PM UTC

meesterdude wrote: post #73

lobster_johnson wrote: post #63

Earlier quoted context omitted.

That's more a criticism of the standard HTTP server, which is a bit of a black box, apparently intentionally. There's nothing wrong with writing your own server to make up for it's limitations.

except for the fact that you shouldn't have to write your own server?

Why not? Plenty of languages don't come with one built in at all, or not one widely used in production (e.g. Python's http.server, there are a heap of other Python web servers out there).

Re: Why I’m Frustrated with Go

#114

Post by humanrebar » Sun, Jul 23, 2017, 2:10 PM UTC

blub wrote: post #102

humanrebar wrote: post #88

Earlier quoted context omitted.

> humanrebar is really grasping at straws. :) On the contrary, I've had to mentor a lot of C++ developers where they were surprised when their put-const-on-it approach to providing safety resulted in production bugs. I think it's fair for people to be surprised by this sort of thing. And I don't think the things Go developers have to do are all that much worse than equivalent code in C++. In C++, 'const' mostly means…

Context is everything. If you come in the middle of a topic about declaring a bog-standard map and start discussing the subtleties of const, container design and the map implementation you will confound people and are frankly off-topic. :) I mean the discussion was about declaring a simple map. In that context, it really is as easy as writing const std::map map; Go can't do that. C++ can do that. Seems pretty straigh…

That's basically only useful as a stack variable, though, which was my point. Well, that and "immutable" in the context of C++ is misleading.

It was on topic because I am saying the C++ boilerplate wouldn't really be better than the Go boilerplate. All the "out of context" details are basically my point. You need to know a lot of surprising things to C++ well.

Re: Why I’m Frustrated with Go

#115

Post by nine_k » Sun, Jul 23, 2017, 2:18 PM UTC

43224gg252 wrote: post #32

thinbeige wrote: post #27

Earlier quoted context omitted.

> I don't have much experience with elixir, but that's because I like to stay employed. While the previous commenter gave an objective and rational overview why he think Go gives him a hard time you can't resist to get polemic.

I gave rational counter arguments and employment is pretty important too imo. It seems a lot of the anti-Go people tend to favor languages that no one gets paid to use.

You should stick with Cobol. It paid the developers for 60 years, and has a very fair chance to continue commanding reasonably good salaries for another 20 or 30.

Maintaining Cobol code is a chore, though, partly for the same reasons as Go code.

Re: Why I’m Frustrated with Go

#116

Post by codegladiator » Sun, Jul 23, 2017, 2:19 PM UTC

> That’s an infuriating amount of code to write

24 lines, really ?

Re: Why I’m Frustrated with Go

#117

Post by codegladiator » Sun, Jul 23, 2017, 2:20 PM UTC

pebers wrote: post #113

meesterdude wrote: post #73

Earlier quoted context omitted.

except for the fact that you shouldn't have to write your own server?

Why not? Plenty of languages don't come with one built in at all, or not one widely used in production (e.g. Python's http.server, there are a heap of other Python web servers out there).

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 ?

Re: Why I’m Frustrated with Go

#118

Post by meesterdude » Sun, Jul 23, 2017, 2:22 PM UTC

pebers wrote: post #113

meesterdude wrote: post #73

Earlier quoted context omitted.

except for the fact that you shouldn't have to write your own server?

Why not? Plenty of languages don't come with one built in at all, or not one widely used in production (e.g. Python's http.server, there are a heap of other Python web servers out there).

when you set out to solve a particular problem, do you really think its a worthwhile use of your time and effort to create a webserver? Mind you i'm not talking so much about "built-in" webservers than I am about reusing an existing, battle tested one from a 3rd party (e.g. OSS) so you can focus on the actual problem your trying to resolve.

Re: Why I’m Frustrated with Go

#119

Post by searealist » Sun, Jul 23, 2017, 2:22 PM UTC

humanrebar wrote: post #92

searealist wrote: post #83

Earlier quoted context omitted.

const std::set s; // This is immutable. const_cast &>(s).emplace(); // This is UB.

And what do the assignment operators of Foo look like?

I'm fixing your incorrect understanding of how const works in C++ and you are choosing to be argumentative.

Re: Why I’m Frustrated with Go

#120

Post by kuschku » Sun, Jul 23, 2017, 2:22 PM UTC

43224gg252 wrote: post #60

kuschku wrote: post #54

Earlier quoted context omitted.

But you still have to write the function a hundred times — once each for every immutable map you'll use. This is the opposite of DRY.

Go also supports libraries.

Go doesn’t really support libraries of data structures and containers, though. You can’t build a library of different kinds of immutable and mutable maps, trees, etc that are reusable – precisely because generics are missing.