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

221–230 of 233 posts

Re: Why I’m Frustrated with Go

#221

Post by seanwilson »

sametmax wrote: post #220
seanwilson wrote: post #216

Earlier quoted context omitted.

I just don't find that personally. Having to run the code over and over again to manually check for errors or having to write unit tests to gain confidence it's working is more difficult to me than getting help from static type checking. I mean why do you think it's always going to be more difficult with static types? Because you have to write type annotations?

External data are never perfectly documented or known. You usually have huge and painful experimentation phase with parsing it. Experimenting is way easier with dynamic languages. You type less. Changing your mind has a lower cost. You don't need to think about doing the right things as much.

So in a statically typed language, if all I know is that I'm getting a string as input, it'll force me to deal with all the possibilities. Is it a number in the form of a string? A null value? A string that isn't a number? The type system will guide me through handling all the possibilities and enforce that I handle all of them. With dynamic typing, there's always a chance you've missed a case and next time the data comes in it'll trigger an exception.

If you have decent type inference there isn't extra typing and any time you think you're saving with dynamic languages gets eaten up having to manually fix things when errors happen at runtime. I'd much rather spend time fixing predictable compile time errors than unpredictable runtime errors.

Re: Why I’m Frustrated with Go

#222

Post by andrewjw »

xfer wrote: post #159
JamesMcMinn wrote: post #147

Earlier quoted context omitted.

No, YOU are still talking about immutable data structures, where as I am talking about the need to write boilerplate code in Go due to lack of Generics. The blog posts topic was not "immutable data structures", rather the need for boilerplate code in Go because of the lack of generics. The particular example was one of immutable data structures, however that was an example rather than the topic. The author themselves…

The comment i replied to : > No, Generics make it possible to create a generic immutable data structure I am sure i can read.

That was a reply to "Generics don't solve immutability" which was a reply to a post that did not contain the word "immutable" but does contain the word "generic"

James' comment you quote was responding to your comment, which he parsed generically as "Generics don't solve T", with a comment of the form, "Generics make it possible to implement a generic T."

I'm confident you can read, but I'm not so sure about your reading comprehension and critical thinking.

Re: Why I’m Frustrated with Go

#223

Post by masklinn »

ue_ wrote: post #218
masklinn wrote: post #129

Earlier quoted context omitted.

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

How is an error differentiated from a panic? Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal?

> How is an error differentiated from a panic?

I'm using them for the same purpose, but panic is rust-specific whereas error is not.

> Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal?

Technically it can be recovered from[0] but practically it usually should not be. Panics should not be used as an exceptions system. An OOB panic is basically a failed assertion. If OOB is a normal part of your operations, use a panic-safe access method (e.g. slice::get[1] which returns an Option)

[0] https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

[1] https://doc.rust-lang.org/std/primitive.slice.html#method.ge...

Re: Why I’m Frustrated with Go

#224

Post by zimpenfish »

brango wrote: post #195
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 +…

I've done my first project with go. Goroutines are undoubtedly cool and I like the strong typing. * Unfortunately error handling sucks (no stacktrace by default? Let's go back to the days of peppering print statements around just for fun). * DB support is terrible (I've spent hours doing what I could have done in half an hour with python). * It's so verbose, even simple things like mapping over an array to create ano…

I get stacktraces from `panic()` - is this not what you're after?

    goroutine 1 [running]:
    main.b()
        /home/rjp/git/godiggy/test.go:8 +0x64
    main.a()
        /home/rjp/git/godiggy/test.go:13 +0x9b
    main.main()
        /home/rjp/git/godiggy/test.go:18 +0x9b
    exit status 2

Re: Why I’m Frustrated with Go

#225

Post by ue_ »

masklinn wrote: post #223
ue_ wrote: post #218

Earlier quoted context omitted.

How is an error differentiated from a panic? Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal?

> How is an error differentiated from a panic? I'm using them for the same purpose, but panic is rust-specific whereas error is not. > Can a panic as is caused by the OOB situation I described be recovered from, or is it necessarily fatal? Technically it can be recovered from[0] but practically it usually should not be. Panics should not be used as an exceptions system. An OOB panic is basically a failed assertion. I…

Interesting, thank you.

Re: Why I’m Frustrated with Go

#226

Post by zimpenfish »

jorgec wrote: post #85
43224gg252 wrote: post #32

Earlier quoted context omitted.

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.

I interviewed for two Go jobs in London last month that were specifically building up Go teams for long term projects. It's definitely getting less niche by the month.

Re: Why I’m Frustrated with Go

#227

Post by jasonkostempski »

Ar-Curunir wrote: post #126
jasonkostempski wrote: post #70

Earlier quoted context omitted.

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?

But the way it's done in static languages​, it's one more thing you have to worry about constantly, even when it's not a real concern. And when you need to parse external data, all you get for free is ugly exceptions that you have to decipher to construct a user readable error.

Re: Why I’m Frustrated with Go

#228

Post by masklinn »

TheCoelacanth wrote: post #198
masklinn wrote: post #22

Earlier quoted context omitted.

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

So you can do it in Go in the same sense that you can do it in assembly language.

Exactly.

Re: Why I’m Frustrated with Go

#229

Post by xfer »

andrewjw wrote: post #222
xfer wrote: post #159

Earlier quoted context omitted.

The comment i replied to : > No, Generics make it possible to create a generic immutable data structure I am sure i can read.

That was a reply to "Generics don't solve immutability" which was a reply to a post that did not contain the word "immutable" but does contain the word "generic" James' comment you quote was responding to your comment, which he parsed generically as "Generics don't solve T", with a comment of the form, "Generics make it possible to implement a generic T." I'm confident you can read, but I'm not so sure about your rea…

I'm confident that you have no clue what you are talking about.

Re: Why I’m Frustrated with Go

#230

Post by brango »

zimpenfish wrote: post #224
brango wrote: post #195

Earlier quoted context omitted.

I've done my first project with go. Goroutines are undoubtedly cool and I like the strong typing. * Unfortunately error handling sucks (no stacktrace by default? Let's go back to the days of peppering print statements around just for fun). * DB support is terrible (I've spent hours doing what I could have done in half an hour with python). * It's so verbose, even simple things like mapping over an array to create ano…

I get stacktraces from `panic()` - is this not what you're after? goroutine 1 [running]: main.b() /home/rjp/git/godiggy/test.go:8 +0x64 main.a() /home/rjp/git/godiggy/test.go:13 +0x9b main.main() /home/rjp/git/godiggy/test.go:18 +0x9b exit status 2

I want to be able to handle errors, pass them up a few functions then log a stacktrace. I don't want to panic everywhere since robustness is important.
Post reply on HN