Hacker News Reader

Comment by alexandercrohde | Hacker News Reader

This reads like sour grapes.

Basically, this is trying to spin "Popular language missing essential feature" into "But what if it's because they're braintstorming something EVEN BETTER???"

Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first.

Plus I think the language-obsession is usually cargo-culting and signaling. All good engineers I know use and enjoy several languages. The hipster/all-talk/buzzword engineers are the ones who insist on prototyping garbage in a new language every 6 weeks and dropping it entirely thereafter.

View on HN

>Popular language missing essential feature

But is it an essential feature? I've written a lot of Go code and I'm perfectly fine without generics. It makes my code a lot simpler, no need to abstract everything into Thing<OtherThing implementing Stuff, YetOtherThing<Thingie implementing This or That>>. By the way, C doesn't have generics.

If you really need generics that badly for your use-case, nothing stops you from using another language.

Bringing up C invokes my suspicions about this debate: It's really people with totally different use cases talking past each other.

C doesn't have generics. Java has extremely limited generics. In both cases, it means that it's annoying and difficult for me to write a decent math library. I have to choose among making it support only one numeric type, implementing many copies by hand (one for each numeric type), or using some sort of ugly code generation tool - who knows what in Java, the preprocessor in C - to implement all those copies.

Which might not be a problem for everyone, but, for my use case, it's annoying.

(Deliberately avoiding the "generic library of data structures" use case because, while generics are what brought that to most of us (edit - in the world of static typing), it would appear that Go's handling that case just fine without them.)

I'd say either resort to code generation or pick another language that fits better your use-case.

Yeah, sorry if I wasn't being clear. That's pretty much the line I was thinking along.

It's perfectly fine for Go's answer to be, "Go doesn't have generics because generics aren't needed to solve the kinds of problems Go is designed for solving, and we are not trying to be a kitchen sink language here. If generics are something you need, please pick a language that's designed to solve the problems that you're trying to solve."

But that's a far cry from what TFA said. TFA read more to me as, "Go doesn't have generics because generic programming is a half-baked idea that isn't ready for prime time."

Or, to throw a third option one out there -- "Go doesn't have generics because they would interact poorly with some other aspect of the language." That works, too.

For example, it's why F# continues not to have ad-hoc polymorphism, despite many users clamoring for it. I'm inclined to agree with the project's maintainers on the subject. As useful a thing as it is, and as glaring as it is for a modern descendant of ML not to have it, it's hard to see how it could be added without creating all sorts of language warts.

Both F# and C# can do ad-hoc polymorphism - I use it in my language-ext library [1], the library is C# but the principle is the same for F#. It's not idiomatic (or pretty), but it's possible if needed. Higher-kinds is the killer missing feature.

[1] https://github.com/louthy/language-ext#ad-hoc-polymorphism

> I think Go should be comfortable not being suitable for writing certain classes of programs. I don’t think programming languages should compete with each other in an attempt to become the perfect solution to every problem. This is impossible, and attempts will just create a messy kitchen sink that solves every problem poorly.

is a quote from the article, and seems to say exactly what you're saying?

C does have generics since C11, although relatively constrained.

To me, despite the name, _Generic(...) doesn't really count. It's more like a switch statement that lets you switch on a type instead of a value. You still have to manually write all your own implementations, which leaves you firmly in territory covered by the 2nd option I listed.

Maybe I'm missing something, though. On the rare occasion that I write C code, I stick to C99, so I haven't had much occasion to use it.

If you nitpick enough, nothing is essential. We can write everything in C, or heck, even assembly.

"If you're not happy go look elsewhere" doesn't move the needle on the question "Should Go have generic" at all. It's not an argument at all.

Then should all languages have all features?

As the author explains in the article, I don't think all languages should try to solve all problems perfectly.

I don't see how that is the point I made. The point I made was that an argument should be given as to whether a feature should be in the language or not.

Note that this leaves the possibility that a feature should not be in the language, even if it does solve a real problem.

Both arguments do not address whether the language should have a feature or not.

"Not essential" might be recast as a valid argument, but must be rephrased in terms of cost vs benefits of the feature examined wrt the goals of the language.

Of course it isn't an essencial feature, all the older timers here had to code with programming languages without generics support for a couple of decades.

By the way, C has minimal generics support since C11.

I'm not super educated on this, but the example I'm asking is "How would you port the library lodash to your language without generics?"

"Porting lodash" isn't an end unto itself, but you can use `interface{}` everywhere and have the same degree of type safety that lodash enjoys, which is to say zero.

You can also use lodash with TypeScript, and get a great deal more safety than that...

Granted, but "lodash" is still a means and not an end.

> Well, if they're brainstorming something better, then I'll wait to use your language until you solve all the basic problems first.

Yet people can write distributed databases, monitoring tools, dns/DHCP servers in go. ANd they deliver stable and performant solutions with thousands of institutional users.

How come, if the basics are not solved?

That is a meaningless statement. You can do anything in (almost)any language that doesn't mean the basics are solved.

The parent should have said, "Go is regularly used to ship..." instead of "Go can be used...". The fact that Go backs all sorts of complex, interesting software testifies that it has solved the basics extrememly well, and if you're going to argue for a definition of "the basics" which doesn't respect shipping software then your argument is self-defeating. "Generics" isn't an end unto itself, after all.

> The parent should have said, "Go is regularly used to ship..."

So does C, C++, Java, etc. That statement is meaningless. It just means that with enough contortion, you can write some code in golang that works. But that doesn't mean mean there aren't better, safer ways to write code. As others said, you can write large systems in C, but we still see the fallouts of using a very limited and unsafe language.

And the funny things is, how do some of these larger projects get around golang's limititions? They write code generators to emulate mocking and generics, ending up with a weird mix of code that is difficult to manage. I saw this at my current employer, where they use golang for most of their backend. It's funny that I always think that even writing in Java would make the code base a lot more maintainable and even shorter and less verbose.

> So does C, C++, Java, etc. That statement is meaningless.

You're not following the conversation. The question is "Does Go solve 'the basics'?", not "Is Go better than C, C++, Java, etc?". I noted that Go solves 'the basics' for any meaningful definition of the term, as evidenced by regularly shipping useful software; I didn't claim that "regularly shipping useful software" makes it better than other languages.

> And the funny things is, how do some of these larger projects get around golang's limititions? They write code generators to emulate mocking and generics, ending up with a weird mix of code that is difficult to manage. I saw this at my current employer, where they use golang for most of their backend. It's funny that I always think that even writing in Java would make the code base a lot more maintainable and even shorter and less verbose.

This is a fallacy. A code generator is a pain in the ass to work around generics, but it's entirely possible and likely that the efficiencies gained by Go (versus Java or other candidate languages) more than justify the losses due to a code generator compared.

It's also entirely possible and likely that people are throwing code generators at problems (like mocking) that don't require or benefit from code generators.

> So does C, C++, Java, etc. That statement is meaningless. It just means that with enough contortion, you can write some code in golang that works.

Indeed it's as capable as those languages in this domain. The productivity is higher though, thanks to the stdlib.

Go's stdlib is a tiny portion of what Java and .NET offer.

Yes those are two bloated stdlibs.

On the contrary, they are feature rich with capabilities that Go still hasn't found a proper way to support, like something comparable to Swing.

Naturally turning into name calling is easier when running out of arguments.

Java hasn't found a proper way to support something comparable to Swing. :)

If Java's standard library is reasonably sized, what is your idea of a bloated standard library? How often do you use SOAP? Applets? Open MBean? CORBA? Relation?

> Naturally turning into name calling is easier when running out of arguments.

I like many of your posts. This one is just gratuitous ad hominem.

You say this as if swing is a plus for java. It looks alien everywhere. Is it used by eclipse by the way?

It is used by JetBrains products, a fairly small company selling developer tools, you might have heard you them.

They happen to sell an IDE for Go.

They did pop up in short period of time and go projects are generally considered quite stable - how can you achieve those without "basics being solved"? IMHO basics is precisely what they did solve exceptionally well.

I used to write full blown applications in Assembly as well.

With thousands of institutional users? Implementing distributed databases?

As much as old time mainframes and Novell NetWare based applications could have.

Then it was the proper choice, like go is today. I haven't heard about a lot of distributed databases in assembly.

Most successful distributed databases taking load at scale with powerful OLAP engines are written in C++, not Go.

Indeed. However go does make some inroads there for oltp workloads or simple kv like etcd.

Not with anything comparable to ScyllaDB, RavenDB, Akka, Akka.NET, Orleans.

Nobody uses ravendb or akka.

Everyone here would like some numbers, after all you must have a solid source to make such statement.

Care to provide the name of VC backed companies built around them? I do not know of any. Akka has some java shops using them. But I wouldn't call it a database.

Ravendb...

You got me lost there, first you say nobody uses them, then you mention some.

Better get those numbers straight.

You're being ungenerous. The way they are using "basics" implies that they don't have the basics they expect to have for the problems they want to solve. The fact that someone else has the ability to solve other problems using the tool is irrelevant, and only highlights that you have different expectations.

Lack of generics is a feature imo

Reply on news.ycombinator.com