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

81–90 of 233 posts

Re: Why I’m Frustrated with Go

#81

Post by ghthor »

doublerebel wrote: post #6

So, once upon a time I wanted to associate information with http connections (as I am accustomed to in every other language I've ever written) just to enable proper http keepalive and debugging through a proxy written in Go. Ended up with this. [0] Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib. I still appreciate many go tools and the cross platform single…

Seems like you got work done by altering the stdlib because it was approachable enough to alter. I don't see what the complaint is here.

Re: Why I’m Frustrated with Go

#82

Post by humanrebar »

searealist wrote: post #43
humanrebar wrote: post #12

> 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. Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. Also, to provide good 'const' support in containers, you usually have to provide extra read…

> Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. const std::set & s // This is a read-only view. const std::set s // This is immutable. > Another approach is to just declare member variables 'const'. So you have a 'const map ' as a member variable. Except for that to work, you n…

> const std::set s // This is immutable.

> Foo() : s(helper()) {} // This is a move, not a copy.

First, I'll point out that the data of s is not immutable. The fact that you can const_cast away the const and change the value makes that clear. If people do things like that (or corrupt memory or have race conditions in the code), C++ doesn't necessarily give you clear exceptions or compiler errors. Many of the ways to break things result in "undefined behavior", which might involve data corruption and crashes. I've seen both happen to 'const' objects in production code.

You have a fair point about the move. But not all projects are using C++11 yet. And your use of a 'helper()' builder was actually part of my point as well. The article complained about all the extra code needed in Go to do immutable maps. But it's not true that in C++ you can just add 'const' to a few spots and move on.

I'll also point out that having the 'const' member in 'Foo' likely makes it impossible to implement assignment operators and possibly a move constructor, depending on what you are doing. It's likely if you want to have read-only semantics in your data in C++, you'll have to be aggressive using unique_ptr and shared_ptr so that you can have things like proper move semantics. And that means you'll likely need to be checking for null data.

Point being, you can achieve read-only semantics in C++. But it's not foolproof and it's not as clean as the article seems to imply.

Re: Why I’m Frustrated with Go

#83

Post by searealist »

humanrebar wrote: post #82
searealist wrote: post #43

Earlier quoted context omitted.

> Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. const std::set & s // This is a read-only view. const std::set s // This is immutable. > Another approach is to just declare member variables 'const'. So you have a 'const map ' as a member variable. Except for that to work, you n…

> const std::set s // This is immutable. > Foo() : s(helper()) {} // This is a move, not a copy. First, I'll point out that the data of s is not immutable. The fact that you can const_cast away the const and change the value makes that clear. If people do things like that (or corrupt memory or have race conditions in the code), C++ doesn't necessarily give you clear exceptions or compiler errors. Many of the ways to…

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

Re: Why I’m Frustrated with Go

#84

Post by lobster_johnson »

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?

But that depends on what you're trying to accomplish. It's intended as a high-level, general-purpose server. It will always lack features if you go advanced enough.

Re: Why I’m Frustrated with Go

#85

Post by jorgec »

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.

In reality, Go is a language that practically no one gets paid to use. Go is niche and the few projects around here are short term.

Re: Why I’m Frustrated with Go

#86

Post by [deleted] »

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…

[deleted]

Re: Why I’m Frustrated with Go

#87

Post by masklinn »

barrkel wrote: post #51
43224gg252 wrote: post #18

Earlier quoted context omitted.

>I found it a chore to maintain Go-based systems My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week. I don't have much…

> This is almost always unacceptable in production, This is not true for almost all software outside of embedded domains. In fact responding to an error near where the error occurred is almost always a mistake. The rare exceptions to this are when "error" is unavoidable due to concurrency (e.g. I/O), and even then many errors shouldn't be handled (misconfiguration, incomplete system initialization, etc.) or should be…

> If you support this position, you'd support checked exceptions like Java - something that's widely considered a mistake.

The primary problem of checked exceptions in java is not that they exist, it's that they are very badly integrated with the rest of the language e.g. it's impossible to be generic or transparent over checked exceptions, their hierarchy is messy and it's often unclear why specific exceptions are checked and others unchecked. Haskell's error handling (reified through Either error values) has similar effective semantics but nowhere near the dislike because it's well integrated in the language and you can be generic over the error, the value, and the result itself.

Re: Why I’m Frustrated with Go

#88

Post by humanrebar »

blub wrote: post #75
searealist wrote: post #43

Earlier quoted context omitted.

> Actually C++ doesn't have immutable data unless you count compile-time constants and literals. You can declare things 'const', but that only provides a read-only (1) view on mutable data. const std::set & s // This is a read-only view. const std::set s // This is immutable. > Another approach is to just declare member variables 'const'. So you have a 'const map ' as a member variable. Except for that to work, you n…

Yes, humanrebar is really grasping at straws. :) I would also mention that using mutable and const_cast is frowned upon and it can be trivially searched for and forbidden. Their comment about const iterators also misses the mark. Yes, the designers of the C++ standard library did a bit more work and now everyone has a high-quality type-safe dictionary implementation available. That's how it's supposed to work...

> 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 the compiler will give you nice diagnostic errors if you do mutable things to 'const' things. There aren't any guarantees about the data itself being unchanged.

> the designers of the C++ standard library did a bit more work

My point was that all container implementations need to do the same work if they want both const and non const iterators. You can't just return 'const iterator' from you 'begin' method because that implicitly converts to a non const 'iterator' and a mutable view of your container.

> Yes, the designers of the C++ standard library did a bit more work and now everyone has a high-quality type-safe dictionary implementation available.

I very much appreciate the hard, mostly unpaid, work that people put into the C++ standard. But everyone has to do a bit more work if they want, say, a read-only key-value store laid out in contiguous memory. The standard key-value stores are a pretty straightforward rb-tree and a suboptimal (to allow for iterator semantics) hash table. It's not hard to implement (again, due to hard work from the standard committee) a sorted vector>. It's a bit of arcane work, however, to make that optionally const or to have it share an interface with map and unordered_map.

Re: Why I’m Frustrated with Go

#89

Post by jorgec »

dullgiulio wrote: post #41
43224gg252 wrote: post #18

Earlier quoted context omitted.

>I found it a chore to maintain Go-based systems My opinion is the opposite. Almost every go code base I've seen is extremely consistent compared to other languages. Going from one code base to another is almost always seamless because learning Go involves learning the Go tools which forces you to follow Go coding standards. I'd choose to work on a Go code base over Java or C++ any day of the week. I don't have much…

>> the entire error thing is absurd. Anders Hejlsberg got th is right many years ago: 9 out of 10 errors are "handled" by a central error handler > This is almost always unacceptable in production, especially when it comes to mission critical hard/software. You need to be able to handle errors in production that you may not even be able to catch in testing and that means you need to catch all the errors and think cri…

When you wrap the error then you are kicking it out. Sooner or later you must catch the error. So, in most case, its just delaying the inevitable.

Re: Why I’m Frustrated with Go

#90

Post by doublerebel »

ghthor wrote: post #81
doublerebel wrote: post #6

So, once upon a time I wanted to associate information with http connections (as I am accustomed to in every other language I've ever written) just to enable proper http keepalive and debugging through a proxy written in Go. Ended up with this. [0] Turns out the Go authors don't think you should do this so I had to majorly alter and recompile the stdlib. I still appreciate many go tools and the cross platform single…

Seems like you got work done by altering the stdlib because it was approachable enough to alter. I don't see what the complaint is here.

If you actually take a look at the many changes that had to be made due to the uncreative limitations imposed by Go, you'll see that it was was neither approachable nor maintainable. I'm just stubborn and found it hard to believe it would actually take that much work until I tried it.

This is supported by the fact that contexts have been added, and I won't be surprised to see Go reverse more of their decisions as the language grows and devs prioritize shipping over Go dogma.

Post reply on HN