Viewing profile — latronic_notron

> 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 unc…

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 the…

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/Arra…

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 …

> 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…

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 com…

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 metap…

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 techniqu…

> 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 …

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…

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 …

> 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 …

> 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 w…

> 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 r…

> 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 j…

> "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 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 interfa…

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…