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

211–220 of 614 posts

Re: Go 1.18

#211

Post by BobbyJo »

akmittal wrote: post #167
naikrovek wrote: post #161

Earlier quoted context omitted.

> Existing libraries resorted to code generation a lot. guess what generics is in a lot of languages? code generation! the files just aren't saved to disk. IIRC on a podcast I seem to recall hearing that it was implemented this way for Go, at least for the prototype, and it seems likely to me that it is also done this way in production, but not with textual code.

Thats like saying lets just write assembly because eventually code will be converted to assembly. As a developer now we dont have to bother about codegen.

No exactly. Assembly is more like the generated code than the generator code.

Re: Go 1.18

#213

Post by avl999 »

_0w8t wrote: post #67

For me the most puzzling aspect of Go is channels. Ada tried CSP (Concurrent Sequential Processes that Go channels are based on) in eighties and people quickly realized that it lead to bad performance and was unsuitable for a lot of useful cases. So Ada got standard mutexes and signals. So why CSP which does not allow to implement priority delivery or multicasting and makes cancelling much harder compared with normal…

Avoid channels except for straight forward, producer-consumer workflows. Use mutexes and other traditional concurrency primitives for other stuff. Channels are a huge shotgun with caveats.

Re: Go 1.18

#214

Post by nwsm »

sneak wrote: post #205
justinsaccount wrote: post #48

Generics is the big news, but the fuzzing support is amazing too. I added a fuzz test to an app I have in about 5 minutes. It was no harder than adding a normal test. I expect to see a huge boon in users of fuzzing techniques which will benefit projects across the board.

Link to the diff? I always learn better by concrete example than by docs.

The docs have concrete examples if you want- https://go.dev/doc/tutorial/fuzz

Re: Go 1.18

#215

Post by honkycat »

edenlinger wrote: post #80
honkycat wrote: post #4

WOOO! I have been using the RC at work lately, and I have to say: The generics implementation is quite nice, and RUTHLESSLY slashes boilerplate and copy-pasta. This is going to turn Golang from "that one boilerplate-y language without generics" into my favorite language. I've been using the https://github.com/samber/lo library, and it is very nice to be able to do "map/reduce/etc..." on golang structs. I would really…

I don't mean to disparage the wonderful work of the lo developers but, this is in many ways what I feared generics would bring. If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language. I am probably an old man yelling at clouds and I hope those who like this style get tons of value from it. I just don't see the benefit of trying to retrofit s…

> If you aren't going to lean into the simplicity and single way of doing something, you are likely better served in another language.

Generics were widely asked for by the community for many reasons, one of the main things being reducing boilerplate and having basic polymorphic functionality that other languages provide.

I'm not trying to disparage you but: You don't know who I am, or my capabilities. Please don't be condescending to me and assume I just "don't get it" or that I am too lazy to learn the "go" way of doing things.

I am seeing that a lot in this comment section. You are judging others and coming to conclusions because we like something you do not like. I can totally understand your perspective, because I also see the danger of introducing more "power" into a language that was elegant and simple.

I respect your disagreement with introducing generics to Golang. However, please extend us the courtesy of assuming we are at least remotely competent.

Re: Go 1.18

#216

Post by avl999 »

exdsq wrote: post #143

Aaaand now watch every projects abstraction increase tenfold under the weight of generics

Or an expectation of competence from developers and expecting them to consider tradeoffs of their design- in other words doing their damn jobs as opposed to the language baby sitting them away from tools they might use incorrectly.

Re: Go 1.18

#217

Post by ithkuil »

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…

My main misery with modules was due to people renaming their GitHub repositories

Re: Go 1.18

#218

Post by jayd16 »

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?

Re: Go 1.18

#219

Post by jayd16 »

ithkuil wrote: post #217
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…

My main misery with modules was due to people renaming their GitHub repositories

Fork them (just make a copy you own) so you have control?

Re: Go 1.18

#220

Post by Mawr »

morelisp wrote: post #198
Mawr wrote: post #176

Earlier quoted context omitted.

type Optional[T any] struct { value *T } Don't use a pointer - it's bad for performance. func MakeOptional[T any](value *T) Optional[T] { Use `New` instead - it's the idiomatic name for a constructor in Go. Drop the `Optional` part - the module name suffices - the caller will see: `opt.New`. Personally I just call the module `optional`, I think it's clearer: `optional.New`. func (o* Optional[T]) Unwrap() (T, error) {…

Whether a pointer is bad for performance in this case seems hard to tell a priori. There are also performance advantages if Optional packs nicely.

It is just an assumption on my part, I figure that the cost of pointer chasing is generally going to outweigh any disadvantages. It can also help enable optimizations, for example slices and maps that do not contain pointers do not get scanned by the GC ([1]).

[1]: https://github.com/golang/go/commit/85e7bee19f9f26dfca414b1e...

Post reply on HN