181–190 of 305 posts
Earlier quoted context omitted.
Writing a generic function to sum an array of any numbers type is trivial in C++. There's no 4 day research period, even if you're new to templates. template T sum(T* x, size_t size) { T acc = 0; for(size_t i = 0; i
Isn't acc and the xs same width here? So you risk overflow?
Earlier quoted context omitted.
Generics are great when you need them, but they will cut you badly if you misuse them. Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too. Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that…
Please show code then I dont remember misusing C# generics even once and I struggle to see example of such a case
Earlier quoted context omitted.
Generics are great when you need them, but they will cut you badly if you misuse them. Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too. Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. As opposed to, say, adding a new field to a class, that…
>Generics are viral. When you make something generic, you often have to make the things that touch or contain it generic, too Do you have an example of that? Can't you always "typedef" any particular generic type as a concrete type and work with that going forward? >Generics also create tight coupling. When you change the definition of a generic interface/class, you'll need to update your usage across the codebase. A…
> Have you ever wanted an interface (or abstract type) to be parameterized on a polymorphic variable to its implementer, but not its users? Have you ever wanted to parameterize over internal state, without revealing what that state contains to your users? This is what existential types allow you to do.
Earlier quoted context omitted.
This is not the case with traits/type class approach seen in Rust/Haskell.
I'm afraid that it most certainly is, as Rust is the only language I have ever used generics in, and I had this problem. Lifetimes suffer from the exact same problem as well, since they're really an exotic form of generic. That said, I will readily admit that it was a lack of skill on my part. From talking to people in the Rust community though, I gather this isn't an uncommon experience.
Earlier quoted context omitted.
Go 's compilation speed is only impressive for newer generations that never used compilers for Pascal dialects, Modula languages, BASIC,....
True but they didn't have to deal with the complexity of the modern software where a typical project can pull in thousands of dependencies (transitively).
Earlier quoted context omitted.
I'm afraid that it most certainly is, as Rust is the only language I have ever used generics in, and I had this problem. Lifetimes suffer from the exact same problem as well, since they're really an exotic form of generic. That said, I will readily admit that it was a lack of skill on my part. From talking to people in the Rust community though, I gather this isn't an uncommon experience.
They're not viral in rust - you can always replace the generic with a concrete type in super types.
Earlier quoted context omitted.
This requires an exception mechanism to handle allocation failure. This issue pervades C++ when exceptions are disabled. Important error handling goes unhandled.
How does Go handle allocation failure? In my understanding objects may be allocated on the stack or heap per the compiler's whims. If a heap allocation fails, you just get "fatal error: runtime: out of memory" and an abort.
Earlier quoted context omitted.
I’m pretty sure Go’s maintainers were aiming for “mere” practical success, as opposed to some theoretical success that only academic languages succeed at.
What's the definition of "success" here? Popularity?
Earlier quoted context omitted.
Can’t hate on generics, so we need to find something else. Go takes away type system fidget spinners and leave devs with nothing to do but the actual job, which they hate, and thus they hate Go.
No it's simpler than that, they hate Go cause it's a half-assed language. The creators didn't respect developers enough to make it consistent and complete cause "devs are not smart enough". The argument about "getting things done" is like saying the language is Turing complete.
Earlier quoted context omitted.
How does Go handle allocation failure? In my understanding objects may be allocated on the stack or heap per the compiler's whims. If a heap allocation fails, you just get "fatal error: runtime: out of memory" and an abort.
Your understanding is correct. That's also what you will effectively get with C or C++ on Linux anywhere you would have had a choice between C++ and Go to behind with.