231–240 of 614 posts
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…
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…
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…
Can you share some issues you have?
Earlier quoted context omitted.
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.
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.")
}Earlier quoted context omitted.
Fork them (just make a copy you own) so you have control?
Usually my problems are with transitive dependencies. I would have to fork quite a few projects to deal with that. I wish there was a more systematic way to do "replace", possibly in libraries as well
curl -L -O "https://go.dev/dl/go1.18.windows-amd64.zip"
unzip go1.18.windows-amd64.zip
Join-Path $pwd "go\bin" >> $Env:GITHUB_PATH
Great 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.
This is quite tricky to implement properly if the compiler doesn't do some form of specialization. (Basically, you need a different vtable entry for each instantiation of a generic method, or you need a runtime lookup to find it). But given that the Go compiler is doing complete specialization, I'm surprised they left this out.
Generic methods (on classes) are the way to emulate first-class polymorphism (roughly, passing around type constructors) without explicit support in the language. It's a limitation that will eventually catch up with you.
Earlier quoted context omitted.
Usually my problems are with transitive dependencies. I would have to fork quite a few projects to deal with that. I wish there was a more systematic way to do "replace", possibly in libraries as well
There’s a « replace » directive in go.mod.
Earlier quoted context omitted.
Honestly, one of the biggest things that drives me away from Go isn't the lack of features, it's this condescending attitude that comes from so many people who espouse Go. I don't need to invest in a language whose community is so hostile. If you wanted to be persuasive or helpful, you could try explaining what the other approaches to work around lacking generics might be , rather than just insulting people for being…
> Honestly, one of the biggest things that drives me away from Go isn't the lack of features, it's this condescending attitude that comes from so many people who espouse Go. I could say the same about many of Go's critics, but I don't because that wouldn't be constructive. Rather than taking undue offense at my comment, why not articulate a counterexample to prove that there are valid reasons why a person (rather tha…
All three of these things are subjective.
> in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to"
At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.