strings.Cut / bytes.Cut is really nice.
Go 1.18
191–200 of 614 posts
Re: Go 1.18
#192In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional
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) {…
I love it. I will update the library to match some of your suggestions.
I agree with peer comment that we should likely defer to the original type for JSON serialization.
Re: Go 1.18
#193Great to see this! Generics will drastically improve datastructure libraries. That said, for people worrying about overcomplication, fortunately methods can't have type parameters. That means ergonomic monads are not possible to implement, and we'll most probably not see the whole functional story play out in Go.
Plenty of great functional alternatives to Go.
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 for more functional style programming, and golangci-lint has a linter for exhaustiveness.
Re: Go 1.18
#194Earlier quoted context omitted.
It's not a feature, and it's not a good idea to refer to people with @nicks, because Twitter's @name convention is much stronger and the two don't overlap perfectly (I am not, for instance, @tptacek on Twitter). I use 'nick to refer to people here, in keeping with our lispy ethos, but really anything other than @nick is fine.
I would not assume any "@" is referring to a twitter user, it is common across a number of apps (not to mention, IRC)
It's worth noting that on IRC it refers to someone being an op, and that it's not used for pinging people. (I sometimes see people who are used to other chats put the @ at the start of an IRC message)
Re: Go 1.18
#195This 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 have an irrational dislike of go because for every X it's missing the community's answer is "you don't need X" (until they decide you do). Package management, generics, sum types, decent error handling, etc. It's an arrogant approach that rubs me the wrong way. It reminds me of "You're holding it wrong" and seems ingrained in the go ethos. That's not to say I'm not productive in go, but I could be vastly more produ…
If I rethink about how long I was kept away from go by its error handling and then I fell in love with it...
Re: Go 1.18
#196The general excitement about generics on this thread makes me uneasy. Please keep in mind that generics are a pretty big hammer - they can add a lot of complication if not used with caution. Only use a language feature if you absolutely must.
The thing that worries me is people trying to reconstruct features from other languages with generics. One of the things I like about Go is that no matter whose code you're looking at, it's almost certain that you're already familiar with any feature you'll see, because the set of features is relatively small.
Re: Go 1.18
#197Now 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…
If you only had a single case in a few years, then why would you need a ternary operator? Your anecdotal data experience is actually confirming their decision to leave this out of the language.
Re: Go 1.18
#198In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional
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.
Re: Go 1.18
#199Earlier quoted context omitted.
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…
This is by design: https://go.dev/doc/faq#Does_Go_have_a_ternary_form Ken Thompson added ?: to B / C and then he took it from us in Go due to the wisdom he gathered in between.
> A language needs only one conditional control flow construct.
And yet, Go has a switch statement.
Re: Go 1.18
#200In celebration of generics release, I was playing around with supporting Optionals via generics. If anyone's interested I am happy to make this a real project https://github.com/frenchie4111/go-generic-optional
My main fear with the introduction of generics was the lack of stdlib support. I know they want to play it safe and are planning to change this in future versions, but the last thing I want is that I have to download some github.com/foobar/... library for every common sense generic type I might want to use.