131–140 of 224 posts
Earlier quoted context omitted.
And yet, the dmd compiler for D support templates and is faster than the gc Go compiler.
I'll say it again: Go doesn't have generics because of implementation complexity. The tradeoff was against the additional complexity that our users would have to deal with.
Earlier quoted context omitted.
There's a way to make channels easy to use and abstract. Just make a typecast function. Details in a comment on the original post. The idea is that you create a library which communicates using channel interface. Great. Now you need to add `i.(myType)` wherever. So, create a function that accepts an interface, switches on type (switch i.(type)) and returns a value with your concrete type. It's a 6-liner solution to m…
In a statically typed language, it shouldn't be necessary to break type safety to implement basic abstractions. The only thing interface{} provides over void* is safe typecasting.
In go, where interfaces are implemented by default and `interface{}` covers everything, you also don't need to. It's just a little bit (~6 lines) of code to add to guarantee it while they figure out a nice way to add generics.
Rather than arguing about generics in Go again, I'd be interested in reading about how experienced Go developers solve the problems posed in this article. (He may be wrong that there's no elegant solution.) Also, if it can't be solved elegantly, perhaps adding merge() and a few other important functions to the language would be good enough? After all, Go already has the magic append() function for slices and we get q…
Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem wit…
> Go doesn't let you build abstractions - it offers what
> it does, and if its not enough - tough luck.
Earlier quoted context omitted.
I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pret…
I never thought people will actually come up and defend code duplication. It's definitely more than ugliness. The need to fix all the copies when they need to be updated is a bigger problem.
> I never thought people will actually come up and defend
> code duplication.
Overapplication of DRY as axiomatic has led to much pain and suffering.
Earlier quoted context omitted.
I've done most of my Go programming on library code. A sync library for relational databases to sqlite (for mobile devices) and an embedded database. Lack of generics has bothered me a little, but copy and paste with a multiple-cursor editor really makes short work of it. I think the worst part is really our natural aversion to code duplication and the ugliness of it. e.g. having to write min/max for integers is pret…
"My editor makes it really easy to do this terrible thing, so it's okay!" I'm sorry, I quite enjoy many aspects of Go - but the argument that committing one of the cardinal sins of programming is okay because your editor makes it easy is worse than the actual language shortcoming itself.
Go was created for businesses, not developers. The holy grail of a corporate programming language is that all individual developer personality is restricted, such that _you cannot tell from reading code who wrote it_. This is all about long-term, large-scale maintainability for massive code bases at massive corporations.
Disclaimer: I work at Google, I do not represent Google, and this is just my opinion after spending time "on the inside".
Earlier quoted context omitted.
It was the community attitude towards generics and code distribution that eventually made me focus on Rust and D. At least those communities embrace modern computing abstractions and code distribution practices.
It's fine that you don't agree with our tastes, but it would be nice if you could stop coming into every Go thread and being condescending about it. Like PostgreSQL and OpenBSD, I've been permanently turned off Rust because I never want to be left at the mercy of a community that invests so much time in harassing and insulting others.
who is harassing or insulting anyone in the Postgres world?!?!
Earlier quoted context omitted.
It reminds me of the wonderful fun days of Java 1.2 - anybody remember how proud Sun was of how everything derived from object so you could use the untyped containers for everything?
The main difference with casting to Object is that you can use type switches or safe casts which return an additional success boolean, to restore type safety quickly after taking the item out of its container. Yes, you can type-test in Java before you type-cast, but it isn't idiomatic, and it isn't syntax.
Go doesn't let you build abstractions - it offers what it does, and if its not enough - tough luck. What I dislike worst is the denial of the Go community and creators, claiming that generics are too complex and that you don't really need them. I dismissed Go not because of its lack of abstraction power, but because its authors and community is incapable of admitting problems when they see them. A similar problem wit…
> Go doesn't let you build abstractions - it offers what > it does, and if its not enough - tough luck. This seems contradictory. Go offers primitives, and lets you build exactly the abstractions that make sense in your domain on top of those primitives. The argument here appears to be that the primitives are too low-level, which is a fair-enough point, but not at all what you're claiming.
Of course: turing tarpit, greenspunning, yadda yadda yadda, but his point remains: Certain abstractions with a low cost/benefit factor are just not expressible in "idiomatic" Go.