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

491–500 of 614 posts

Re: Go 1.18

#491

Post by glenjamin »

thegeekpirate wrote: post #434
yashap wrote: post #416

Earlier quoted context omitted.

Sets tend to have methods like difference, union and intersection - with a map[T]bool, if you want to find the difference, union or intersection of 2 sets, you have to do all of that with much more verbose (and error prone) loops. Also, the type being a set carries a semantic meaning, with a map[T]bool it’s not obvious from the type alone that we only care about the keys, not the values.

> with a map[T]bool This takes up unnecessary space—use map[T]struct{} instead, which also explains to anyone reading the code that the value isn't used.

And now with generics we have a way to make this decision/optimisation once, and have everyone else benefit from it without having to be aware of the details!

Re: Go 1.18

#492

Post by [deleted] »

glenjamin wrote: post #491
thegeekpirate wrote: post #434

Earlier quoted context omitted.

> with a map[T]bool This takes up unnecessary space—use map[T]struct{} instead, which also explains to anyone reading the code that the value isn't used.

And now with generics we have a way to make this decision/optimisation once, and have everyone else benefit from it without having to be aware of the details!

[deleted]

Re: Go 1.18

#493

Post by ezst »

zozbot234 wrote: post #437
yashap wrote: post #418

Earlier quoted context omitted.

The downside is they’ll make Go code less uniform. Do you represent nullability with a nil-able pointer, or an option monad? To transform a list, do you loop over a slice, or map/flatMap/filter over a more functional data structure? etc. Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. I think generics will make it less verbose and error…

> Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. Except that this kind of uniformity inherently tends to disappear in larger projects, to be replaced by increased complexity. Java was also designed to be a "simple" language, one trivially understandable by hordes of low-skilled code monkeys, and yet look at the added layers of complexi…

> when properly designed (especially, avoiding the feeping creaturitis of something like Scala)

What I find interesting here is that Scala has the reputation of being a complex language, while its syntax and grammar are among the simplest and most straightforward there is: https://images.app.goo.gl/K1NTGUP4G9T6wfY48

I believe that this is what "scalable" means in the eyes of its creator: it offers very powerful abstractions to be adequate for mundane tasks (e.g. file-level scripting) up to complex systems and problem spaces.

Yes, as a consequence, people have created libraries and codebases with Scala that are inadequately complex and abstract for the problem at hand, but that's not something one should blame on the language but on the project/company culture. Same is true for any language: C++ templates can be abused in ludicrous ways, some of Java's design patterns make you wish inheritance would be forbidden, python's module imports potentially overwriting globals and other footguns.

No language can be dumbed-down so much that the resulting codebase becomes immune to some amount of "abstraction management", not go, not even python. Once this is understood and accepted, it becomes obvious that it's not worthy to castrate a language on the basis of "simplicity", because eventually this complexity will be warranted at a point in the future or for some aspect of the project.

I think the go designers did the right thing here, I don't think this will bring dramatic changes in how the language is used, and will actually help with "managing abstraction" where it's due.

Here's more on that: https://www.lihaoyi.com/post/StrategicScalaStylePrincipleofL...

Re: Go 1.18

#494

Post by ezst »

lifty wrote: post #477
zozbot234 wrote: post #437

Earlier quoted context omitted.

> Pre-generics, Go has been a very limited language. On the downside it’s verbose and error-prone, on the upside it’s very uniform. Except that this kind of uniformity inherently tends to disappear in larger projects, to be replaced by increased complexity. Java was also designed to be a "simple" language, one trivially understandable by hordes of low-skilled code monkeys, and yet look at the added layers of complexi…

Java code got complex after adding generics, not before. In a big Go codebase, even if it’s complex, the styling and patterns are the same, so it’s easier to follow. That might change to some degree with the addition of generics.

That's not true. Java was notorious for AbstractFactoryProducerArtifactFactory and awful inheritance-based patterns long before that.

You can't dumb down a language and expect the complexity of the problem space to go away (developers will have to cope with it one way or another), and you can't expect the programming language alone to be the sole judge of what's an acceptable level of abstraction (or architects would have been made redundant by now).

Re: Go 1.18

#495

Post by morelisp »

int_19h wrote: post #487
morelisp wrote: post #431

Earlier quoted context omitted.

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 .

Then I'm not even sure what you're talking about when you say "heap-allocate even a local variable" if you don't actually mean the value of that variable. If you draw that distinction, "variables" are never allocated; spaces for values are.

Regardless, whether something is a local or not in Java still varies depending on the JIT's decisions. (Or rather, the JIT does not see local/non-local variables, only lifetimes, and whether the lifetime may extend past the JIT's current view.)

Re: Go 1.18

#496

Post by bashery »

rr808 wrote: post #362
dimgl wrote: post #284

Earlier quoted context omitted.

Disclaimer: I'm extremely happy that generics are coming to Go. > I wish I understood how people can say 'this will result in so much more weird boilerplate garbage code' It's pretty simple: there's a lot of developers that misuse/shouldn't use generics. Here's an article I found just casually browsing on Google that shows why this can turn out to be such a huge problem. https://itnext.io/golang-1-18-generics-the-goo…

My view is there should be official libraries with generics, but regular developers shouldn't be allowed to write any.

agree +1

Re: Go 1.18

#497

Post by kitd »

jjtheblunt wrote: post #307
SureshG wrote: post #281

Earlier quoted context omitted.

> None with the same performance characteristics, Most JVM languages (Kotlin/Scala/Clojure) including Java :) In fact kotlin/java has better peak performance than Go. Main advantage for go is the reduced memory footprint.

> In fact kotlin/java has better peak performance than Go. Says what benchmark?

There are many benchmarks showing Java faster than Go. The trick is picking one that people agree is representative.

It shouldn't be surprising though. "Peak performance" doesn't include start-up time, and ignores memory. If you discount both those, there's no reason that JITted native code wouldn't be faster than a runtime that includes goroutine scheduling.

Re: Go 1.18

#498

Post by lifty »

kortex wrote: post #275
morelisp wrote: post #222

Earlier quoted context omitted.

Efficient map/filter/reduce chaining basically requires JIT to fuse the operations and/or a GC prepared to deal with huge amounts garbage. In Go, filter(h, map(g, filter(f, a))) will be immensely slower than the equivalent for loop.

Great point. Although, that sounds like a typical example of "let's write it the ergonomic but less performant way first, then profile and refactor as needed". That seems very tractable for that sort of refactor, especially with type safety. Also I would not be surprised to see JIT-like behavior from go tooling, first party or otherwise, if that sort of approach takes off.

And now we introduced 2 new problems: 1. We have 2 ways of doing stuff (boring loop vs map) 2. We have a new hidden way to introduce performance degradation by importing a library that uses map

You might argue that you should know what you're importing, but in practice, it can hurt the overall ecosystem. I'm still supporting the introduction of generics, but the tradeoff should be clear to everyone.

Re: Go 1.18

#499

Post by morelisp »

acuozzo wrote: post #295
MrDOS wrote: post #234

Earlier quoted context omitted.

Not only that, but despite all of the other syntactic sugar Go is lacking (usually sorely, such as a “try” error handler), the switch statement is really just an “if” statement in disguise. var someVar, anotherVar string // ... switch { case someVar == "whatever": fmt.Println("Tell me how, exactly,") case anotherVar == "nope": fmt.Println("this compiles to a jump table?") default: fmt.Println("Spoiler: it doesn't.")…

> the switch statement is really just an “if” statement in disguise If the switch is over a fixed set of strings, then can't the backend generate a perfect hash function ala gperf and then proceed to use the computed hash value to implement a jump table? Also, FWIW, the only compiler backends I've ever seen blindly emit a jump table all died in the '80s. Jump tables aren't always the fastest choice: https://www.cipht…

Go currently uses a binary search for integer switches (and I believe serial comparisons otherwise). Jump tables are in development and likely to appear around 1.19 or 1.20. As you say, there's a lot of edge cases to consider when figuring out whether a table or comparisons are the better choice.

https://go-review.googlesource.com/c/go/+/357330/

Re: Go 1.18

#500

Post by t43562 »

jayd16 wrote: post #218
t43562 wrote: post #209

I think about Go with pleasure until I remember importing. The miseries I've experienced with modules - the way imports are satisfied......just so hard to understand. Built-in support for SCM sites like github (yuck!). Just struggling to put code in a place where some other bit of my code can use it. The C/C++ preprocessor is an abortion and go seems to have made something that solves all the problems I had with that…

Whats wrong with SCM support?

Works with github, doesn't work (for no reason that you can understand at first glance) with the company bitbucket server. There's no programmatic or configuration mechanism I can use to fix it - it needs changes on the server which I cannot make. etc etc.
Post reply on HN