Recently I found about two new programming languages(Vala and google's GO) which don't support method or function overloading and intend on not supporting them in the future ever! The creators of these languages say that overloading is evil and should not be used!(in system programming?)

I was told that the creators of Go Language even say that classes inheritance are evil as well and Go doesn't support that!

My question is:

Are they really that bad that the new languages are omitting them? Or Is there a specific field of usage for that languages which makes them evil? What could be the disadvantage of using such facilities at all?

  • 2
    By "GOO", do you mean Go?
    – user7043
    Jan 19, 2013 at 18:33
  • 4
    Anything can be evil if it was being misused.
    – neo
    Jan 19, 2013 at 18:38
  • 6
    Some people, when discovering a programming language has features that tend to be abused by poor programmers, create a lobotomized language. See, for example, Java (operator overloading is evil! multiple inheritance is evil!). Now, unless they invent something to replace it, they have two problems: boilerplate code, and unhappy skilled programmers. But they no longer have the original problem. Then, skilled programmers forced to use the lobotomized language write pet projects in languages they actually like.
    – JasonTrue
    Jan 19, 2013 at 20:17
  • 4
    Overloading isn't necessary in Go as Go methods can accept arbitrary types as arguments. In languages that support overloading, it is mostly used to provide the conceptually identical action with different input types. In other words, they tend to be statically typed languages. In languages where a method can take arbitrary data (for instance: python), overloading is unnecessary. Jan 19, 2013 at 21:31

3 Answers 3


I can see where they're coming from, but as rules I would say these are way too specific for 100% restriction in a language design.

Gigantic 18+ layer convoluted inheritance schemes are pretty well-established as an anti-pattern for instance but inheriting 1-3 levels deep can be perfectly reasonable for solving certain problems depending on what other things a language design allows.

Likewise, it's fairly easy to see how method overloading could be done to excess, making an API so overwrought that you'd have to check the docs every time just to figure out how to use a method for the one of 16 ways you actually need it to work. Whereas, used responsibly, it's fairly easy to see how overloading for similar types in the same pattern could be completely reasonable and not at all difficult to remember. That, even more so than the inheritance thing strikes me as an odd feature to restrict wholesale. But, full-disclosure: I'm comfortable with a paradigm where everything is mutable, you don't have to declare a method twice to overload its arguments, and first class functions rain down from all over the place like candy from a busted-open pinata.

That said, just because I don't like it, doesn't mean languages can't make a good case for being highly restrictive. Java for instance (as I understand it) is essentially a design response to the issue of C/C++ code tending to allow so much granular control that it can be very hard for two devs to understand each other's code. Java's inherent conservatism/protectionism allows a lot more developers to work together on the same project while having less trouble understanding what the other devs are on about because, for instance, everything absolutely must be in a class. And you don't get things like pointers which are certainly powerful but can also very easily turn a code-base into a waking nightmare in mediocre hands. I might argue that most of the time having a lot of developers in the first place is its own problem but I wouldn't go so far as to say this is never a necessity or that they'd always be better off with the dynamic flexibility of JavaScript or the full-on close-to-chrome granular control of C++.

I would however argue that a general purpose language should probably be more flexible than Java is but that's not something 75% of Stack is likely to agree with me on necessarily.

Languages are inherently about design trade-offs. What this really comes down to is how sold you are on the philosophy in terms of solving the problems you typically need to solve. In this case, I think they're being silly for the vast majority of problems I've personally needed to solve but most of that is web UI stuff.

  • 1
    +1, because this is a well-reasoned, useful, and fairly relevant answer, but I feel compelled to point out that the OP was asking about "method or function overloading", not "operator overloading". The two are related, of course, but they're definitely distinct: some languages, such as Java, support the former but not the latter, and some, such as Perl, support the latter but not the former.
    – ruakh
    Jan 20, 2013 at 3:35
  • Silly me. I thought that at first but then corrected for some reason. Probably from browsing one of the other answers and thinking I'd misread the question. Jan 20, 2013 at 15:40
  • Corrected for method. Still fit the general theme of being a design-tradeoff. Jan 20, 2013 at 15:47

Classes, method overloading, operator overloading... they are all tools. They are suitable in some circumstances, not in others. Don't try to apply labels like "evil" to such things; instead, strive to understand them so you can decide for yourself whether they are useful or not.

  • i didn't say they are evil, if i remember correctly it was mentioned in valas mailing list)
    – Hossein
    Jan 19, 2013 at 19:27
  • Well stated. If you have a solid grasp of the concept, you can do really cool things; don't box yourself in to thinking one thing is better than another, the box keeps you from innovating and creating.
    – Johnnie
    Jan 19, 2013 at 23:49

The premise of your question is flawed: GOO supports both overloading and classes.


Not the answer you're looking for? Browse other questions tagged or ask your own question.