I mean it isn't even just a squiggly line, the code fails to compile. Like come on, I will clean up my unused imports and variables before sending it for review, but just let me develop in peace.
Not a go dev. Is it really preventing compilation or is it just some hardened linting rules? Most languages can prevent compile on those errors if tweaked, but that seems bad if it's not a warning
Yes, and it fucking sucks. It's a great thing to lint for but it makes debugging such a pain - commenting out an irrelevant block to focus your debugging will sometimes break your ability to compile... it's extremely jarring.
I don't think its inherently bad but it feels jarring when the language allows you reference nill pointers. It's so effective in its hand holding otherwise that blowing things up should not be so easy.
C is also bad - but I do think .Net takes the cake. I'm willing to give C a pass though since it existed before we had search engines... Go was specifically developed at Google so there's no excuse.
I ran across an old Stackoverflow question from many years ago where someone asked a question about types and wondered if generics could solve it. There was a very high-minded, lengthy reply that Go does not have generics, because that makes the language small and clean.
Since then, Go has implemented generics. Because who the hell wants a strongly typed language without generics on this side of 2010?
I honestly only think generics made it into Go because the designers started getting embarrassed by the solution to nearly every problem being "create an empty interface".
On this side of 1990. I'm not saying C++ did this right, but it embraced the idea that maybe the compiler could do a little more for us. And every time someone fielded a new language with some traction, eventually they added generics or just used duck-typing from the start.
I thought everyone else just did what I do -- if there's a squiggle, take away the squiggle part. If something's missing, make a blank line and then blindly bounce on the tab key until Copilot fixes it.
That's step 1, and if that doesn't work, step 2 is to actually look at what's going on and try to fix it.
You bring back my bad memories of having to implement a server program in rust and all my searches ended up with about 1/3 useful results and the rest being hosting options for rust gameservers
Thank you very much, I'm definitely going to take this for a spin! Can I ask if you or someone you know uses this? I'm curious what the experience is like and if theres any downfalls.
func GetConfig(path string) mo.Result[*Config] {
return mo.Try(func (*Config, error) {
// logic to get the config
})
}
conf := GetConfig.OrElse(&DefaultConfig)
While it might not make much sense for a function you use just once, it can get actually pretty useful to simplify error handling like this for something you use more often.
mostly the Result type. MustGet where you'd except a panic OrElse to pass a fallback value (can be a function with return value of the same type, as the inner function, but without an error). Useful in e.g. more complex constructors where some fields might not be readily available. Either can for instance be useful to have arbitrary type unions in structs. I haven't used Option that much but seems similar to Rust's.