161–170 of 224 posts
Earlier quoted context omitted.
And yet, the dmd compiler for D support templates and is faster than the gc Go compiler.
DMD isn't faster than the go compiler anymore
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.
you see, the problem with the complexity of a language isnt real. it is perfectly possible to avoid generics in c++ forever. but there will come a day when you think to yourself, was it really worth it to be this lazy? then you take a peek and (assuming you understand generics by then enough to use it a little) suddenly half of what you have writen so far is for the bin.
Earlier quoted context omitted.
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.
Please tell me where you've been harrassed and insulted by the Postgres community? Sometimes people come into the IRC channel and say something that doesn't make sense and are told it doesn't make sense, and sometimes those people get very upset, but I wouldn't classify that as harrassment. And that's basically the strongest reaction you'll ever get from anyone in the community.
I basically stopped using (public) IRC somewhere around 2000. I have little idea what goes on in PostgreSQL's IRC channel(s). I expect it's toxic, but I'd expect that for any project's IRC presence. Public IRC is an inherently toxic medium.
Earlier quoted context omitted.
Please tell me where you've been harrassed and insulted by the Postgres community? Sometimes people come into the IRC channel and say something that doesn't make sense and are told it doesn't make sense, and sometimes those people get very upset, but I wouldn't classify that as harrassment. And that's basically the strongest reaction you'll ever get from anyone in the community.
Any active comments thread related to MySQL attracts a derailing holier-than-thou invasion telling us how dumb we are for not using PostgreSQL. PostgreSQL's advocates haven't quite reached the arrogance level of Oracle DBAs, granted, but they're a lot more active. I basically stopped using (public) IRC somewhere around 2000. I have little idea what goes on in PostgreSQL's IRC channel(s). I expect it's toxic, but I'd…
Earlier quoted context omitted.
I find your response condescending and hostile, actually. The parent was making a basic generalization; he didn't categorically claim that his statement applied to all people. People de facto speak in the form of opinions, and if we are all to qualify our statements with "...in my opinion" for fear of accidentally making an authorative statement, then HN would become a very unhappy place.
> I find your response condescending and hostile, actually. Welcome to the Go community.
At least by now, they updated their docs a little bit.
I still think the "How to Write Go Code" article, which most beginners will encounter, is absolutely misleading by its advocacy of 'go get' - I cannot envision a universe where 'go get' makes sense. You absolutely have to vendor your dependencies if you want any kind of stability with your project.
This is a really great read, and goes beyond just channels and concurrency. It seems to me that Go is designed to discourage developing higher-level abstractions. That was my sense using it in the past, and it's only gotten stronger over time. Remember that one of Go's primary stated goals is "speed of compilation"[1]. Simplicity and ease of learning are paramount, and it's easier to learn a language where any chunk…
This is a really great read, and goes beyond just channels and concurrency. It seems to me that Go is designed to discourage developing higher-level abstractions. That was my sense using it in the past, and it's only gotten stronger over time. Remember that one of Go's primary stated goals is "speed of compilation"[1]. Simplicity and ease of learning are paramount, and it's easier to learn a language where any chunk…
"Go is designed to discourage developing higher-level abstractions." Yes, that does seem to be the distinctive thing about Go. It's almost like someone read Paul Graham's "blub" essay[1] and thought, "what would it mean to take seriously the idea that blub is the best language?" Everyone knows that building abstractions has a cost - the cost of building the abstractions themselves, the cost of figuring out the partic…
If you look at code from the newer fancy languages people do use these fancy features.
Earlier quoted context omitted.
> You're entitled to your opinions, but this is a patently false statement. There is plenty of C code currently running on my machine that was written decades ago and is still actively maintained. You're right. Sorry. You can do it by enacting a fair approximation of stapling your eyelids to your hairline. I apologize for not being exhaustive. > The Go community actively embraces Worse-Is-Better. If your opinions are…
I think the real point is that Go just isn't a language meant for developers: It's a language meant for sys admins (which explains why it is popular with users of other languages usually used for sys admin jobs). If your job is glueing a few existing services together, you won't miss Generics much.
Go is a language for people who write servers. It is really really good for those uses. Look at Docker, etcd, Kubernetes, Juju, Cloudflare, Soundcloud ...
And probably a ton that are internal to a company and not really exposed as a user-facing "Go Application™" (like the stuff behind google's downloads service, some of youtube's metadata processes, etc etc).
I think the fact that early on in Go's life someone called it a "systems language" really confused a lot of people. It's not a systems language. It's just a language. The channels, goroutines, and standard library happen to be really useful when writing networked servers.
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…
There's no generalized solution to every generic problem. The "cast to interface{}" is the closest to a linear mapping of generics, but if you're reaching for that all the time, you're doing it wrong. So the only sane answer is, "it depends". The only use case that I have encountered that is essentially impossible in Go is the "generic data structure". Mind you, that's a bit of a big deal, even if it covered over by…
Im mainly a clojure guy and we generally belive the CPS and FP go together very well. The new interduction of transducers makes this even clearer and it seams to me this is a feature that go should really think about.