91–100 of 168 posts
> Everything is broken. Everything is fine. This is the correct conclusion. The people getting outraged over this are the same that will hold long and boring monologues about how everybody does REST wrong.
Earlier quoted context omitted.
Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.
> added it without many issues Except for the fact that all CLR languages must adopt the same variance model, enforced by the runtime (or choose not to interoperate well).
The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.
> If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe. And conceivably a good deal faster, too. My understanding is that the JVM is required to constantly perform runtime type checks.
The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.
Just use dynamic or better yet type-tag-free languages. Types are hard to get right and hard to reason about. Sure, there are some Sheldons out there who master it even under pasta applications, but most of us are not Sheldons. C# also bleeped up types by adding nullable types, making reflection into a scavenger hunt. For dynamic or tag-free languages, type indicators could be used to parse-check scalar (base) values…
Earlier quoted context omitted.
Unlike Java, Go doesn't have to worry about bytecode backwards compatibility. That was the main issue that had them reaching for type erasure. Take a look at C# which added it without many issues (because they were willing to break back compat of their bytecode). Go fits this model a whole lot better.
Did C# really break backwards compatibility of their bytecode? What I understand is that C# generic and non generic APIs are completely different, and are not inter operable.
To the 2nd - The concrete types are separate, but they fit into a common interface hierarchy, so, at a source code level, they're plenty interoperable. For example, the (non-generic) IEnumerable interface has a Cast() extension method that will convert it to a (generic) IEnumerable. IEnumerable, for its part, simply inherits IEnumerable.
In general, I actually like using those conversion methods for downcasting, because it gives a clearer indication of when I'm in a danger zone - for example, converting a non-generic list to a generic list might fail if the non-generic list contains a mix of different types of object. Java's situation feels less predictable to me, as this article illustrates fairly well. A few keystrokes for the sake of safer code is a dandy tradeoff in my book.
Earlier quoted context omitted.
Just use dynamic or better yet type-tag-free languages. Types are hard to get right and hard to reason about. Sure, there are some Sheldons out there who master it even under pasta applications, but most of us are not Sheldons. C# also bleeped up types by adding nullable types, making reflection into a scavenger hunt. For dynamic or tag-free languages, type indicators could be used to parse-check scalar (base) values…
> C# also bleeped up types by adding nullable types, making reflection into a scavenger hunt. Having used reflection in C# with both nullable types and non-, I'm curious what you mean by "scavenger hunt".
Earlier quoted context omitted.
This is HN, we don't need seat belt analogies. Very strict type systems forbid this class of errors during compilation, others do a best effort and fail at runtime.
Whoever you are, analogies can help clarify your thinking. A type system that prevents some errors is not without value just because it cannot catch others. If the uncaught types of errors are rare and the type system that would solve them somehow burdensome it may even be a reasonable compromise to accept these faults.
A language like rust can prevent writing code like that, and thus prevent that sort of error, while a language like javascript is even more lax. Both have their tradeoffs wrt productivity and performance.
The mess that is the current Java type system makes me skeptical when proponents of languages like Go say not to worry, that generics can be added later. If Java had generics in the beginning, it would look a lot different and the type system would be more powerful and safe.
Just use dynamic or better yet type-tag-free languages. Types are hard to get right and hard to reason about. Sure, there are some Sheldons out there who master it even under pasta applications, but most of us are not Sheldons. C# also bleeped up types by adding nullable types, making reflection into a scavenger hunt. For dynamic or tag-free languages, type indicators could be used to parse-check scalar (base) values…