|
Here's a q for the Go experts -- why is Go's type system brain dead?
|
#
¿
Feb 25, 2015 06:47
|
|
|
|
| # ¿ Apr 29, 2024 03:33 |
|
|
Karate Bastard posted:Huh. That's a really bad blog post. It's a really good one b/c it adequately captures the feeling of writing go (and searching for go, &c)
|
|
#
¿
Feb 25, 2015 09:08
|
|
|
"we"
|
|
#
¿
Feb 26, 2015 05:14
|
|
|
Compile times are important to us. That's why we have offloaded compilation onto our programmers.
|
|
#
¿
Feb 26, 2015 05:15
|
|
|
sarehu posted:Sorry there's no There's probably one in yospos or smth
|
|
#
¿
Feb 26, 2015 07:24
|
|
|
Most of my complaints with Go are with the hype surrounding it anyway. It's fairly palpable. Go is not the saviour.
|
|
#
¿
Feb 27, 2015 08:24
|
|
|
Karate Bastard posted:Nah that's all good, as long as it can be kept to the concrete. For example, I'd really like to hear why you think the type system is bad and how it hinders you in your day-to-day work, and what you propose should have been done instead, and why you'd expect that to improve things, and what other language you consider has done this right. Most go projects I've seen go to type assertions at some point and some even have to resort to using reflect. Moving your type system to the runtime is a pretty good concrete example of it not being expressive enough.
|
|
#
¿
Feb 27, 2015 08:39
|
|
|
Voted Worst Mom posted:What's wrong with type assertions? That's not a strange thing to do when you're using interfaces anyways. I also really doubt many projects have to resort to using reflect unless you're dealing with protocol buffers or something. It's actually pretty loving strange when all of your type information is known at compile-time. It makes your project more brittle and it's unnecessarily verbose. And gently caress it, why should I have to do it? Why can't it just have a good type system instead?
|
|
#
¿
Feb 28, 2015 09:25
|
|
|
MALE SHOEGAZE posted:I am just learning Go and the fact that it gets so many things right are what make the things that seem 'less right' so frustrating. The type system feels like more of a straight jacket than an actual tool. A good type system can be expressive and powerful in addition to just making your code typesafe. 
|
|
#
¿
Feb 28, 2015 09:27
|
|
|
sarehu posted:Here is what annoyed me about Go's type system yesterday. I had several types of slice, and for each of them, I wanted to find the index of the element that matched a given player. In other languages I could just write func[T] lookup(elems []T, f func(T)bool) (index int, found bool) { ... }, or actually it would be a utility written for me, but instead I had to rewrite the same for loop several times. And the same again when I wanted to make a new slice with the matched element removed. I guess it doesn't matter though because Go is made by titans in their field, just like Git, a perfect version control system that is also above criticism. Don't worry, `go generate` will allow you to fix this by building the world's most simple build system. Any .go file in your repo may bear a `//go:generate` on any line, and go will happily call out to your shell to perform whatever you've put there. Simple!
|
|
#
¿
Mar 3, 2015 10:38
|
|
|
|
| # ¿ Apr 29, 2024 03:33 |
|
|
duck monster posted:Is it just me or do a lot of Go's libraries have utterly garbage documentation. Maybe I'm spoiled by python, but I'm coming across so many libraries that have at best a minimal API documentation and no context at all. I think they're pretty good but assume some familiarity with C. I wasted half an hour the other day trying to get the binary package's thing to pack my int into bytes, but it turns out its packing is set up for protobufs. D'oh!
|
|
#
¿
Mar 12, 2015 18:35
|
|