Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: My notes on Working with Go

github.com

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Show HN: My notes on Working with Go

#11

Post by hombre_fatal »

rsa25519 wrote: post #5
bruhlollol wrote: post #4

Note nº 1: don't!

Care to elaborate?

Do we really need to entertain throwaway accounts created just for the boring "lang {good,bad}!" interjection?

If you want to see it, there are so many places we have that discussion. And that discussion can be found so many times online. Look at any Go version release on HN if you want to find more.

Even making a top-level comment like "Can anyone explain some quick pros/cons of $lang?" would go farther than these interjections where we need to prod them with twenty questions just to help them flesh out their own point of view. That's what's annoying about it.

Re: Show HN: My notes on Working with Go

#13

Post by xcbl »

hombre_fatal wrote: post #11
rsa25519 wrote: post #5

Earlier quoted context omitted.

Care to elaborate?

Do we really need to entertain throwaway accounts created just for the boring "lang {good,bad}!" interjection? If you want to see it, there are so many places we have that discussion. And that discussion can be found so many times online. Look at any Go version release on HN if you want to find more. Even making a top-level comment like "Can anyone explain some quick pros/cons of $lang?" would go farther than these i…

99.99% of the boring $lang_is_superior "discussions" is by people without throwaway accounts. These people are also often more aggressive and indoctrinated.

Re: Show HN: My notes on Working with Go

#14

Post by Cthulhu_ »

bruhlollol wrote: post #6
rsa25519 wrote: post #5

Earlier quoted context omitted.

Care to elaborate?

It ignores some historical bad design decisions, the worst of them being having null in the language, the famous one billion dollar mistake. And well, no support for functional/immutable data structures is something I dislike. My squad did a micro-service in Go at work and was not pleasant as we expected.

Null is only a thing for pointers, in a lot of cases you can use value types where they use a sane "zero" value for everything by default.

But did you really create a new troll account to go and represent the Rust Evangelism Squad? I mean if you really want to discuss the merits of Rust vs Go, at least have the decency to do a writeup that doesn't repeat the same - known - issues with Go.

Re: Show HN: My notes on Working with Go

#16

Post by hombre_fatal »

xcbl wrote: post #13
hombre_fatal wrote: post #11

Earlier quoted context omitted.

Do we really need to entertain throwaway accounts created just for the boring "lang {good,bad}!" interjection? If you want to see it, there are so many places we have that discussion. And that discussion can be found so many times online. Look at any Go version release on HN if you want to find more. Even making a top-level comment like "Can anyone explain some quick pros/cons of $lang?" would go farther than these i…

99.99% of the boring $lang_is_superior "discussions" is by people without throwaway accounts. These people are also often more aggressive and indoctrinated.

There is no shortage of Go users, like myself, that can admit to the downsides of it. That's why there's always the same debates about things like sum types and generics and interface{} and null pointer errors in every Go thread. And even in the recent submission where Go implements provisional generics, we go on to point out the downsides of it, like how you're still stuck with null pointers to represent sum types (like an imagined Result impl). And it's pretty good discussion.

I mean, the throwaway accounts so far aren't exactly raising the bar of discussion here. So far it's extremely elementary. Is this the discussion you think we're missing out on without throwaway accounts? Maybe if we keep prodding you/them for more info, they'll flesh out a novel point? Time to shit or get off the pot.

Re: Show HN: My notes on Working with Go

#18

Post by isatty »

bruhlollol wrote: post #10
colesantiago wrote: post #7

Earlier quoted context omitted.

what language do you suggest instead of go?

Rust is a better choice

It depends on _for what_. The most important part of these discussions often leaves out this important part.

I use go as a python replacement for the most part and it’s brilliant at it. Types, compiled, good collection of external libraries and easy to read. For most of my scripting or mini projects I’m not willing to use C++ and by the same thought, I’m not willing to use rust either.

Re: Show HN: My notes on Working with Go

#19

Post by bruhlollol »

Cthulhu_ wrote: post #14
bruhlollol wrote: post #6

Earlier quoted context omitted.

It ignores some historical bad design decisions, the worst of them being having null in the language, the famous one billion dollar mistake. And well, no support for functional/immutable data structures is something I dislike. My squad did a micro-service in Go at work and was not pleasant as we expected.

Null is only a thing for pointers, in a lot of cases you can use value types where they use a sane "zero" value for everything by default. But did you really create a new troll account to go and represent the Rust Evangelism Squad? I mean if you really want to discuss the merits of Rust vs Go, at least have the decency to do a writeup that doesn't repeat the same - known - issues with Go.

I am not evangelist. Go error handling and pointers could be type safe, that's my real disappointment with it. I like its simplicity, but having a sane zero value for "almost everything" doesn't solve the problem.

Re: Show HN: My notes on Working with Go

#20

Post by vips7L »

bruhlollol wrote: post #10
colesantiago wrote: post #7

Earlier quoted context omitted.

what language do you suggest instead of go?

Rust is a better choice

While I am no fan of Go, Rust is not a better alternative for most use cases of the average Go program. A better alternative would more likely be Java/Kotlin/Scala/C#. All with proper generics, good standard libraries/ecosystems, and fast run times.
Post reply on HN