8 ms·

So, what exactly is .NET? As a non-corporate Mac user, I'd like to know.

joshuapants 12y ago
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
- mozumder 12y ago
  How does it compare to Swift/Xcode/Mac Native?
  - untog 12y ago
    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)
    - joshuapants 12y ago
      > For XCode, compare it to Visual Studio (IMO, VS is light years ahead) I agree. VS is the best IDE I've ever used by far. > For Mac Native, compare to the .NET runtime (IMO .NET is better but it's not as clear cut) The only thing I wish is that MS made it a bit easier to make .NET transparent for the user. Occasionally you need to install a version of the runtime when you install a new program, it'd be nice if that was all "built-in" and taken care of instead of adding another step to the installation.
      - runfaster2000 12y ago
        Strangely enough, the reason that this install step exists is because the .NET Framework _is_ built-in to Windows. For example, .NET 3.5 was built-in to Windows 7. If your app needed .NET 4, then it needed to formally install it on the system. If we didn't make that an option, then .NET 4 apps would not run on Windows 7, which would be bad. .NET Core is _not_ built-in to the OS, so apps can carry it within their package, meaning that there is never a need to add another step to the installation. This is a major goal of .NET Core.
        joshuapants 12y ago
        Ah thanks for clarifying. I guess I was thinking more along the lines of just always grabbing the most recent .NET through Windows Update automatically.
        runfaster2000 12y ago
        Makes sense. There is a latency of when .NET Framework versions are released and when they show up on Windows Update. Also, customer do not have to install them even when they do show up. Also, some versions don't show up on Windows Update for various reasons. That's why the install step exists.
- cheepin 12y ago
  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.
  - ilaksh 12y ago
    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.
- usef- 12y ago
  > 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.
  - ane 12y ago
    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.
    - Skinney 12y ago
      Technically, JVM doesn't have a type system, last I checked. Which is why Java (the language) uses type erasure. CLR does have a type system, but this also makes certain things harder to implement which is why, i think, Scala stopped working on their CLR compiler. The JVM was also designed as a language agnostic VM, which is why they stabilized their bytecode specification early on. There are certain things you can do in bytecode which cannot be done in Java for instance. Your criticism on the lack of user-defined value-types is valid, which they are working on for JVM 10. This is agreeably late, but better late than never.
Someone1234 12y ago
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.
- mozumder 12y ago
  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.
  - UK-AL 12y ago
    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.
  - thalesmello 12y ago
    > 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.
    - notsony 12y ago
      So when will Swift be made open-source? I am not going to make the same mistake twice and be tied down to a language (Objective-C) and private APIs (Cocoa, iOS, etc) which are useless outside of Apple's ivory tower. I had always thought of C# and Mono as a potential cross-platform solution, but now that .NET is open-source and Microsoft are pushing it hard, even on Linux, it has become a viable one. I suspect I am not the only Mac->iOS developer who is thinking along these lines.

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

mozumder 12y ago
How does it compare to Swift/Xcode/Mac Native?
- untog 12y ago
  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)
  - joshuapants 12y ago
    > For XCode, compare it to Visual Studio (IMO, VS is light years ahead) I agree. VS is the best IDE I've ever used by far. > For Mac Native, compare to the .NET runtime (IMO .NET is better but it's not as clear cut) The only thing I wish is that MS made it a bit easier to make .NET transparent for the user. Occasionally you need to install a version of the runtime when you install a new program, it'd be nice if that was all "built-in" and taken care of instead of adding another step to the installation.
    - runfaster2000 12y ago
      Strangely enough, the reason that this install step exists is because the .NET Framework _is_ built-in to Windows. For example, .NET 3.5 was built-in to Windows 7. If your app needed .NET 4, then it needed to formally install it on the system. If we didn't make that an option, then .NET 4 apps would not run on Windows 7, which would be bad. .NET Core is _not_ built-in to the OS, so apps can carry it within their package, meaning that there is never a need to add another step to the installation. This is a major goal of .NET Core.
      - joshuapants 12y ago
        Ah thanks for clarifying. I guess I was thinking more along the lines of just always grabbing the most recent .NET through Windows Update automatically.
        runfaster2000 12y ago
        Makes sense. There is a latency of when .NET Framework versions are released and when they show up on Windows Update. Also, customer do not have to install them even when they do show up. Also, some versions don't show up on Windows Update for various reasons. That's why the install step exists.
cheepin 12y ago
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.
- ilaksh 12y ago
  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.
usef- 12y ago
> 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.
- ane 12y ago
  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.
  - Skinney 12y ago
    Technically, JVM doesn't have a type system, last I checked. Which is why Java (the language) uses type erasure. CLR does have a type system, but this also makes certain things harder to implement which is why, i think, Scala stopped working on their CLR compiler. The JVM was also designed as a language agnostic VM, which is why they stabilized their bytecode specification early on. There are certain things you can do in bytecode which cannot be done in Java for instance. Your criticism on the lack of user-defined value-types is valid, which they are working on for JVM 10. This is agreeably late, but better late than never.

Someone1234 12y ago

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.

mozumder 12y ago
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.
- UK-AL 12y ago
  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.
- thalesmello 12y ago
  > 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.
  - notsony 12y ago
    So when will Swift be made open-source? I am not going to make the same mistake twice and be tied down to a language (Objective-C) and private APIs (Cocoa, iOS, etc) which are useless outside of Apple's ivory tower. I had always thought of C# and Mono as a potential cross-platform solution, but now that .NET is open-source and Microsoft are pushing it hard, even on Linux, it has become a viable one. I suspect I am not the only Mac->iOS developer who is thinking along these lines.