What magic are you talking about? Various .Net frameworks have silly amounts of magic, but C# itself?
- Class extensions: I saw code examples online that just wouldn't work for me because the compiler told me a certain method of a built-in class wouldn't exist. After I while I found out that the author of that snippet had used class extensions and not bothered to mention.
- The var keyword: While this is sometimes nice for quick scripting or hacking in the debugger console, it opens the door for hard-to-read code.
Those are not necessarily "magic", but potential obscurities that can't happen in Java, simply because Java lacks these features.
For most devs, Visual Studio isn’t a realistic option.
Windows is the de facto standard in most places that aren't chasing the leading edge.
I’m not sure anyone would agree with that.
Unless you also count designers, and kids who just learnt how to click together a website in Frontpage 2000 as developers.
Especially if you count compsci graduates, it becomes very obvious just how much *nix dominates.
But good job with the warrantless and wrong contempt.
Project Rider by Jetbrains is a cross platform C# IDE.
VS Code has some tooling.
etc...
Project Rider is still extremely green and is not FOSS, nor free as in free beer.
VS Code is extremely limited and the little support it has is for .NET Core only.
I'm right now working on an MVC 5 project on Linux and I have to jump around MonoDevelop and Rider to have a workable dev environment; with the occasional jump to a Windows VM and Visual Studio to make sure everything works over there (it often doesn't).
.NET IS NOT a viable stack for developing on Linux and it's an inferior one in macOS. If you want to do real work with it you have to eat, breathe and live Windows and VS.
If I didn't absolutely have to work with .NET in this particular situation I would've laughed all my way back to a real cross-platform stack.
.NET isn't, and wasn't officially meant to be. That's your problem.
I've been working on a .net core web app on my mac exclusively now for the last 8 weeks and have had no problems with it. I do check to make sure it works in full VS/Windows occasionally and every single time its worked without fail, and without a single change. Just pull the code and go. I haven't needed to touch windows but its nice to know it still works over there anyway.
Using VS Code as my main editor. Tried Rider a little yesterday and I'll probably switch to that once its more stable as it has a few more tools for refactoring etc.
So .NET core is clearly what's intended to be used cross platform, and it works great.
Idk about Swift, never used it yet.
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())I see what you mean, but isn't this one of the advantages of explicitly declaring types? If you refactor a method to return a different (incompatible) type, you'll have to touch all affected code parts, possibly revealing uninteded consequences of the change.
Also, I think remembering that autocompletion in VS had some trouble with correct type inference in some cases. But it's been a couple of years, maybe things are different now.
If you can refactor your code such that you change the return type of a method such that it returns an object of a different type, which nonetheless implements all of the methods used by clients of your type that accept and return types which in turn accept and return types that line up with the expectations of their clients, etc, etc, without having to look at or touch any of those clients, and end up with something that happily compiles but gives an unexpected result, you need to have a long and hard look at how you're using the language's type system, and why it isn't encoding your assumptions in a sane way.
Your code shouldn't be compatible with a different type unless it makes sense for your code to be compatible with that type. That's what the type system is for.
Sure, different types shouldn't use the same method name for different functionality, but it happens. And when such a scenario happens, I imagine it will be quite nasty to debug.
I've used var since it came out years ago and never had this autocompletion problem you talk about.
You sometimes had to explicitly declare a type in foreach loops, but that had more to do with shitty legacy APIs that used abstract classes as return types. Wasn't really var's fault though.
You have a Toilet object with a method flush.
var toilet = house.getToilet();
toilet.flush();
I agree this problem would also occur when using chained calls (house.getToiled().flush()), but explicit types could cover at least some of the cases.
This has happened to me exactly 0 times since type inference was introduced in 2007/2008.
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.
Dictionary<string, Tuple<int, List<string>>> foo = new Dictionary<>();
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.
TL;DR: Java has something similar, it just came from a different view of how the problem should be solved. Both approaches have advantages and drawbacks.
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.