241–250 of 318 posts
Earlier quoted context omitted.
I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!
Yes, constantly. I've rarely seen generics overused.
Earlier quoted context omitted.
Only if the cost-benefit works out, and there isn't a better solution.
And that's clearly the case with generics.
Earlier quoted context omitted.
> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between. The problem with interface{} is that it makes it pretty much worthless to have a type system at all.
Generics in java work via type erasure, so is the same as interface{} by the time the code is running.
As for saying "they are the same once the code is running", well, duh, of course, but it's completely useless by then.
Earlier quoted context omitted.
I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!
Overused in what way? Do you have an example of what you mean by that? I'm having a hard time understanding where using generics would cause problems. C++ templates, sure, but those are much more powerful than just having parametric polymorphism.
C++ templates! I keep on running into places where I'm debugging, then I find myself in a maze formed by template overuse, then debug around that instead.
just having parametric polymorphism
I think that could be workable in Go. I can imagine how debugging that would be straightforward.
Earlier quoted context omitted.
> Yes, the first couple of weeks were a bit rough while I was getting used to the ownership system, but since then I have been progressing at a relatively quick pace. This is the very definition of "high barrier to entry". Clearly it wasn't too much of a barrier for you but I can see how it'd be an issue for people. I'm expecting editor support and wider adoption (differently constructed tutorials, SO answers) to low…
I can see that, but a couple of weeks of investment doesn't seem "incredibly high" to me.
When I say something like "incredibly", it's after thinking about trying to teach it someone more junior (like you'd see in a corporate environment with a mix of skill levels). I think that this would be a very difficult task.
Earlier quoted context omitted.
> The problem with interface{} is that it makes it pretty much worthless to have a type system at all. I don't understand this argument. You need `interface{}` about 1% of the time; somehow it's better to have no type checking than only 99% type checking? Even in the 1% of cases, I've literally never seen a production bug (or even a failed test case) caused by a type error. I'm sure they happen, but I doubt they happ…
Except the 99% (though in my experience more like 80% of the cases where generics would be considered in other languages) of the time you are refraining yourseld from using interface{} and perhaps choosing another bad solution (lesser of the evils)
Earlier quoted context omitted.
If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects.
> If you're doing that all over the place, you're doing it wrong. I've never seen Go code that looks like that in real projects. Yet it is there in the language. Why is that? how do you justify adding this to a statically typed language?
Earlier quoted context omitted.
>C++ doesn't have reflection How would you describe RTTI?
Can you create adhoc types from nothing with RTTI ? because in Go you can, at runtime. Is it what a statically typed language which community claims generics are unnecessary should prioritize as a feature ? runtime magics ? really ?
Earlier quoted context omitted.
Most of the times we couldn't do the refactorings/changes we wanted to, it was because we could only be 99.9% sure and not 100% sure someone didn't stick some goofy value somewhere to denote something special. Also, I'm not so sure that Smalltalk as a language community and as a programming environment did what it took to get everyone to do the right thing. In Swift, it seems like the programmer would quickly learn t…
Interesting point about refactoring and "doing the right thing", didn't think about that angle, thanks for the reply!
I've had a little exposure to Go and seen how rapid development in Go can be while still maintaining decent performance. Is anyone aware of scientific stack development in Go? Specifically, does HN think thee will be a Numpy or Scipy equivalent in Go or does this not make any sense?