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

121–130 of 233 posts

Re: Why I’m Frustrated with Go

#121

Post by bjz_ »

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.

> 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.

"Safe" as in "memory safe". Panicking is better than allowing one to read into that memory. I would prefer panic-safe, but we might have to wait for a new dependently typed systems lang for that.

Re: Why I’m Frustrated with Go

#122

Post by meesterdude »

codegladiator wrote: post #117
pebers wrote: post #113

Earlier quoted context omitted.

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 ?

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

Re: Why I’m Frustrated with Go

#123

Post by nine_k »

pebers wrote: post #112

> 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…

Lombok takes care of most of such boilerplate in Java.

Code generating tools for Go also exist. The difference is that they produce source code, while things like Lombok, or any reasonable macro system, never surface intermediate code, unless explicitly asked.

Re: Why I’m Frustrated with Go

#124

Post by marcus_holmes »

I keep getting drawn back to Go.

I left it a while back, with a lot of the same frustrations. But then I tried a bunch of other things, and nothing seemed to work better. There seem to always be some frustrations with whatever language. And I found myself craving that simplicity again.

I might get annoyed with it again, and try some other stuff. And that might stick. But I suspect Go is the worst language except for all the others [1].

[1] http://www.goodreads.com/quotes/267224-democracy-is-the-wors...

Re: Why I’m Frustrated with Go

#125

Post by xfer »

JamesMcMinn wrote: post #17
NateDad wrote: post #15

Earlier quoted context omitted.

Generics don't solve immutability.

No, Generics make it possible to create a generic immutable data structure which can be used instead of re-writing the same boilerplate for every data type, which is the authors complaint.

You are still talking about immutable data structures, which has nothing to do with generics.

Re: Why I’m Frustrated with Go

#126

Post by Ar-Curunir »

jasonkostempski wrote: post #70
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…

No matter where the data comes from, there's so much more validation to be done that types can't handle. Why should validation concerns be split up?

It's one less thing to worry about, and cut out some tedious overhead for the developer?

Re: Why I’m Frustrated with Go

#127

Post by japano1se »

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…

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 state and continue to do so, and to learn how to do it differently would just be more trouble than it's worth, if not an outright regression.

This is the major problem I have with this sort of article; people never talk about languages in the context of actual working programs, just engage in dry theorizing or armchair programming. If the author put the complaint from this article into context, I'd not have a problem with it. But because it's a toy example with no relevance to actual programs people might want to write and use, it's unhelpful and misleading.

Re: Why I’m Frustrated with Go

#128

Post by Ar-Curunir »

masklinn wrote: post #30
dvirsky wrote: post #26

Earlier quoted context omitted.

I don't know specifically why that is for this specific project, but in general Go has GC and bounds checking that slow things down.

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

Using standard practices like iterators elides the bounds check, because the iterator is guaranteed to never go out of bounds.

Re: Why I’m Frustrated with Go

#129

Post by masklinn »

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.

> 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.

Er yes, it's safe as in memory-safe, as in an OOB will not own the entire application let alone machine. Error on OOB is a very common (if not quite universal) strategy — and incidentally also the one Go uses, the other primary one being returning null (which would be difficult in a language where most types are not nullable).

If you want panic-safe, use .get.

Re: Why I’m Frustrated with Go

#130

Post by nine_k »

masklinn wrote: post #22
rvense wrote: post #20

Earlier quoted context omitted.

Is it possible to write a reusable version of something like this in Go without using interface{}?

If "static codegen" is considered OK, then I guess yes, and I guess you can use The Thing[0] to even make them look like actual generics. Every user of the library will need to run codegen to post-process their source files and generate the relevant instantiations of the "generic" collection. [0] https://www.reddit.com/r/rust/comments/5penft/parallelizing_...

Then I could take almost any reasonable language, and transpile it to Go source. This worked for years for Javascript 5, and for C before that, and for Fortran even before that.

In either case, the reason was that the target language was considered not expressive enough, though ubiquitous.

Post reply on HN