91–100 of 105 posts
Earlier quoted context omitted.
Well, that's how C++ started. I'm honestly surprised nobody's forked Go or made a less obnoxiously opinionated front-end.
Oden: experimental, statically-typed functional language, built for Go ecosystem https://news.ycombinator.com/item?id=11183836
Earlier quoted context omitted.
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…
> From what I've seen, the other mechanisms for limiting over-exuberant abstraction don't work well enough over the long term, at scale. 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.
Right, so now I'm forking it and maintaining my own language to add a feature I just get for free in any number of reasonable competitors..
Well, that's how C++ started. I'm honestly surprised nobody's forked Go or made a less obnoxiously opinionated front-end.
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 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…
You're being very nonspecific again, but I'll assume that your specific criticism is that C++ should have standardized STL collections sooner. I agree, but it doesn't imply that it should have baked them directly into the language syntax! 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 thin…
You assumed wrong.
I can't think of a single language that had problems with incompatible core collections due to having them be in the library
So? Who said that? Not me! And actually, Smalltalk did have some collection incompatibilities across vendors. (#at:put: returning the inserted value in one impementation while it returned the collection in other ones.) But the implementations of those weren't completely in the library. (You could treat them as such, however.)
Earlier quoted context omitted.
If I can use GC, why would I pick go over any of the other compiles-to-native languages with vastly friendlier type systems and language features? Rust, D, Haskell, etc. all offer similar performance profiles and are much nicer for the programmer.
"vastly friendlier type systems"? The type systems of all of these languages are more "bondage & discipline" than Go's. Stricter, more complex.
That's exactly what a helpful language does:
(0) Define a region in the design space that contains the program you want.
(1) Conveniently tell you when you have accidentally stepped outside of this region.
> more complex.
How are you measuring this? I know of two good measures, and neither favors Go:
(0) The size of a formal semantics. Go's particular feature set suggests looking at Featherweight Java (a subset of pre-generics Java specifically designed to be amenable to formalization), and, well, FJ's ratio of static guarantees to language size is very low compared to most typed lambda calculi (on which ML and Haskell are based).
(1) The number of special cases in the language's design. Here Go fails miserably, due to the sheer number of built-in types and functions that require hardcoded support.
Earlier quoted context omitted.
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.
> 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. Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.
These things are epiphenomenal, and have to do with what happens in large codebases over a long time, with lots of programmers. It's a fallacy to suppose that neat StackOverflow sized examples are some kind of a evidence gold standard. The problems I've encountered with C++ templates have to do with the interaction of several things at once, in places I'd have to dig out of version control, in codebases I can't share. So no, I'm not signing up for doing that work for you for free.
Earlier quoted context omitted.
If they're stricter, it's only because they rule out more kinds of incorrect behavior. Sounds pretty bondage & discipline to me.
Well then bust out the gimp suit, because I want my program to run correctly.
Earlier quoted context omitted.
> 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. Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific.
Can you explain with an example that would apply to Go how introducing generics to a language was making a mistake? Be specific. These things are epiphenomenal, and have to do with what happens in large codebases over a long time, with lots of programmers. It's a fallacy to suppose that neat StackOverflow sized examples are some kind of a evidence gold standard. The problems I've encountered with C++ templates have t…
(I don't think there are any such examples, because simple ML-style generics yield a lot of power for negligible drawback, and I hope that future versions of Go add them.)
Earlier quoted context omitted.
Right, so now I'm forking it and maintaining my own language to add a feature I just get for free in any number of reasonable competitors..
Rust is ready, free, and open. Use it and stop complaining about Go.
Earlier quoted context omitted.
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.
Well, the Go developers and most of its real users (not bloggers who dabble) don't want to go this route. So seek your solution elsewhere.
Yeah, how dare he have an opinion that runs counter to the known truth. He has attacked the Body. He is not one with Landru.