> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you…
Agreed. I find C# and F# surprisingly refreshing. ReasonML is a bit unfinished, but it's a sign of great things to come.
> I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java Now that you mention it, I can't really blame them! > On the other hand I've never heard…
Yes, I'm aware that they're a special case. What I mean is that this is exactly what is traditionally called "generics" or "parametric polymorphism" in PL literature. Go's Map/Array/Slice called "predefined generic…
I'm familiar with that article, and it got me excited for a while, but it's about compiler implementation, and it doesn't really have much to do with the current discussion, other than rationalizing the opposition for…
> they also remove the rails that keeps Go code pretty consistent But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not…
Exactly. For a while .NET Core also had a folder within the project for third-party NuGet modules, and for a simple web app they would go into the 200mb, and that's without the compiler itself. Now those files live in a…
They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.
Go has interface{}, which can be abused as much as generics for the same purpose, but without the type safety, hence, less secure. And nobody is advocating C++ style template metaprogramming. There are much better…
Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.
> Those techniques work well for design systems. That's true! I find that enforcing a consistent and quickly-changing design system is way easier than when I was using old techniques. > Instead of doing the…
> Yes, but by far more important are bounds checks. Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great…
I personally find most implementations of generics to be in the class of "boring and predictable". I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but…
In recent projects I tried 3 new approaches: React's CSS-in-JS, Vue's Scoped CSS and Tachyons/Tailwind Atomic CSS. All of those solutions were a huge improvement and scaled better than any of the previous pure-CSS…
> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.
> Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Except when it isn't. Except when it crashes in production. I believe…
> It's not a webpack add-on. It's a part of Vue's templating engine that is essentially CSS-in-JS, they just give you a template to work in. It's regular CSS in the templates and regular CSS in the frontend. There's no…
> Meanwhile Vue is neither HTML [1], nor strictly speaking CSS [1], and has a very wierd concept of how objects work in JS. Vue Templates are a very thin DSL on top of HTML. It's just markup. Once you understand that,…
> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said,…
Just curious: why don't you want generics in Go? The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}. It's not as if Go is a language…
It's a CRUD app. Nothing special about it. It just happens to use this specific stack.
> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. > I stopped working when my node modules directory topped 60mb and I still hadn't made a data…
> And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :) That's fair! I'm really sorry I typed that, it was completely uncalled for and I wasn't referring to you…
Agreed. I find C# and F# surprisingly refreshing. ReasonML is a bit unfinished, but it's a sign of great things to come.
> I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java Now that you mention it, I can't really blame them! > On the other hand I've never heard…
Yes, I'm aware that they're a special case. What I mean is that this is exactly what is traditionally called "generics" or "parametric polymorphism" in PL literature. Go's Map/Array/Slice called "predefined generic…
I'm familiar with that article, and it got me excited for a while, but it's about compiler implementation, and it doesn't really have much to do with the current discussion, other than rationalizing the opposition for…
> they also remove the rails that keeps Go code pretty consistent But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not…
Exactly. For a while .NET Core also had a folder within the project for third-party NuGet modules, and for a simple web app they would go into the 200mb, and that's without the compiler itself. Now those files live in a…
They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.
Go has interface{}, which can be abused as much as generics for the same purpose, but without the type safety, hence, less secure. And nobody is advocating C++ style template metaprogramming. There are much better…
Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.
> Those techniques work well for design systems. That's true! I find that enforcing a consistent and quickly-changing design system is way easier than when I was using old techniques. > Instead of doing the…
> Yes, but by far more important are bounds checks. Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great…
I personally find most implementations of generics to be in the class of "boring and predictable". I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but…
In recent projects I tried 3 new approaches: React's CSS-in-JS, Vue's Scoped CSS and Tachyons/Tailwind Atomic CSS. All of those solutions were a huge improvement and scaled better than any of the previous pure-CSS…
> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.
> Whenever I fed the wrong argument in for a void* parameter (which is rare enough), the program crashed on the first try and the problem is obvious. Except when it isn't. Except when it crashes in production. I believe…
> It's not a webpack add-on. It's a part of Vue's templating engine that is essentially CSS-in-JS, they just give you a template to work in. It's regular CSS in the templates and regular CSS in the frontend. There's no…
> Meanwhile Vue is neither HTML [1], nor strictly speaking CSS [1], and has a very wierd concept of how objects work in JS. Vue Templates are a very thin DSL on top of HTML. It's just markup. Once you understand that,…
> "You can't ship software in a language without generics!" Isn't this is a strawman? Most arguments in favor of generics in this thread and elsewhere are well informed and people just want safer code... As you said,…
Just curious: why don't you want generics in Go? The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}. It's not as if Go is a language…
It's a CRUD app. Nothing special about it. It just happens to use this specific stack.
> Coming from the .NET toolchain and expecting a lightweight, easy to start with approach I was yet again totally shocked. > I stopped working when my node modules directory topped 60mb and I still hadn't made a data…