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

Go 1.18

go.dev

Post reply on HN
Print view View original

381–390 of 614 posts

Re: Go 1.18

#381

Post by movedx »

rr808 wrote: post #364
movedx wrote: post #303

Earlier quoted context omitted.

I don't consider those kinds of people engineers at all. They're people who have learned a syntax, some patterns and, thanks to their human brain, can adopt it slightly to certain situations. But they're not engineers. Engineers constantly ask why, explore the unknown and are aware of almost all possible solutions available to them. using this knowledge they select the correct tools and build the solution. What you'v…

Engineers are people who can create a solution to a problem in an efficient and effective way. Specialists who know every detail are craftsmen who can create the best possible solution but they aren't necessarily good engineers.

> Engineers are people who can create a solution to a problem in an efficient and effective way.

How do you create an "efficient" and "effective" solution if you're not aware of as many options as possible, i.e. fuzzing for security vulns?

How is your solution "effective" if I can throw a bunch of Unicode at an input field and crash your application because the "engineer" didn't know what fuzzing is?

Re: Go 1.18

#382

Post by int_19h »

robocat wrote: post #313
rob74 wrote: post #99

Earlier quoted context omitted.

What people don't realize is that the simplicity of the language also contributes to the compilation speed, so adding features to the language at the same rate as other projects (that I don't want to mention here) would jeopardize one of Go's major advantages.

The syntactic choice of using square brackets instead of angle brackets for generics appears to be due to optimising for parsing. User clarity is decreased to allow for code optimisation IMHO. From https://groups.google.com/g/golang-nuts/c/7t-Q2vt60J8 the following: Angle brackets require unbounded parser look-ahead or type information in certain situations (see the end of this e-mail for an example). This leaves us…

How does using [] for generics decrease user clarity? They're both just grouping characters. If the argument is that [] is easy to confuse with indexing, then by the same token is also easy to confuse with comparison operators.

One could also argue that [] is the better choice precisely because it is similar to indexing a map - a generic type can be seen as a map of types to other types.

Re: Go 1.18

#383

Post by stouset »

squeaky-clean wrote: post #365
throwaway894345 wrote: post #332

Earlier quoted context omitted.

> I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' Who says this? There have been a lot of weird arguments surrounding Go and generics over the last decade, but I’ve never heard anything like this.

As a non-Go user who peaks into threads about major Go updates, this is one of the most commonly repeated things I've read.

It's a point that's been made repeatedly as comments on this very article.

Re: Go 1.18

#384

Post by int_19h »

stouset wrote: post #185
keybored wrote: post #107

Earlier quoted context omitted.

This comment has the tone of being genuinely inquisitive, yet it mostly comes up with negative and depraved reasons for as to why someone one might dislike $lang. - Rational reasons (frustrations with the language design) are briefly acknowledged but then some reason left by the wayside - It is suggested that people don't have principled objections to $lang; they will "latch onto" something else if $misfeature is fix…

This needs to be higher up, and summarizes my main cultural oppositions to golang. I'll also add: - Extensive laundry lists of frustrations, sharp edges, antipatterns, and ways the language makes it trivial to write incorrect code are dismissed as nits or minor annoyances. - Missing features that have no way of being worked around are dismissed off-hand as unnecessary complexity. - The language authors repeatedly ign…

> Missing features that have no way of being worked around are dismissed off-hand as unnecessary complexity.

You forgot to add the part where, once the features are added after all, they stop being "unnecessary" complexity :)

Re: Go 1.18

#385

Post by int_19h »

stouset wrote: post #160
philosopher1234 wrote: post #3

This is very exciting! Generics will be helpful for some, I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. I would like to understand a bit more about where a lot of the Go criticism comes from. Of course some amount of it comes from direct frustrations people have with the lan…

> I'm sure, but my reading of the winds is that people will find other idiosyncracies of Go to latch onto and complain about. It seems to me the next object of hatred is the lack of sum types. This is a needlessly dismissive perspective. Put another way, now that one of golang's most prominent deficiencies has been addressed, people will switch their focus to other areas of frustration. > Sometimes I think the core i…

> this simplicity just kicks the cans of complexity and verbosity downstream onto its users

I still think that append() is the arch-example of that. I can't think of another high-level PL that doesn't have an atomic add-item-to-collection operation (either in the language or in stdlib) without requiring the user to coordinate all the moving parts.

Re: Go 1.18

#386

Post by int_19h »

throwaway894345 wrote: post #63
mcronce wrote: post #35

Earlier quoted context omitted.

While true, that doesn't really change the situation for the individuals who require

No one meaningfully "requires generics", people are just reluctant to set their ego aside and learn a different approach. Some use cases may benefit from generics, but even then "require" is too strong.

You can dig a hole of any size with a shovel, given enough time. But I wouldn't fault people who refuse to dig a large hole with a shovel after they've seen an excavator at work.

Re: Go 1.18

#387

Post by diehunde »

preseinger wrote: post #287
pie_flavor wrote: post #277

I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' as it solves a problem that has resulted in an absolutely ludicrous amount of weird boilerplate garbage code. You're not trading off generic code vs non-generic code. Problems are generic. For solving generic problems , you're trading off the generic code that best expresses them, for codegen, dynamic downcasting,…

Problems are not generic. "I need a N-ary binary tree over arbitrary comparable types" is not a problem. Problems are expressed in terms of domain concepts that are unique to the problem space, the organization, the business need. Some _implementation details_ or maybe patterns that can be used to solve those problems may be generic. That's separate.

Go is used a lot for systems programming where you do see those problems.

Re: Go 1.18

#388

Post by stouset »

drdaeman wrote: post #162
mseepgood wrote: post #105

Now Go has everything I need in a programming language!

Not for me. There is no ?: ternary operator. Having to write 6 additional lines of code for each tiny conditional sucks. It's not frequent, I think I've only had a single case in a few years where I had difficulty working around, but when it happens - it's not fun. err := h(cond(x) ? f(x) : g(x)) vs var temp T if cond(x) { temp = f(x) } else { temp = g(x) } err := h(temp) Hopefully, this can be improved with generics…

Frankly I'd kill for go statements to be expressions, which essentially solves this.

    foo := if a { b } else { c }

Re: Go 1.18

#390

Post by chakkepolja »

int_19h wrote: post #355
cardanome wrote: post #268

Earlier quoted context omitted.

Ocaml. Insanely fast compiler. Great type system. Functional programming at its best but still relatively pragmatic and easy to mix in some imperative code if need be. It is a bit more complicated than Go and the ecosystem is maybe a bit more patchy but other than you will have a good time.

Ocaml is not particularly fast, for a compiled language. Is Go really slower?

(not GP)

>> fast compiler

But yeah everything is fast at runtime as well when you coming from JS and python.

Post reply on HN