Think of it as like the Java runtime environment, but not terrible.
You have two main pieces: the Common Language Runtime, which is the virtual machine (like the JVM) that executes the code. Then you have the library it comes with, which is fairly large compared to most languages.
> Think of it as like the Java runtime environment, but not terrible.
What's terrible about the JVM/JRE?
Many people complain about the language Java (conservative language, programmer culture of complexity...), or the web browser plugin for the JVM (security vulnerabilities, bad startup performance...), but I've generally heard good things about the JVM itself.
The JVM type system uses type erasure (which means that any generic type Blah<T> becomes Blah at runtime), so you can't instantiate types based on generics at runtime. In C# it is valid to do "T foo = new T();" and because of reified generics, this works. You can't overload functions based on their generic type ("Foo(List<int> ...) and Foo(List<string> ...)" on the JVM (the <...> bit gets erased!). This was done to preserve binary backward compatibility when generics were introduced in Java.
The CLR supports user-defined value types whereas the JVM doesn't, it relies on a classical uniform data representation. Because value types are stack allocated, in C#, you will have less stress on the GC (because you can define stack-allocated value types), on the other hand, the JVM GC will be doing a lot more work. This is why you see "the JVM is heavily optimized" statements.
Another downside of the JVM is that it has no native support for tail call optimization, this is not that major, but it is a bit silly for functional languages running on the JVM (Clojure). The Scala compiler is intelligent enough to do this by itself, but there's no native support on the VM itself, unlike on the CLR.
Another point is that the CLR was designed as a true language-agnostic virtual machine, so developing new languages on it is easy. It is not hard to do that on the JVM, but more so than on the CLR.
One of the interesting things I'm waiting to see is if .NET gets good enough to become the "main" platform for compile to VM languages like Clojure. It can already compile to .NET, but it's significantly less used than the JVM version, despite .NET generally being easier to target.
It is like the Java runtime, but started afresh with all of Java's learned lessons taken into account (although Java with 7 and 8 in particular is catching up).
Up until now however it has only ran on Windows which was its biggest "downside" Vs. Java which runs on many platforms.
> started afresh with all of Java's learned lessons taken into account
I don't think that's really historically accurate. Java and C# were pretty similar back in 2002. The .NET team was more willing to add complexity and occasionally make breaking changes, like generics in CLR 2.0.
That's not historically accurate either. The .Net team was more willing to break things because in 2002 they had their 1.0 release. By then Java had already lived through 6 years of very aggressive presence in the marketplace, with lots of legacy code already in the wild. The only legacy MS had to worry about was COM, which had its own compatibility wrappers that were not fundamentally intrinsic to the CLR.
So .Net had the advantage of coming years after Java had shown what it could be done (or not, see browser applets) from a technological and commercial point of view, AND quite a few years of development without worrying about backward compatibility.
I'm not saying Sun developers were not slow (they were), but they clearly had a much more "entrenched" position, with all that it entails.
It's not that simple. The CLR has a different feature set to the JVM; or rather, it has a feature superset. If you run Java-like code on the CLR, I would expect it to not be as fast or have as high GC throughput as Hotspot, especially if the Java code has been tuned to Hotspot - there are particular fast paths for certain operations that kick in, where if your code is a little bit too far from the optimized idiom, you end up 3-5x slower. For regular code, I wouldn't expect a big gap between CLR and JVM; a lot of Java code is dominated by pointer chasing because the primary tool of abstraction is a heap-allocated object. C# written in the same way will be bottlenecked in similar ways on cache misses, TLB misses, etc.
There's a larger variety of JVMs designed for a broader range of hardware, the most interesting to me being Azul and their GC tech.
But the CLR gives you some different tactical options. Value types and unsafe code let you do things that are far more expensive or awkward on the JVM. Writing a significant amount of functionality that does no heap allocation is more feasible on the CLR than JVM. Native interop is an order of magnitude easier. The CLR is generally much faster to start up; Java terminal apps don't suit interactive use. The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
The CLR offers a lot of functionality that the JVM doesn't (see Someone123's comment) - which in my opinion makes is it a lot more compelling - so in that way it is more sophisticated than the JVM.
A reference to back your statement up would be great... (i couldn't find a good one quickly). Are you aware of the capabilities of the CLR's next generation RyuJIT? What you say is at odds with what I thought, but I'd love my perceptions to be corrected if they are indeed incorrect.
One advantage is developing server-side .NET apps without the need of a Windows VM, with the aid of regular Unix tools in your regular dev environment. That's a win in my book.
But a cross-platform CLR opens up some possibilities even for desktop or CLI apps. The wealth of the .NET ecosystem is compelling.
> I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?
Well, probably it is better if you have (say) a company full of people who know how to write C# but have never used Swift. And the whole write once run anywhere thing is nice (sure, native apps "feel" better, but if there are no native apps I'd rather have a Java version than nothing).
Think of it as like the Java runtime environment, but not terrible.
You have two main pieces: the Common Language Runtime, which is the virtual machine (like the JVM) that executes the code. Then you have the library it comes with, which is fairly large compared to most languages.
edit: Added more context
> Think of it as like the Java runtime environment, but not terrible.
What's terrible about the JVM/JRE?
Many people complain about the language Java (conservative language, programmer culture of complexity...), or the web browser plugin for the JVM (security vulnerabilities, bad startup performance...), but I've generally heard good things about the JVM itself.
The JVM type system uses type erasure (which means that any generic type Blah<T> becomes Blah at runtime), so you can't instantiate types based on generics at runtime. In C# it is valid to do "T foo = new T();" and because of reified generics, this works. You can't overload functions based on their generic type ("Foo(List<int> ...) and Foo(List<string> ...)" on the JVM (the <...> bit gets erased!). This was done to preserve binary backward compatibility when generics were introduced in Java.
The CLR supports user-defined value types whereas the JVM doesn't, it relies on a classical uniform data representation. Because value types are stack allocated, in C#, you will have less stress on the GC (because you can define stack-allocated value types), on the other hand, the JVM GC will be doing a lot more work. This is why you see "the JVM is heavily optimized" statements.
Another downside of the JVM is that it has no native support for tail call optimization, this is not that major, but it is a bit silly for functional languages running on the JVM (Clojure). The Scala compiler is intelligent enough to do this by itself, but there's no native support on the VM itself, unlike on the CLR.
Another point is that the CLR was designed as a true language-agnostic virtual machine, so developing new languages on it is easy. It is not hard to do that on the JVM, but more so than on the CLR.
2 replies →
One of the interesting things I'm waiting to see is if .NET gets good enough to become the "main" platform for compile to VM languages like Clojure. It can already compile to .NET, but it's significantly less used than the JVM version, despite .NET generally being easier to target.
People have been using the CLR like that for many languages for many years. Maybe you didn't hear about it because it was a Windows thing.
.NET was good enough when it came out many years ago. It was just a closed one platform thing.
How does it compare to Swift/Xcode/Mac Native?
You've listed three very different things there.
For Swift, compare it to C# (depends on personal preference)
For XCode, compare it to Visual Studio (IMO, VS is light years ahead)
For Mac Native, compare to the .NET runtime (IMO .NET is better but it's not as clear cut)
4 replies →
It is like the Java runtime, but started afresh with all of Java's learned lessons taken into account (although Java with 7 and 8 in particular is catching up).
Up until now however it has only ran on Windows which was its biggest "downside" Vs. Java which runs on many platforms.
> started afresh with all of Java's learned lessons taken into account
I don't think that's really historically accurate. Java and C# were pretty similar back in 2002. The .NET team was more willing to add complexity and occasionally make breaking changes, like generics in CLR 2.0.
That's not historically accurate either. The .Net team was more willing to break things because in 2002 they had their 1.0 release. By then Java had already lived through 6 years of very aggressive presence in the marketplace, with lots of legacy code already in the wild. The only legacy MS had to worry about was COM, which had its own compatibility wrappers that were not fundamentally intrinsic to the CLR.
So .Net had the advantage of coming years after Java had shown what it could be done (or not, see browser applets) from a technological and commercial point of view, AND quite a few years of development without worrying about backward compatibility.
I'm not saying Sun developers were not slow (they were), but they clearly had a much more "entrenched" position, with all that it entails.
The JVM is much more sophisticated than the CLR. Its GCs and JIT are many, many years ahead of the CLR's.
It's not that simple. The CLR has a different feature set to the JVM; or rather, it has a feature superset. If you run Java-like code on the CLR, I would expect it to not be as fast or have as high GC throughput as Hotspot, especially if the Java code has been tuned to Hotspot - there are particular fast paths for certain operations that kick in, where if your code is a little bit too far from the optimized idiom, you end up 3-5x slower. For regular code, I wouldn't expect a big gap between CLR and JVM; a lot of Java code is dominated by pointer chasing because the primary tool of abstraction is a heap-allocated object. C# written in the same way will be bottlenecked in similar ways on cache misses, TLB misses, etc.
There's a larger variety of JVMs designed for a broader range of hardware, the most interesting to me being Azul and their GC tech.
But the CLR gives you some different tactical options. Value types and unsafe code let you do things that are far more expensive or awkward on the JVM. Writing a significant amount of functionality that does no heap allocation is more feasible on the CLR than JVM. Native interop is an order of magnitude easier. The CLR is generally much faster to start up; Java terminal apps don't suit interactive use. The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
6 replies →
I'll just direct you to the first reply on Stackoverflow here: https://stackoverflow.com/questions/453610/javas-virtual-mac...
1 reply →
The CLR offers a lot of functionality that the JVM doesn't (see Someone123's comment) - which in my opinion makes is it a lot more compelling - so in that way it is more sophisticated than the JVM.
A reference to back your statement up would be great... (i couldn't find a good one quickly). Are you aware of the capabilities of the CLR's next generation RyuJIT? What you say is at odds with what I thought, but I'd love my perceptions to be corrected if they are indeed incorrect.
1 reply →
That really isn't true. Perhaps 5 years ago it was but not now.
1 reply →
So, why would a Mac user develop in it, instead of in a Windows (virtual) machine?
How would .NET compare to Apple's native environment?
I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?
I mean, Java never really caught on with the Mac user base.
One advantage is developing server-side .NET apps without the need of a Windows VM, with the aid of regular Unix tools in your regular dev environment. That's a win in my book.
But a cross-platform CLR opens up some possibilities even for desktop or CLI apps. The wealth of the .NET ecosystem is compelling.
> I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?
Well, probably it is better if you have (say) a company full of people who know how to write C# but have never used Swift. And the whole write once run anywhere thing is nice (sure, native apps "feel" better, but if there are no native apps I'd rather have a Java version than nothing).
> I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?
You said it all. The whole point is cross platform development.
People use Swift to develop apps for Apple products. Before Dot.net was made open source, people only used it to develop for Microsoft platforms.
The fact Dot.net is now crossplatform makes it possible for GNU/Linux and Mac users to consider it for development.
1 reply →
For mac users, it's probably going to used for web development rather than native apps.
Although there are some good bindings to cocoa to do so.