81–90 of 105 posts
Earlier quoted context omitted.
If they're stricter, it's only because they rule out more kinds of incorrect behavior. Go's type system is actually strict in a useless way, because it doesn't allow you to write correct parametric code (for example, sorting generic slices).
If they're stricter, it's only because they rule out more kinds of incorrect behavior. Sounds pretty bondage & discipline to me.
Earlier quoted context omitted.
It's not about changing everything, it's about being able to make abstractions that aren't second class citizens. By giving this power, you also increase the consistency of the language.
By giving this power, you also increase the consistency of the language. Maybe. That's like the apocryphal story about the student asking a question if a particular proof step is really obvious, so the professor goes across the hall, derives stuff on the other blackboard for the next 30 minutes, then comes back into the lecture hall saying, "Yes, it's obvious." Maybe you increase the consistency of the language from…
But bona fide parametric polymorphism doesn't have this problem. ML's design is a constructive proof that you can have a reasonable degree of abstraction without compromising usability.
Earlier quoted context omitted.
I don't understand this attitude. I do use other languages, and I can tell you type polymorphism is not a mistake. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function.
I can tell you type polymorphism is not a mistake. It's a particular trade-off. Some opine that it's not the right trade off. You disagree. Complicated architectures full of abstraction are a mistake, which you can limit without sacrificing the ability for me to make a type-safe generic function. From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long ter…
Can you name a specific example of people using ML-style generics (i.e. no typeclasses, no module system) to achieve "over-exuberant abstraction"?
Earlier quoted context omitted.
So you want other people to maintain something for you and do it the way you like? Obviously, it's not simple to just fork a project like Go and maintain it but the point is that it is not legally impossible. A group of people inclined enough to "fix" Go for themselves are completely free to do so. BTW, you might be interested in https://oden-lang.org/
No, I want the language to have a standard way to extend it that's compatible with the core. Generics is a standard way to do type polymorphism without having the ship people another compiler.
Earlier quoted context omitted.
In my case it's python, Rust has a bit more of a learning curve / productivity hit. I'm still complaining though because I like what Go is doing with concurrency and simplicity, but I think it would be almost perfect if it just trusted the user a bit more.
I think it would be almost perfect if it just trusted the user a bit more. If it trusted the user just a bit more, it would be making many of the same mistakes other languages make, which Go is trying to avoid. You're free to go and use some of those other languages.
Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.
Earlier quoted context omitted.
https://golang.org/LICENSE
Something we're slowly coming to terms with is the consequence of having open source without open governance . It's not clear to me that the language would be better if the project stewards accepted more feature requests, though. It is incredibly difficult to hold the line against feeping creatures and a noisy minority when the benefit of simplicity is diffuse.
Earlier quoted context omitted.
This presupposes that change is bad. In many (most?) codebases, the change in style is good. Sure, such a thing can be good, as in, it's a good trade off. Pulling a tooth can be good in this sense, as it's better than getting further infections from an abscess. But here's the thing about trade-offs -- really you want to avoid having to make them in the first place. (Dental hygiene.) I'm working in a C++ code base rig…
I can't tell whether you're arguing (a) that people who originated whatever C++ codebase you're working on should have had better foresight or (b) nobody should have even tried migrating to a more modern style. I think both (a) and (b) are untenable: (a) is equivalent to "people shouldn't make mistakes"—i.e. directly at odds with the real world—and (b) is a recipe for stagnation.
To quote Theodore Roosevelt, "A man's hindsight is as good as his foresight, and if he doesn't use it, it's a darnedsight!" I'm saying that the Go maintainers should take a look at the historical pitfalls of other languages, like C++, and try to use that information to chart a smoother path. From listening to Rob Pike talk about his motivations, I think that's exactly what happened with Go.
Earlier quoted context omitted.
Why hasn't it happened to me? I've been writing Go for over 3 years, and I prefer the language stay as is. I'm more concerned about porting it to more platforms. Perhaps that's a reason I'm motivated to desire less language changes.
> Why hasn't it happened to me? Well, don't know about your case, but I've seen e.g. people who are religious about being DRY and dislike any kind of useless boilerplate, and others just copy paste code with wild abandon and couldn't care at all.
Go and Generics issue on the other hand, feels a little different to me. It is a solved problem. Go does not have an inherent show stopper for generics. It's just not there because of.. What? Stubbornness? I'm not sure. But then it irritates me to copy paste stuff.
Earlier quoted context omitted.
I can't tell whether you're arguing (a) that people who originated whatever C++ codebase you're working on should have had better foresight or (b) nobody should have even tried migrating to a more modern style. I think both (a) and (b) are untenable: (a) is equivalent to "people shouldn't make mistakes"—i.e. directly at odds with the real world—and (b) is a recipe for stagnation.
I can't tell whether you're arguing (a) that people who originated whatever C++ codebase you're working on should have had better foresight To quote Theodore Roosevelt, "A man's hindsight is as good as his foresight, and if he doesn't use it, it's a darnedsight!" I'm saying that the Go maintainers should take a look at the historical pitfalls of other languages, like C++, and try to use that information to chart a sm…
I can't think of a single language that had problems with incompatible core collections due to having them be in the library as opposed to directly in the language. The closest thing I can think of is Haskell's explosion of String types, but one of the lessons to take from that is precisely the opposite of what Go chose—it's pernicious partially because the suboptimal String is baked into the language, and the overloaded strings extension is necessary to correct this!
Earlier quoted context omitted.
I think the opinionatedness doesn't have to stop, just the opinions can change in the face of evidence that a particular abstraction is more useful than the archetectural hazards it presents developers.
Can you quantify this, then?
Maybe I could do some kind of poll of people hitting this or other rough snags that would be solved by generics or something similar? But I am afraid that (rightfully so) go fans would feel the poll could be overrun by people who only casually dabbled in go. Same with counting the many complaints of people every time this topic is brought up- the general response seems to be that they don't want that kind of programmer here anyways, so go away.