7 ms·

> Technically there is nothing I don't like about JVM right now, everything that seems impossible 15 years ago is now solved. Value types are a major missing p

> Technically there is nothing I don't like about JVM right now, everything that seems impossible 15 years ago is now solved. Value types are a major missing piece in the JVM stack right now. It's at least on the roadmap, but it keeps getting pushed back and back and back. I'd also argue runtime generics is another one, and perhaps more depressingly one that is unlikely to ever get fixed. .NET has both of them and also has the same core strengths JVM does, so given the choice I'd go with .NET over JVM 100% of the time as a result. JVM's GC & JIT seem to be on a never ending improvement cycle, but the actual language & core libraries are incredibly slow to react to anything.

btilly 8y ago
.NET is tied to Microsoft, so I'd avoid it 100% of the time. Yes, yes. I know that Microsoft theoretically open sourced and ported it. However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only. Otherwise I agree that it is a better Java.
- wilsonnb3 8y ago
  I don’t think is true anymore. The .net 5 announcement was very clear that .net core is the future and its been a while since you’ve had needed things that are windows only to build a non-trivial .net core application.
  - btilly 8y ago
    Please double check my wording. Yes, you can write a non-trivial .NET application on Linux. But if you take a non-trivial .NET application that runs on Windows, the odds are low that it can easily be ported to Linux. And there are almost no non-trivial .NET applications that weren't originally written for Windows. The result is that if you work with .NET, you're going to be pushed towards Windows.
    - kiriakasis 8y ago
      It the wording of the announcement (taking them in good faith) that applies to applications using .NET Framework. .NET Core should be 100% portable to Linux/Mac/wasm. .NET 5 should supersede both Core and Framework IIRC
      - btilly 8y ago
        I have been hearing announcements about how Microsoft was working to make .NET code portable ever since Mono was first started in 2001. In the years since, I've encountered many stories that attempted to make use of that portability. All failed. I've seen the promise of portability with other software stacks, and know how hard it is. I also know that taking software that was not written to be portable, and then making it portable, is massively harder than writing it to be portable from scratch. So, based on both the history of .NET and general knowledge, I won't believe that .NET will actually wind up being portable until I hear stories in the wild of people porting non-trivial projects to Linux with success. And I will discount all announcements that suggest the contrary.
        scarface74 8y ago
        I have been hearing announcements about how Microsoft was working to make .NET code portable ever since Mono was first started in 2001. Microsoft didn’t have anything to do with Mono until 2016. If you start from scratch with a greenfield .Net Core project there aren’t really any issues getting it to work cross platform.
    - scarface74 8y ago
      You are no more “pushed toward Windows” with new code you do with .Net Core than you are if you use any other cross platform language. While I’ll agree that anything that uses any of the advanced features of Entity Framework and MVC is not trivially ported.
      - btilly 8y ago
        When you're trying to write new code, you run into a problem and look for a library that solves it. But all of the libraries that you find are Windows First, and it is not until after you're committed to them that you sometimes discover how they are Windows Only. So yes, even in a new project, there will be a pull back to Windows. Because virtually nothing is truly written from scratch.
  - spjt 8y ago
    Looking at the announcement it seems they're basically folding all of the Windows-specific stuff back into .net core. Isn't that just going back to a compatibility minefield?
- GordonS 8y ago
  They didn't "theoretically" open source it - they actually open sourced it. I get why people used to shit on Microsoft, but Microsoft has demonstrated over a number of years that its changed under Satya. > However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only. Outside of desktop GUIs, this is simply not true. I'm writing complex, cross-platform systems that work just fine on Windows and Linux (and would on MacOS if I chose to target it). Hell, even a lot of the tooling is now cross-platform: Visual Studio Code, Azure Data Studio, even Visual Studio and Xamarin run on MacOS!
  - jhasse 8y ago
    No, Visual Studio does notrun on macOS. Visual Studio for macOS is a fork of MonoDevelop.
    - scarface74 8y ago
      So because it’s not the same code base but it is produced by the same company with the same purpose? It’s not “Visusl Studio Code”? Was Photoshop not Photoshop on Windows when the assembly language optimizations were different between PPC and x86?
MaxBarraclough 8y ago
> the actual language & core libraries are incredibly slow to react to anything. async/await being the obvious example. Still no sign of it in the Java language, nor any expectation of it, unless I missed something.
- pron 8y ago
  https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the project lead)
  - yawaramin 8y ago
    > Fibers are user-mode lightweight threads that allow synchronous (blocking) code to be efficiently scheduled, so that it performs as well as asynchronous code Sounds a lot like Erlang BEAM processes.
    - pron 8y ago
      Yep; or Go's goroutines. Except that the fibers are implemented and scheduled in the Java libraries; the VM only provides continuations.
      - mycall 8y ago
        How does it compare to Windows fibers?
  - cozos 8y ago
    I find this really interesting. Care to provide some comparisons?
  - MaxBarraclough 8y ago
    Great article, thanks. Some perhaps-silly questions: 1. Is it possible to inspect the state of a 'parking' operation, the way you can in .Net with Task#Status? 2. So fibers run in 'carrier threads'. Is there a pool of carrier threads, or can any thread act as a carrier? I'm thinking of .Net's where this is configurable (ignoring that .Net 'contexts' aren't exactly threads), by means of Task#ContinueWith() and the Scheduler class. I take it from the following snippets that fibers can only run on the thread where they were created: starting or continuing a continuation mounts it and its stack on the current thread – conceptually concatenating the continuation's stack to the thread's – while yielding a continuation unmounts or dismounts it. And also: Parking (blocking) a fiber results in yielding its continuation, and unparking it results in the continuation being resubmitted to the scheduler. On a non-technical note, how do OpenJDK projects feed back into the Java spec and Oracle Java?
pron 8y ago
> .NET has both of them I'll give you value types, but reified generics in .NET were a mistake. It really makes interop and code sharing among languages hard, in exchange for a rather slight added convenience. This means that if you're a language implementor and you're targeting .NET, you'll get much less from the platform than you would if you target Java, which makes .NET not a very appealing common language runtime. And not only is Java a good platform for Kotlin and Clojure, but thanks to Truffle/Graal it's becoming a very attractive, and highly competitive, platform for Ruby, Python and JavaScript. All of that would have been much more difficult with reified generics. Also, I don't think value types in Java are being "pushed back." The team is investing a lot of work into them as it's a huge project, but AFAIK no timeline has been announced. > and also has the same core strengths JVM does I don't think so. Its compilers are not as good, its GCs are not nearly as good, and its production profiling is certainly not as good (have you seen what JFR can do?); and its tooling and ecosystem are not even in the same ballpark.
- bunderbunder 8y ago
  I see it as a double-edged sword. On the one hand, reified generics means that it's .NET's object model or the highway. On the other hand, .NET maintains a much higher standard of inter-language interoperability. When I was on .NET, I didn't have to worry much about the folks working in F# accidentally rendering their module unusable from C#. Now that I'm on the JVM, I've accepted that it's just a given that the dependency arrows between the Java and Scala modules should only ever point in one direction.
  - pron 8y ago
    It's not .NET vs Java so much that the development of the two languages you mention are coordinated. For Kotlin and Clojure interop works both ways; Scala doesn't care much about that, so Scala developers write special facades as Java language API. There are lots of different languages on Java, and they care about different things. The Java team itself develops only one language, although at one time there was another (JavaFX Script). Some language developers (Kotlin, JRuby) work more closely with the Java team, and others (Scala) hardly ever do.
- 8y ago

btilly 8y ago

.NET is tied to Microsoft, so I'd avoid it 100% of the time. Yes, yes. I know that Microsoft theoretically open sourced and ported it. However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only. Otherwise I agree that it is a better Java.

wilsonnb3 8y ago
I don’t think is true anymore. The .net 5 announcement was very clear that .net core is the future and its been a while since you’ve had needed things that are windows only to build a non-trivial .net core application.
- btilly 8y ago
  Please double check my wording. Yes, you can write a non-trivial .NET application on Linux. But if you take a non-trivial .NET application that runs on Windows, the odds are low that it can easily be ported to Linux. And there are almost no non-trivial .NET applications that weren't originally written for Windows. The result is that if you work with .NET, you're going to be pushed towards Windows.
  - kiriakasis 8y ago
    It the wording of the announcement (taking them in good faith) that applies to applications using .NET Framework. .NET Core should be 100% portable to Linux/Mac/wasm. .NET 5 should supersede both Core and Framework IIRC
    - btilly 8y ago
      I have been hearing announcements about how Microsoft was working to make .NET code portable ever since Mono was first started in 2001. In the years since, I've encountered many stories that attempted to make use of that portability. All failed. I've seen the promise of portability with other software stacks, and know how hard it is. I also know that taking software that was not written to be portable, and then making it portable, is massively harder than writing it to be portable from scratch. So, based on both the history of .NET and general knowledge, I won't believe that .NET will actually wind up being portable until I hear stories in the wild of people porting non-trivial projects to Linux with success. And I will discount all announcements that suggest the contrary.
      - scarface74 8y ago
        I have been hearing announcements about how Microsoft was working to make .NET code portable ever since Mono was first started in 2001. Microsoft didn’t have anything to do with Mono until 2016. If you start from scratch with a greenfield .Net Core project there aren’t really any issues getting it to work cross platform.
  - scarface74 8y ago
    You are no more “pushed toward Windows” with new code you do with .Net Core than you are if you use any other cross platform language. While I’ll agree that anything that uses any of the advanced features of Entity Framework and MVC is not trivially ported.
    - btilly 8y ago
      When you're trying to write new code, you run into a problem and look for a library that solves it. But all of the libraries that you find are Windows First, and it is not until after you're committed to them that you sometimes discover how they are Windows Only. So yes, even in a new project, there will be a pull back to Windows. Because virtually nothing is truly written from scratch.
- spjt 8y ago
  Looking at the announcement it seems they're basically folding all of the Windows-specific stuff back into .net core. Isn't that just going back to a compatibility minefield?
GordonS 8y ago
They didn't "theoretically" open source it - they actually open sourced it. I get why people used to shit on Microsoft, but Microsoft has demonstrated over a number of years that its changed under Satya. > However the way that this always works is that there is a base that can be written in, but anything non-trivial will have pulled in something that, surprise surprise, is Windows only. Outside of desktop GUIs, this is simply not true. I'm writing complex, cross-platform systems that work just fine on Windows and Linux (and would on MacOS if I chose to target it). Hell, even a lot of the tooling is now cross-platform: Visual Studio Code, Azure Data Studio, even Visual Studio and Xamarin run on MacOS!
- jhasse 8y ago
  No, Visual Studio does notrun on macOS. Visual Studio for macOS is a fork of MonoDevelop.
  - scarface74 8y ago
    So because it’s not the same code base but it is produced by the same company with the same purpose? It’s not “Visusl Studio Code”? Was Photoshop not Photoshop on Windows when the assembly language optimizations were different between PPC and x86?

MaxBarraclough 8y ago

> the actual language & core libraries are incredibly slow to react to anything. async/await being the obvious example. Still no sign of it in the Java language, nor any expectation of it, unless I missed something.

pron 8y ago
https://wiki.openjdk.java.net/display/loom/ https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the project lead)
- yawaramin 8y ago
  > Fibers are user-mode lightweight threads that allow synchronous (blocking) code to be efficiently scheduled, so that it performs as well as asynchronous code Sounds a lot like Erlang BEAM processes.
  - pron 8y ago
    Yep; or Go's goroutines. Except that the fibers are implemented and scheduled in the Java libraries; the VM only provides continuations.
    - mycall 8y ago
      How does it compare to Windows fibers?
- cozos 8y ago
  I find this really interesting. Care to provide some comparisons?
- MaxBarraclough 8y ago
  Great article, thanks. Some perhaps-silly questions: 1. Is it possible to inspect the state of a 'parking' operation, the way you can in .Net with Task#Status? 2. So fibers run in 'carrier threads'. Is there a pool of carrier threads, or can any thread act as a carrier? I'm thinking of .Net's where this is configurable (ignoring that .Net 'contexts' aren't exactly threads), by means of Task#ContinueWith() and the Scheduler class. I take it from the following snippets that fibers can only run on the thread where they were created: starting or continuing a continuation mounts it and its stack on the current thread – conceptually concatenating the continuation's stack to the thread's – while yielding a continuation unmounts or dismounts it. And also: Parking (blocking) a fiber results in yielding its continuation, and unparking it results in the continuation being resubmitted to the scheduler. On a non-technical note, how do OpenJDK projects feed back into the Java spec and Oracle Java?

pron 8y ago

> .NET has both of them I'll give you value types, but reified generics in .NET were a mistake. It really makes interop and code sharing among languages hard, in exchange for a rather slight added convenience. This means that if you're a language implementor and you're targeting .NET, you'll get much less from the platform than you would if you target Java, which makes .NET not a very appealing common language runtime. And not only is Java a good platform for Kotlin and Clojure, but thanks to Truffle/Graal it's becoming a very attractive, and highly competitive, platform for Ruby, Python and JavaScript. All of that would have been much more difficult with reified generics. Also, I don't think value types in Java are being "pushed back." The team is investing a lot of work into them as it's a huge project, but AFAIK no timeline has been announced. > and also has the same core strengths JVM does I don't think so. Its compilers are not as good, its GCs are not nearly as good, and its production profiling is certainly not as good (have you seen what JFR can do?); and its tooling and ecosystem are not even in the same ballpark.

bunderbunder 8y ago
I see it as a double-edged sword. On the one hand, reified generics means that it's .NET's object model or the highway. On the other hand, .NET maintains a much higher standard of inter-language interoperability. When I was on .NET, I didn't have to worry much about the folks working in F# accidentally rendering their module unusable from C#. Now that I'm on the JVM, I've accepted that it's just a given that the dependency arrows between the Java and Scala modules should only ever point in one direction.
- pron 8y ago
  It's not .NET vs Java so much that the development of the two languages you mention are coordinated. For Kotlin and Clojure interop works both ways; Scala doesn't care much about that, so Scala developers write special facades as Java language API. There are lots of different languages on Java, and they care about different things. The Java team itself develops only one language, although at one time there was another (JavaFX Script). Some language developers (Kotlin, JRuby) work more closely with the Java team, and others (Scala) hardly ever do.
8y ago