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

481–490 of 614 posts

Re: Go 1.18

#481

Post by lmm »

int_19h wrote: post #356
yawaramin wrote: post #305

Earlier quoted context omitted.

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?

Rust doesn't really have first-class functions - you can't take an arbitrary snippet of code and turn it into a function value, because sometimes it will no longer pass the borrow checker.

Re: Go 1.18

#482

Post by morelisp »

stouset wrote: post #241
CraigJPerry wrote: post #228

Earlier quoted context omitted.

>> generics reduce complication That goes against the definition of the word complication. To complicate something is to combine and intertwine it with other concerns. To fold them together is to complicate them. To generify a function is to complicate it with the ability to accept multiple types rather than just one. There are totally great use cases for generics but all the cases I’ve seen are in library code not i…

As a general rule, if you're referencing the dictionary definition of a word to make your point, you're just playing semantic games. You know what people also find complicated? Hundreds of lines code being repeated with superficial edits because of golang's lack of ability to abstract higher-level ideas. It's a stupid toy example, but for a very large number of people nums.take(20).select(&:odd).reduce(&:+) is less c…

There are two bugs in the code, and your (intentional?) use of non-idiomatic Go is the cause of one of them. Since you don't mention it in your follow-up comment I assume you didn't mean to write it in the first place.

Still, there is a middle ground that remains both efficient and readable:

    sum := 0
    for _, v := range take(20, nums) {
        if v % 2 == 1 { // or if odd(v), if you like
            sum += v
        }
    }
I'd venture most of the clarity come from the generic take (specifically, being able to implicitly take min(len(nums), 20)), not the generic filter/reduce. The second point of clarity comes from Ruby's dynamic method dispatch and large method set on numeric types; no thanks. Only as a third-tier aspect does select/reduce come into play, and I think that one is much more questionable (e.g. reduce or fold, and either way how do I explain this name to new programmers? -- and &:+, what a messy identifier).

Re: Go 1.18

#483

Post by int_19h »

srer wrote: post #439
int_19h wrote: post #382

Earlier quoted context omitted.

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.

It certainly does for me. It ties into this quote: > Why not use the syntax F like C++ and Java? A great number of us are used to seeing rather than [] for generics. It would seem limitations in Go's parser outrank a popular norm.

If you look at some of the contortions that e.g. C# has to go through when evolving the language, due to numerous ambiguities between used for types and used in expressions, I think it's still a very sensible choice.

Re: Go 1.18

#484

Post by reegnz »

alex_sf wrote: post #419
saurik wrote: post #351

Earlier quoted context omitted.

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

Policies don't work. It's why we lean on process in fields where correctness matters, e.g. aviation.

Policies do work if you have a process to enforce those policies. Without policy how do you define the process? "Good intentions never work, you need good mechanisms to make anything happen." http://nickfoy.com/blog/2018/4/7/good-intentions-dont-work

Re: Go 1.18

#485

Post by int_19h »

uryga wrote: post #465
int_19h wrote: post #380

Earlier quoted context omitted.

Exceptions can still be treated as syntactic sugar for EaV; it just means that every expression has an implicit unwrap-and-propagate.

are there any languages that do this? Rust's `?` is similar but the propagation is explicit

That's what I'm saying - any language with exceptions can be treated as if it was all Rust-style Result, but with implicit ? after every expression. Well, and E is an open variant (like e.g. extensible variant types in OCaml), unless the language has checked exceptions like Java.

Re: Go 1.18

#486

Post by alophawen »

majewsky wrote: post #474
alophawen wrote: post #373

Earlier quoted context omitted.

I predict someone will boil up a linter tool that would block generics in your CI.

I also predict it will be practically useless since those five libraries that you absolutely depend on will all be rewritten to take advantage of generics, and then you're left with the lose-lose situation of "maintain a fork of the last non-generics version myself" or "get stuck on the last non-generics version and never receive security updates again".

Not sure why you would run checks on your dependencies rather than your code.

Re: Go 1.18

#487

Post by int_19h »

morelisp wrote: post #431
int_19h wrote: post #358

Earlier quoted context omitted.

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

Java can decide to heap-allocate or not heap-allocate at runtime based on what optimizations the JIT has performed so far, and so it can change over the course of a program's run. I don't think you can get more implicit than that.

Why would Java ever heap-allocate a local, regardless of optimizations?

It can decide to heap-allocate or stack-allocate objects (when you new them) based on escape analysis, which is a JIT optimization. But that's very different from heap-allocating variables.

Re: Go 1.18

#488

Post by int_19h »

BoorishBears wrote: post #395
int_19h wrote: post #353

Earlier quoted context omitted.

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

Ergonomics sucked and a lot of people didn't use them (or even know they existed!) because ergonomics sucked

From my work experience at the time, it was used pretty heavily in new codebases.

Re: Go 1.18

#489

Post by alophawen »

alex_sf wrote: post #406
alophawen wrote: post #371

Earlier quoted context omitted.

I spent 4 months in '21 rewriting a golang backend to properly use channels for concurrency. The previous developers did misuse it and left a steaming pile for me to find. However contracting pays well, so I don't care. You might want to reflect on your reasons for jumping ship because your tooling gained a new feature. Sound's rather irrational to me.

It's less that it gained a new feature, and more (the fear at least) that it made a change for the worse. Avoiding updating to a new version of OSX that stabs you in the face is a reasonable thing to do, despite it being a new feature.

I think this line of reasoning is detrimental for yourself:

- noone is forcing you to use generics in your go programs.

- if you are running outdated OS because you don't like some UX change, you might as well consider changing OS.

Re: Go 1.18

#490

Post by kubanczyk »

cfors wrote: post #321

This will no doubt be overshadowed by Generics, but Workspaces[0] are going to be incredibly useful for companies using a monorepo with shared packages. Once again, great job to the Go team! [0] https://go.dev/doc/tutorial/workspaces

Finally! Helps with both monorepos and multirepos, as illustrated in the tutorial you've linked.

(After going through a bunch of associated docs, I'm under impression that their quality is going down, slowly. At least when comparing it with the stdlib docs' quality.)

Post reply on HN