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

351–360 of 614 posts

Re: Go 1.18

#351

Post by saurik »

jshen wrote: post #327
munificent wrote: post #290

Earlier quoted context omitted.

There's a lot of developers that misuse/shouldn't use any powerful feature. If the solution is to give them a nerfed language, then you also nerf it for the users that would use the feature well in productive, useful ways.

Yes, it’s a trade-off. In an organization with thousands of developers the right trade-off is likely different than an org with 20. What I don’t understand is why people insist on making Go like every other language that already does what that are looking for. You want a language with generics, purely functional blah blah blah, great there are tons of choices, use one of them. Why insist on reducing the diversity in…

This is what policies are for, not entirely new languages: if you don't like generics and don't trust the end developers at your organization to not use them in stupid ways you should maybe (I say "maybe" as this problem just seems so lame of a problem to have: if your army of end developers can't be trusted then you should fire them and hire some real developers) have a way to turn off generics that isn't "use a language that doesn't support them at all" (which I will note is itself nothing more than a policy decision anyway).

Re: Go 1.18

#352

Post by hodgesrm »

codeflo wrote: post #340
preseinger wrote: post #287

Earlier quoted context omitted.

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.

That’s true, a binary tree isn’t a problem, it’s a tool for solving a certain class of problems. Since you can’t build reusable tools in pre-generic Go, (and, to be honest, only a limited set of tools with Go’s new generic system), programmers are forced to reinvent half-baked ad-hoc solutions all over their code base. I once read an article about a C codebase that contained dozens (!) of specialized linked-list impl…

Specialized collections are not necessarily bad. ClickHouse has dozens of hash table implementations, each tuned to a specific use case. It's what you do when you need something to go very fast.

Re: Go 1.18

#353

Post by int_19h »

uryga wrote: post #300
LAC-Tech wrote: post #276

Earlier quoted context omitted.

What's do notation? I've used optionals in many languages, and this is the first I've heard of it. What else do you really need except map and... flatMap (aka `then` aka `and_then` aka `>>=` aka `bind`).

https://en.m.wikibooks.org/wiki/Haskell/do_notation rough analogy: `await` replaces `.then()`, do-notation replaces `.flatMap()`

C# has had Nullable for many years before it got stuff like ?. and ?? that mostly covers this, and it was, well, tolerable.

Re: Go 1.18

#354

Post by throwaway894345 »

mcronce wrote: post #338
throwaway894345 wrote: post #279

Earlier quoted context omitted.

> All three of these things are subjective. Not really. They aren’t formally defined, but there’s pretty wide consensus even among Go detractors about these qualities. > At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is. Not when there are plenty of people willing to think differently and reap the benefits.

lol...you even take criticism arrogantly. Impressive. It wasn't a personal attack, it was a statement of fact, but thanks for making my point even more clearly for me - not only in your response to that, but in your assertion that your opinion based on your experience is fact . Appreciated. Restated: You aren't arrogant because you disagree with me. You're arrogant because the things you say and the way you say them…

Look, I’m not interested in a slapfight. Enjoy your evening.

Re: Go 1.18

#355

Post by int_19h »

cardanome wrote: post #268
zinclozenge wrote: post #193

Earlier quoted context omitted.

None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…

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?

Re: Go 1.18

#356

Post by int_19h »

yawaramin wrote: post #305
zinclozenge wrote: post #193

Earlier quoted context omitted.

None with the same performance characteristics, ease of use, and ecosystem size. I'm reasonably competent with Rust, but sometimes I don't want to bash my head against the borrow checker or litter my code with copy/clone. Go hits a nice sweet spot, my main quibbles are that there's no native iterators/comprehensions or sum types with compiler checked exhaustive matching. With generics we can get libraries that allow…

Rust isn't a functional programming language. You could try OCaml, it's kind of a halfway point between Go and Haskell.

Rust has first-class functions. Not only that, but it also has immutability by default, and ADTs with pattern matching. If OCaml is functional, why wouldn't Rust be?

Re: Go 1.18

#357

Post by philosopher1234 »

mcronce wrote: post #337
philosopher1234 wrote: post #328

Earlier quoted context omitted.

It seems like it does to me. Why doesn't it?

Because not all statements apply to all situations.

This is really vague and unhelpful. I’m going to interpret this to mean you’re not interested in actually explaining the problem, sorry if I’m mistaken.

Re: Go 1.18

#358

Post by int_19h »

lawl wrote: post #298
pkulak wrote: post #71

Earlier quoted context omitted.

I can never seem to understand why a GCed language has pointers, and makes you memorize when to use stack vs heap.

Hits the sweet spot for me between the one extreme of having to malloc/free everything myself and the other extreme where everything is immutable, garbage collected and you dont know what causes allocation. The former is a nightmare for security and productivity, the latter is a nightmare for performance.

Go can implicitly heap-allocate even a local variable if you e.g. capture it in a closure. This is actually more implicit than you get in Java or C#.

Re: Go 1.18

#359

Post by int_19h »

dgb23 wrote: post #173
rochak wrote: post #169

Earlier quoted context omitted.

I have already started having trouble understanding open source code using generics. I can see the upsides of having generics, but have lost the enthusiasm with which I used to browse Go code. I am still a junior engineer, so maybe it will get better with time.

Every abstraction tool will get misused, especially early on. I bet the Go community will figure out how ways to mitigate that in the long run, given it’s culture around readability.

Also, I think that a lot of supposed "misuse" that people are complaining about is actually using the right tool for the job, and the complaints stem from treating the tool itself as inherently too complicated (and thus any use of it as automatically suspect) because it's new and not conceptually trivial.

There was a lot of that back when Java and C# first got their generics.

Re: Go 1.18

#360

Post by int_19h »

ArchOversight wrote: post #246
AaronFriel wrote: post #64

My favorite feature is a tiny, couple line bug fix that I pushed hard to get included during the feature freeze. Full details here, but a summary is below: https://github.com/golang/go/issues/51127 For the past ~8 years, many hundreds of people reported on GitHub - and likely many multiples more have encountered and not reported - a program that didn't work with the error "cannot unmarshal DNS..." This error seems to…

I wish I had your time and effort to be able to fix the issues of split DNS in macOS being broken unless using cgo. https://github.com/golang/go/issues/12524 This has been an open issue since 2015. It's a pain because every single last tool using go cross compilation fails to use the proper DNS resolver and thereby doesn't work when using work VPN's. This is tools like: kubectl, vault, concourse (fly), and many other…

A better question is, why is Go using its own DNS resolver instead of the OS-provided one in the first place?
Post reply on HN