651–660 of 679 posts
Earlier quoted context omitted.
> Rob Pike already stated publicly that he is against the proposed idea for Go 2.0. Rob Pike is not a member of the Go team anymore, and he has not been for several years.
That's sad. Was it because of disagreements?
No, he moved to work full-time on Upspin: https://github.com/upspin/upspin
Earlier quoted context omitted.
In my opinion the monotonic clock example cuts against this argument - originally the core team was extremely dismissive of the idea, even though it had been shown to cause pain for a lot of people: https://github.com/golang/go/issues/12914#issuecomment-15075...
But the implementation that rsc came up with was much better than everything proposed by the community (no API change).
Sometimes, of course, this does not work out for the best.
Earlier quoted context omitted.
> Go does not have generic arrays any more than C does. Go does have generic collections, and generic functions operating on these collections. > You cannot e.g. write a generic Go function to reverse an array. You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. > which you can't in Go Beca…
> You can if you're part of the core team and implement them as builtins. Go doesn't have userland generics, because users of Go are peons who can't be trusted with sharp implements. It looks like you are in golang core team's minds. You appear to be able to judge intent. Impressive quality you have here.
Not at all, Rob Pike stated it fairly explicitly if in somewhat milder terms:
> The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
I pity the recent CS graduates that weren't able to attend a decent CS degree and need Go to fit their mental model.
Go is a language for software engineering, which entails pragmatic human factors. It's not a computer science language, which emphasizes theory.
"Modern" type theory has been around since the 70s but aparently that's still too academic for Go.
But perhaps Canadian Aboriginal Syllabics are still the more pragmatic approach!
https://www.reddit.com/r/rust/comments/5penft/parallelizing_...
Earlier quoted context omitted.
It's not a matter of agreement or disagreement. It's facts. Another user on here put it well: https://news.ycombinator.com/item?id=19979613
The fact is Go team learns from other implementations and it's clear from talks and articles. Another fact is that you're accusing them in having the "mindset of refusing to look at established work". Those two facts don't get along together, that's why I disagree.
That's not learning from established work.
[1] https://medium.com/@valyala/open-sourcing-victoriametrics-f3...
Earlier quoted context omitted.
Value types aren't "necessary", but they would have been valueable at day 1. The GC heap is simply inefficient; not necessarily because of the GC (which indeed is harder with massive multicore), but simply because of the per-object memory overhead. There's a reason java had built-in value types from day 1, because it made sense even back then. Frankly, I think both java and C# kind of got this wrong. There was an ove…
> because it made sense even back then. That was necessary for performance back then. User-defined value types weren't, and Java has done well without them. > Object has semantics, and that was a mistake, because it contributes to the bloat. I think most of the RAM bloat is due to the GC trading off extra RAM for speed rather than object headers, and I'm not sure trading off complexity for headers was right 25 years…
Earlier quoted context omitted.
Yet on a past life I managed to migrate code without any major issues, other than components that weren't available on .NET.
Just like I said then "VB.NET is a new incompatible language, everyone invested in VB needed to retrain skills & rewrite existing software."
Some hard decision was made for the better of the language and its users at the end. Thank you for the courage taking the hard decision.
If want to argue, argue that other package manager do better job than modules instead of community did effort and it goes for nothing but experimental.
Earlier quoted context omitted.
Misconceptions mostly. Java developers are some of the most conservative developers around. And there you have the answer to why Java hasn't evolved that much, or when it did, why it needed to care deeply about backwards compatibility at the source level. It's because Java developers want it that way. The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring e…
> Java developers are some of the most conservative developers around. You're right, there are loads of conservative Java developers. It's one of the the things that makes me love using the language. > The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annot…