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 uncalled for and I wasn't referring to you specifically!

Because "generics" as a feature suffices to support multi-paradigm programming.

I don't really agree with that. Despite being widely used in functional languages, they aren't really a "functional" thing, as much as static typing is.

In fact, I'd argue that Go already has a feature that is much more important and representative of funcional programming than anything else: higher order functions. [1] With higher order functions (and recursion!) you can implement pretty much anything functional.

Generics don't really allow for much more than something like interface{} can already give. The problem is that interface{} comes with both runtime performance and type-safety penalties. Generics could fix that and help programmers arrive at better/safer practices, IMO.

My point is: with generics the language could be much simpler and we'd have to rely less on (IMO) complicated/unsafe features like Reflection and interface{}.

[1] http://aquaraga.github.io/functional-programming/golang/2016...

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 anyone bitch about well designed generics in other languages. Which is a tell since people will bitch about anything and everything.

That's my opinion as well. Generics are quite pleasant, simple and a great tool to have when they're well designed.

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 types" in some literature.

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 the feature.

About your other points: nope, generics wouldn't remove simplicity in the language itself. They would mostly legitimize with type-safety certain idioms that are already present in current Golang code. And the terrible error messages of C++ templates are not really a good example. There are much better languages now when it comes to generics.

I suggest that maybe you try looking into other legitimate uses of generics? The Fibonacci-Tree<K,V> example you gave earlier is unrealistic, and the other example being thrown around here, STL, is too complex... There are lots of legitimate reasons for someone wanting generics in a language, and nobody is advocating for them out of bad faith, or wishing to kill a nice language with feature bloat :(

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 inconsistent with the rest of the language at all.

For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative

Why would generics break that? Funcional programming and type-safety/polymorphism are orthogonal concepts. IIRC, generics were introduced in Barbara Liskov's CLU language, which is imperative.

It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

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 hidden folder (or were absorbed by the stdlib), and nobody complains about it anymore.

Initiatives like Yarn's plug-and-play [1] would have the side effect of being great marketing for Node.js development.

[1] https://github.com/yarnpkg/rfcs/blob/master/accepted/0000-pl...

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 implementations of generics, as acknowledged by Russ Cox himself.

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 "configuration" in your CSS when you're coding, you basically have an intermediate step where you set up those rules in advance, and can just focus on composition itself.

You summed it up perfectly

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 feature), and easier to use daily than go generate. I dunno.

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 generics as they are implemented in C# and Java are pretty cool and simple.

IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code generation. I mean, the complexity is already there... why wouldn't generics simplify those use cases?

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 techniques I was using before.

BUT the key here is that those things only work when you rely on React/Vue/etc components. If you have have to rely on copy/pasting markup, things go wrong FAST and you lose track of your app style and things get duplicated. You also to have to enforce SMALL components. If you duplicate markup between components things get hard (but not as nasty as if you weren't using components).

I honestly believe that people not using modern frameworks can't see the advantages of any of those techniques, and would urge everyone to try them out in component-based project.

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 this is the kind of situation people are trying to avoid with type safety...

Maybe the more serious problem is that people want to be able to quickly say "I want a Fibonacci-Tree<K,V> for types K and V"?

That's uncalled for, isn't it? There's a lot of non-toy problems solved elegantly and pragmatically using generics. I personally enjoy how Entity Framework uses it.

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 JS involved anywhere, unless you count the tooling, but we already use JS tools for CSS processing (PostCSS).

Scoped CSS is an old HTML5 feature that was dropped in favor of style encapsulation using Shadow DOM/Web Components.

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, everything falls into place.

"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, you can already have generics using unsafe solutions. Some built-in types have generics. Most people just want this type safety.

interface{} does feel like a temporary and clunky solution for people used to generics.

And lastly, one thing that you can't really appreciate without trying Go--the lack of generics/expressiveness and general simplicity of the language largely means everyone writes the same boring, predictable code, which means you can pretty much pick up any project on GitHub or your own code from years ago and understand it almost immediately.

I don't get this argument. Why are generics more complicated than other features? Has this hypothesis been tested?

I personally find that using generics is way easier and faster than interface{}, Reflection or code generation. Also simpler and less error-prone than features from other languages like inheritance, operator overloading and unbounded coroutines.

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 without warts... there's a lot of ugly stuff, like Iota, Reflection, the error handling, interface{} itself.

This is a legitimate question, btw. Legitimately looking for other points of view

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 layer.

This is cute.

I have a 40gb virtual machine with Windows + VS Enterprise and SQL Server, that I have to use to work on a single .NET project that can't be migrated to .NET Core yet.

What is 60mb compared to that?