141–150 of 169 posts
The example includes a simple generic `Filter` function
https://ccbrown.github.io/wasm-go-playground/experimental/ge...
Suggestion: While your paper is very intellectual and I laud that, perhaps what would work better for mass uptake is to create your own programming language around the concepts you propose, and let people try that language. You could call this language "Featherweight Go" if you wish, but perhaps it would be better to call it something else entirely, and simply state that that this new language was inspired by Go. Thi…
The "Featherweight Go" referred to in the paper is simply a tiny subset of the Go language itself that's being used as a framework for formalising the mechanism they're proposing could be used.
Earlier quoted context omitted.
You're commenting on a paper by expert programming language theorists describing a design that is both complex and (in some aspects) novel. Almost certainly an element of getting these people to work on it is Go's existing popularity, it's mentioned in the second sentence of the paper. If I understand you right, you are suggesting that instead of doing what they are doing now, they should have just used an existing d…
Yes, right from the beginning. Java isn't the only language to chose from.
Not to mention the open invitation for concrete proposals on how to add them Go.
You might find this post by one of the Go team members interesting:
Earlier quoted context omitted.
Why does genetics make things that’s for read?
Functions can be given semantic names (I.e. have meaning); block statements cannot. If writing a function that can take an array or slice of any type of data requires providing a generic argument (I.e. so you can specify that the function returns a slice of the same type of data as it was given), then you can name it "reverse" if it reverses the array, write it only once, and every timr you use it, you read "reverse"…
Earlier quoted context omitted.
Yes, right from the beginning. Java isn't the only language to chose from.
It’s hard for me to believe that it is as simple as you suggest, considering the large amount of work put in by the Go team already, and the even larger amount of work put in by other programming language implementors to eventually arrive at various (different) design points. Work which often takes many years like C++ concepts. Not to mention the open invitation for concrete proposals on how to add them Go. You might…
For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java.
Where are the experimental builds for generics support in Go?
Earlier quoted context omitted.
Yes, right from the beginning. Java isn't the only language to chose from.
Huh, if there are so many languages to choose from then people can choose one of those. Go will die its natural death. Where is the problem?
Secondly, I also kind of like Go, just see it as lost opportunity to have been with little more than a C like type system, even C has some genericity support in the meantime.
And whatever gets out of it, will be rather clunky as proven by late adoption in Java.
Earlier quoted context omitted.
Except that Java isn't obscure and experiments like Featherweight Java contributed to Java generics final design, introduced in November 2009, 3 years before Go 1.0 was released. What about that then?
My comment was not meant as criticism, I just thought it was nicely ironic. But I guess you're actually consistent: you often lament about people ignoring or reinventing approaches that proved themselves in older languages. Here are people that actually take clues from one such language, and you lament that they didn't do it earlier. I see now that it's not really ironic. Rather, you're seeing the glass half empty wh…
While I am sure Java will get value types, it already has had several experimental releases and the features have been incrementally integrated, after the switch to 6 months release cadence, I am not so sure in regards to Go.
All we get is a source code repository full of comments showing how much is left to be done, if ever. Untouched since last August.
Earlier quoted context omitted.
The "names and organization behind it" thing is needlessly condescending (not to mention false), and the ability to get things done without generics basically restates David's point. Was there something in this paper that you felt unfairly treated Rust, the language you represent on these threads? Because otherwise, I can't see what would motivate you to join this thread to snipe. I'm with David, for what it's worth.…
I went out of my way to make the point without condescension. Evidently I didn't succeed, and I'm sorry for that! Let me put it another way: Virtually all languages that have become popular recently have done so because of the backing of some large organization or another. There was a time when languages like Perl, Python, and PHP could arise out of basically nowhere and become popular. That time is gone, and now lan…
But the bigger problem is just that Rust programmers use generics absolutely everywhere (my early impression is you basically can't avoid it, because of lifetimes), and it simply does make everything harder to understand. I know I'm going to be told that if I buckle down all of this stuff will make sense and I'll be fluent with it, and sure, I managed to grok Alexandrescu C++, too. But adding new layers of indirection everywhere just has to impede comprehension; that's always the tradeoff for parameterizing and indirecting!
The flip side of this is, I've built some fairly serious things in Go --- a compiler, a couple emulators, a disassembler, a symbolic evaluator; not just the server stuff Go is supposed to be good at --- and I have complaints about Go, but almost none of them are its lack of generics.
(There are things I like about Rust! But this isn't the thread for it.)
Earlier quoted context omitted.
It’s hard for me to believe that it is as simple as you suggest, considering the large amount of work put in by the Go team already, and the even larger amount of work put in by other programming language implementors to eventually arrive at various (different) design points. Work which often takes many years like C++ concepts. Not to mention the open invitation for concrete proposals on how to add them Go. You might…
As proven by the lack of progress, that invitation has just political value, it allows posts like yours when these discussions take place. For example, while Valhalla has taken several years so far, OpenJDK team has experimental builds that you can go and play around with value types in Java. Where are the experimental builds for generics support in Go?