Re:Show HN: My notes on Working with Go
by jbreckmckye on Monday August 24, 2020 @07:52AM
(#24259736)
> so you wrote one micro-service and came to that conclusion?
To be fair, that's a lot more empiricism than some teams use.
Re:Show HN: My notes on Working with Go
by throwaway894345 on Monday August 24, 2020 @09:59AM
(#24260684)
I'm a big fan of ML-like type systems, but I never understand why Go gets so much more grief than Python, JS, etc for having nil. At least in Go, only reference types can be nil as opposed to literally any variable. Same with conversation about generics: "How can anyone write software in a language without [type-safe] generics?" of course lots of profitable software is written in languages with no type safety whatsoever and that doesn't seem to bother people.
Re:Show HN: My notes on Working with Go
by AnimalMuppet on Monday August 24, 2020 @01:39PM
(#24263147)
I think that it doesn't bother people when a non-type-safe language isn't type safe. If you reach for Python, you know what you're getting. But when a type-safe language is type-safe-except-for-X, that bothers people who wanted a type-safe language.
And it's one thing if the except-for-X is "except for conversions", like casts in C, C++, and Java. Non-type-safe generics aren't usually a place where you are deliberately bypassing the type safety; they're a place where you'd like to have the type safety you have everywhere else in the language.
Re:Show HN: My notes on Working with Go
by throwaway894345 on Monday August 24, 2020 @03:52PM
(#24264742)
I don’t buy this at all. No one finds out that Go lacks generics when they’re neck deep in a project, it’s widely known ahead of time. If you need something that is type-safe >95% of the time, Go isn’t the answer (yet, anyway) and you rule it out before the first line of code is written and move on to other languages (of course, lots of life-or-death applications are written in C which has a weaker type system than Go, so I would also be skeptical about applications that need >95% type safety).
For what it's worth, I've been programming with Go professionally for a few years, and I do agree with the "null" issue. Although in practice - with a good development culture - it's less of a problem than you might think initially. We tend to avoid using pointers (because, they're not even faster than structs in _many_ instances. They don't work like pointers in C/C++).
By avoiding pointers you also avoid `nil` being a thing. but if not having nil is a strict requirement I'll pick another language like Haskell instead. Pick the right tool for the job yada yada