Swift, Scala, and C# are statically-typed languages, like Java, whereas Apache Groovy is dynamically-typed originally -- though static typing was added in Groovy 2, virtually no-one uses it. Dynamically typed languages like Groovy are good for glue code, build scripts, and testing, not for developing actual systems.

There was also nant and a number of build tools, plus good old make.

I find type inference to be the opposite, generally, because it encourages good naming, and it reduces noise/boilerplate. It also makes writing and refactoring faster (don't have to think about the return types, just the code flow).

The only situation I can even think of where it is a problem is when you are passing something to an overloaded method. For example:

    void DoSomething(MySpecialType value);
    void DoSomething(string value);

    ////

    var result = GetData();
    DoSomething(result);
  

* GetData() is probably badly named in this situation

* If DoSomething() does something very different depending on the type passed, it should have different names, not be overloaded

On top of that, this code can also have the same problem without type inference:

    DoSomething(GetData())

99% of the time it's completely obvious what the variable is because you can just look at the right side of the equal sign.

Also, you can just hover over it.

As for the extension methods, they pretty much fixed that in VS 2015, it will now tell you which using statement you need to include.

Extension methods are a good solution to a specific problem.

Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<string, Tuple<int, List<string>>>();

Is prefferable to:

var foo = new Dictionary<string, Tuple<int, List<string>>>();

What do you get from the former that makes the eye-pain worth it?

Also, the var keyword is necessary for anonymous types if you want to hold a reference to one. And this is a language feature I sorely miss in Java-land.

Java is a shitty language exactly because they don't put in things like these out of fear that people don't know how to use them.

One thing that VS can now do (as of VS 2015) is tell you where exactly the "missing" extension method is, and offer to add a corresponding `using` declaration for you.

Not sure if VSCode or VS/Mac support that, though. But they are all built on the same code analysis engine, so there's no reason why they couldn't.

Extensions methods can be approached via default methods.

Java 9, latest by 10, will get var. It is already on the approved roadmap.

There are still uses though. Lambdas are the future, but there are lots of OO-first libraries that are still quite popular. It'd be nice to create e.g. `new Newtonsoft.JsonConverter() { ReadJson() {...} WriteJson() {...}}` etc on the fly sometimes without needing separate classes.

It's possible in F# though, so nothing dotnet specific is preventing it.

    public static final MyInterface SINGLETON = new MyInterface() {
        ...
    }