31–40 of 44 posts
It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?
If you live in JVM land and value modern development you are probably already on Groovy, Gradle and Grails - where Grails imo. is ahead of the MVC4/5/6 stack...
It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?
> What are the chances of Enterprise switching to .Net instead of Java? Plenty of enterprise shops are Microsoft full-stack shops (Windows Server/.NET/SQL Server/IIS). I get the impression -- though I haven't seen systematic data -- that .NET has been making gains against JVM as an Enterprise platform.
Both Java and .Net are viable, relevant and widespread technologies. It all depends on which segment of the market you happen to be catering to.
Earlier quoted context omitted.
> What are the chances of Enterprise switching to .Net instead of Java? Plenty of enterprise shops are Microsoft full-stack shops (Windows Server/.NET/SQL Server/IIS). I get the impression -- though I haven't seen systematic data -- that .NET has been making gains against JVM as an Enterprise platform.
It mostly depends on perspective. I work .Net enterprise and NEVER hear of Java - giving me the obvious false impression that it is Java that is unused. The only thing under the Sun that we really hear of is Oracle: that's one or two customers. Both Java and .Net are viable, relevant and widespread technologies. It all depends on which segment of the market you happen to be catering to.
Earlier quoted context omitted.
As I understand it, Graal+Truffle is basically the DLR. This has been around since 2008 from Microsoft. Both IronPython and IronRuby have used this for years. The "Day 1" comment was specifically pointed at the read-between the lines for Graal, which is basically to create a real IL for Java instead of using the InvokeDynamic semantic that is currently envogue for Scala, Clojure, etc. .NET has had the multi-language…
Graal is a JIT compiler done in Java, it has nothing to do with DLR. Graal together with SubstractVM offer AOT compilation and is also being used by AMD for the GPGPU support targeted for Java 9, latest Java 10. Truffle is more of a AST manipulation framework for nodes that can be fed into Graal for compilation. Then there are those meta-circular JVMs like JikesRVM which are done in Java.
Earlier quoted context omitted.
Graal is a JIT compiler done in Java, it has nothing to do with DLR. Graal together with SubstractVM offer AOT compilation and is also being used by AMD for the GPGPU support targeted for Java 9, latest Java 10. Truffle is more of a AST manipulation framework for nodes that can be fed into Graal for compilation. Then there are those meta-circular JVMs like JikesRVM which are done in Java.
But SubstrateVM, Graal, Truffle, isn't ready for another few years. ( I haven't heard much since 2013.... )
Sumatra is planned for integration latest by Java 10.
There were a few Java ONE 2014 and JVM Language Summit Presentations.
JRuby: The Hard Parts, Reduction on GPUs, GPU/JVM Cooperation
http://www.oracle.com/technetwork/java/javase/community/jlss...
Ruby on Top of Graal
https://old.parleys.com/share_channel.html#play/543f88bee4b0...
Sumatra OpenJDK Project Update: Parallelize Yourself with the Stream API
https://old.parleys.com/share_channel.html#play/543fa782e4b0...
I'm surprised it's hosted by the .NET Foundation. I feel the .NET Foundation operates somewhat independently from Microsoft, but there is a large alignment with what Microsoft wants. Using LLVM feels like a departure from some of the things they're working on now. Some blog posts I have read on the MSDN Developer Tools Blogs suggested Microsoft was already working on their own AOT compiler, this statement seems to su…
Anything regarding coreclr seems to be handled with a goal of being through and through cross-platform.
Because of this tools like cmake, LLVM etc are used instead of Microsoft in-house tools. Because of this, formerly closed-source tools like MSBuild are now being made open-source.
It's a departure from how Microsoft traditionally have done things in the past, but it's perfectly aligned with where the .NET Foundation is currently going.
Earlier quoted context omitted.
It mostly depends on perspective. I work .Net enterprise and NEVER hear of Java - giving me the obvious false impression that it is Java that is unused. The only thing under the Sun that we really hear of is Oracle: that's one or two customers. Both Java and .Net are viable, relevant and widespread technologies. It all depends on which segment of the market you happen to be catering to.
It just seems that Google, Twitter, Facebook or many other big Data companies will have some / many pieces of tech dependent on JVM. But I never heard anyone them using .Net
That doesn't make either language/runtime bad or better than the other. Their strengths aren't static, either. They are merely different tools suited for different tasks. Both have some extremely large names using them.
Mailing list post: http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-April/084459... And also check out LLVMSharp -- http://www.llvmsharp.org which gives LLVM access to .NET Disclaimer: I'm involved in both projects.
> LLILC is an LLVM based MSIL Compiler - we pronounce it 'lilac' - with a goal of producing a set of cross-platform .NET code generation tools. Today LLILC is being developed against dotnet/CoreCLR for use as a JIT, but an ahead of time (AOT) compiler is planned for the future.
The mailing list post is a bit clearer to my mind, and I'm now rewording the above in "layman's language" as follows, but I may still be wrong (please correct me):
"Today, LLILC is a modified version of CoreCLR (= .NET Core, which is the part of .NET which was open sourced by Microsoft in November 2014) where the code generation backend is replaced with LLVM (but still working as a JIT). We're also planning to implement an ahead of time compiler for MSIL (= CIL, which is what the .NET bytecode is a form of), also using LLVM, but then perhaps forgoing the use of (most of?) CoreCLR. The aim is also to make it possible to use the wide array of tools available in the LLVM ecosystem, such as code analyzers."
It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?
https://github.com/dotnet/llilc/blob/master/Documentation/ll...
When will I be able to get my MVC websites running in node?