Hacker News Reader

It is worth pointing out that when we dropped the interpreter, we only had two or three engineers working on the VM and they had to both develop the JIT and maintain the interpreter, plus work on the GC, io-layer and other VM features.

Without a reason to keep the interpreter (the world was a JIT-friendly place back then), it made no sense to maintain it.

But times change, statically compiled environments are more common nowadays (iOS, PlayStation, Xbox, tvOS, watchOS) and with it the need to have dynamic capabilities.

To put things in perspective, adding generics to the revived interpreter probably took an engineer that was not familiar with .NET about 4-6 weeks of work.

I'm very confused as to if you believe that to be fast or slow. That seems incredibly fast for "an engineer"...

.NET is the perfect stack for the generalist.

- As a consultant if I am handed a .NET project, even if it's a ios, android, web app, or a wpf application, then I'm usually familiar with 100% of the ORMs/PDF libraries/GUIs/build systems/source controls/IDEs/web frameworks they use(excluding client side web). I can come up to speed and get running quickly whether it was built last year or 10 years ago. It's the exact opposite of the javascript environment where two different javascript apps have less in common than a ruby and python app. It also allows me to meet all my clients need well enough on one platform.

- Because of the previous item, it's perfect for enterprise which needs to be able to scale up and down teams internally.

- Tooling is built for ease of use and is amazing. A lot of tooling from my experience in the java world is more powerful but with much much steeper learning curves. Leading to far more specialization.

- Visual studio is a best in class IDE.

- It's not java. From a language perspective java is still playing catch-up.

Java is great, there are a lot of amazing open source projects on it, the big data story on java is far more compelling, you can write much better Android apps, and and large multi-department transactions financial/enterprise software. But it is in no way shape or form superior to .Net in all ways.

As generalist I find being able to do Java, .NET and the occasional C++ dive, a nice way to have the best part of all cakes. :)

.Net does have two major downsides that kill it for me entirely (as someone who has used it for 15 years now): schizophrenic roadmap and deprecation, immature libraries. The deprecation means you can't rely on the longevity of the vendor's whims to build your product on. The library issue is a biggie - there are just so much more higher quality libraries in Java. The language matters considerably less than the libraries do when you want to get from A to B.

On the library front we've used IKVM a few times where there was a java lib that did what we wanted with no equal in .NET land, e.g. Saxon XPath2 would be a primary example. However, with the developer of IKVM stepping down this has created a possible future risk.

It also doesn't help that almost 100% of the time, when I'm Googling for docs, I get sent to a page for something deprecated that may or may not still exist in the version of .NET I'm using. It seems like more often than not, I have to really hunt for up-to-date information, and even then I'm never really sure. MS direly needs to do some SEO work on MSDN.

That and the alarming amount of mixed information you get on whether or not using X is a better idea than Y, for ill-defined (from all angles, including MS), deprecation-related reasons. At least that was my experience a couple weeks ago when I got placed on a one-off .NET project.

I'll admit that I'm not terribly experienced with .NET's standard library. But I am very familiar with C# as a language and I'm comfortable using it. It was rather frustrating for the stumbling block to be what it was.

Excellent GUI frameworks on most platforms.

Much better unmanaged interop story: [DllImport] (btw it works on all platforms, e.g. on Linux it imports from .so libraries), structures, unsigned integers.

Better multithreading: thread pool, synchronization contexts, async-await.

Unsafe code, pointer arithmetic.

LINQ

Speaking of interop - the nice thing about .NET type system, is that it has facilities to do complete mapping to C, with the sole exception of setjmp/longjmp (which is generally a sore point with everything, even C++ doesn't handle it well). You already pointed out unsigned integers and structs; it's also worth pointing out raw (non-GC-aware) pointers, and explicit layout structs; the latter can handle C unions seamlessly, in particular (you just say that all fields have offset 0).

Variable-length C structures don’t map. Example of such structure:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

But they’re rarely found in APIs, and there’s Marshal class in the framework to implement manual marshaling by reading/writing stuff at unmanaged memory addresses, even without /unsafe compiler switch.

With a little syntactic sugar in C#, they do map, in the same exact way you do this in C - you just use a "fixed" array of one as the last element:

   struct VariableLength {
       public int fixedSize;
       public fixed int varSize[1];
   }

Of course, this also means that you have to use stackalloc or other manual allocation to actually get a properly sized block of memory, computing said size yourself; but you also have to do it in C with malloc:

   byte* p = stackalloc byte[sizeof(VariableLength) + 10 * sizeof(int)];
   var vl = (VariableLength*) p;

Once you have a pointer, though, you can do vl->varSize[i] etc - this works because the type of vl->varSize when you access it is int*.

Came here to say this — one of my first projects in the industry as an intern way back with .net 1.1 was to create an c# based application to parse through effectively binary serialized variable sized c structs.

"fixed" was a C# 2.0 addition, though. Back in 1.x days, you basically had to declare that field as a simple scalar instead, and then use & to manually obtain the pointer (but then you could index it with [] etc, same as in C, so it doesn't really make that much of a difference in this case; "fixed" sure did come in handy for other stuff though).

Yeah, Mark Reinhold already stated multiple times that JNI was designed on purpose to be hard, because Sun wanted to drive people away from writing unmanaged code.

Thanks to JRuby guys and Project Panama, Java will eventually get a .NET like interop story, but it is still in the future. :(

Wow when did he say that?

At the JavaOne 2013 Technical Keynote.

https://blogs.oracle.com/java/the-javaone-2013-technical-key...

<quote> He mentioned JNI 2.0 and said, “It just shouldn’t be so hard to integrate Java with native code after all these years.” </quote>

For the full context, you need to watch the keynote.

Searched a bit on Project Panama, found an example:

    @Header(path="unistd.h")

While indeed very easy to use, that API is extremely hard to implement in the runtime to make it work not just for toy examples. Authors of real world libraries do all kinds of weird stuff in their C headers: they abuse C preprocessor, implement compiler-specific hacks, and even include pieces generated by external tools.

> Excellent GUI frameworks on most platforms.

Is platform_s_ here, Windows 10, Windows 8 and other ms platforms Last time I looked GUI on Mac and Linux was far from excellent something on par with python binding to QT/gtk works but not enjoyable

> but there are way more languages targeting the JVM than the CLR these days

This is often repeated, but it turns out that the JVM and CLR have roughly the same number of high profile languages:

Specifically, the CLR enjoys the following mature languages:

    C#
    F#
    VB (which has some distinct advantages over C#)
    C++/CLI
    PowerShell
    IronPython
    Nemerle

It's also worth noting that Clojure absolutely works on the CLR, and F* (F# with a more powerful type system) just hit version 0.9.

C# (and VB), get a bit of love of HN, but they're even more powerful than they get credit for. C# has monad comprehensions, a metaobject protocol[1], and can straight-forwardly simulate type classes (in the form of implicit conversions to constructed classes). So, as a language, C# can get close to both Scala and Clojure even without having higher-kinded types, multimethods, or macros.

[1] https://books.google.com/books?id=QGciuyBRyU0C&pg=PA119&lpg=...

> "IntelliJ is every bit the match for Visual Studio"

What debugging features does IntelliJ have that are of equal or superior utility compared to IntelliTrace?

https://blogs.msdn.microsoft.com/zainnab/2013/02/12/understa...

It has the same feature, called chronon

>but HotSpot seems so dramatically far ahead and the distance is increasing.

Benchmarkgame scores reached basically parity between java and C# once .net core 2.0 dropped

.NET selling points:

* you can do some SIMD explicitly, more is coming

* you have control over when things are stack allocated or not. structs, stackalloc, slices

* you have unsigned ints

Hm, seems like the big win for C# was actually someone going in and optimising the benchmark programs themselves:

http://anthonylloyd.github.io/blog/2017/08/15/dotnetcore-per...

The point of explicit control is usually performance though. So if Java can give you near equal or better performance but without the developer having to explicitly specify as much, isn't that a win?

Benchmark game also lacks the benchmark the Mono blog post is all about - developer iteration time.

In many cases, Java actually can't give you near equal or better perf. "Our optimizer is smart enough, you don't need to care about stack-allocating things" has been the promise for as long as Java existed, but it doesn't really deliver that outside of fairly simple cases (which are also the ones that are typically benchmarked).

Java's new partial escape analysis should help with that.

>So if Java can give you near equal or better performance but without the developer having to explicitly specify as much, isn't that a win?

It would be, but often times the lack of explicit control causes you to need more verbosity in Java to get around it, because the JIT isn't all knowing. For instance say you want an array of 2D vectors (x,y) and you want them in line in the array for data locality. In C# you just make Vector a struct, and put the structs in the array. In Java you would have to just put float primitives in the array and alternate the x and y and keep track of it by hand. Minecraft suffers greatly from this.

As well, Java won't do anything but the most trivial automatic vectorization, and only on integers, and SIMD can be a huge win at times. I'm looking forward to more complete support droping for .net

>Benchmark game also lacks the benchmark the Mono blog post is all about - developer iteration time.

F#

Single file static AoT compilation. Does the JDK support this yet?

Since the early days for anyone willing to pay for commercial JDKs, only Sun was against AOT compilation.

For those that rather use only OpenJDK, there is Linux x64 AOT support on Java 9, with improved support for other platforms in Java 10 roadmap, some of it already in master.

As for F#, currently it is lacking some love from.NET Framework, UWP and Visual Studio teams, which always think about C# and VB.NET terms. Even C++ seems to be better supported.

I would say Scala is on par with F#. And there's also Kotlin if you're looking to transition a Java team to a static FP language more gently. And there's Clojure if you prefer a dynamic Lisp.