The End of IKVM.NET | Hacker News Reader

The End of IKVM.NET

weblog.ikvm.net

88 pointscurtis108 comments

https://mobile.twitter.com/JeroenFrijters/status/85506465430...

This conversation between Miguel De Icaza and the author doesn't look too favorable for the author.

To be honest, though, I think the author recognises that, which is why he specifically praises MdI in his post. Knowing that he's tired and just plain pissed-off with both platforms explains both. You're right, he doesn't come out of it well, but I've certainly had days and even months when I've felt like that, and he's making the right decision: he's moving away from something that is, for him, toxic.

> he's making the right decision: he's moving away from something that is, for him, toxic.

No argument there. After working 15 years on something non trivial it's totally ok to get fatigued and bail out. I was pointing out that there doesn't seem to be a valid technical argument to it.

> My gut knows more about .NET than most brains on the .NET team

That really is quite childish, especially from someone who considers himself an old-timer

A guy who has worked on a project of this nature since the year .NET came out is objectively a .NET old-timer.

IKVM has saved my ass a number of times. The ability to, at times, give up on the .NET ecosystem and peek into the Java ecosystem for suitable open source is fantastic.

We once had a project where some genius long ago had mandated that parts communicate via FTP. Eg one program uploads a file, another program monitors the directory. Total clusterfuck, so we wanted reliable automated tests. Turns out that doing an FTP server in .NET is pretty difficult. Full-fledged commercial libraries exist, but we just wanted a stub for testing.

IKVM, Apache Mina FtpServer solved it in two hours for us. I suspect many .NET shops use IKVM this way.

Sad to see it go, but it must've been an incomprehensibly huge one man hobby project for 15 years! If I were Jeroen I'd quit a long time ago :-)

Let's hope some shops get sufficient value out of it to maintain a fork. Jeroen if you read HN, thanks!!

We have the same setup at our place. FTP communication isn't a "clusterfuck", it is the tried and tested communication method between any two large companies that aren't banks. To us, it is the only highly available and reliable one. Web services have downtimes and re-sends. Our partners practically never turn off their FTP machines.

The only difference at our place is that we assume FTP works and do our tests on the file system. We don't test whether FTP works. We know it does.

How did you deal with large files, dropped connections, and so on?

I mean, sure, FTP the protocol works fine, and so does virtually all FTP software, but for communication it lacks an important feature: the ability to tell when a file completed uploading.

When we started to upload reasonably large files on reasonably fast file systems this became problem. Our file watcher noticed that a new file arrived, but it's just started uploading. We tried polling the FTP server for connection status, but it turned out that the client supported and did at time use, resumed uploads on connection drops. We ended up having to parse each file just to tell whether it had finished uploading. The file fortunately was an enormous XML dump, so we could check completeness pretty cheaply.

All of this work would've been avoided with a transactional protocol such as HTTP.

I've almost exclusively seen this handled using an upload with a temporary filename (usually convention based) and then renamed on completion. Watch then for the existence of the renamed files. Clean up temp files after a defined amount to time (30 days for example).

Ahyes, smart. We didn't control the client, unfortunately, so we couldn't do that.

(we tried to communicate with the people who did but they turned out to be the supplier to the supplier to the customer of our customer, 5 countries away, and fixing anything at all was not high on their priority list :D)

Afterwards change the extension to .xmlok or .xmlfail (alt: zip it), no need for vendor adjustments

Did that to, even open sourced a client to remove folders depending extension and x days https://github.com/NicoJuicy/CLI-Cleanup-IO

Ftp was because of legacy though, I would have preferred http post

Not sure what you mean by huge, but our partners frequently upload 100+ MB files in various XML, IATA and EDI formats. We also use an FTP client locally to read the file back. We don't trust the file system state when it is being controlled by a server.

I'm guessing that the FTP server does the job of not showing half-finished files, since I've never heard of a half-finished file being read back from an FTP server in 15 years. I may have to validate this assumption, though.

The benefit of FTP is that it allows you to resume transfers which is especially important with huge files. HTTP is not particularly nice in that regard. It can also be unclear where exactly the HTTP server is storing the intermediate data. If you're not careful it'll try to store the file in-memory before writing it to disk.

Like tvjames mentions, you can rename the file once complete. Alternatively you can ask for a .md5 file to be uploaded as well and, if all else fails, you can simply poll for the "last changed" time of a file and assume that if it wasn't touched for 15 minutes it's probably done.

I think FTP the protocol would've been fine, and indeed is best suited for the job. The problems really stemmed from having to poll the filesystem because the FTP server was also not under our control. If you embed the FTP server in your app (say, with IKVM ), you can keep the whole intermediate file where you want (or even in RAM if it fits) and this entire problem shrinks 10x.

I beg to differ. HTTP is far better for any usecase than FTP.

I understand that sometimes one has to work because of constraint imposed from parties beyond the control of the project. This may force one to support FTP. But FTP is still a terrible protocol. Uploading files to a directory and processing those from a batch job is not a proper solution to an event driven solution.

> To us, it is the only highly available and reliable one.

As one who has had some experience with FTP I must say that you should consider reading after the meaning of HA and reliability.

> Web services have downtimes and re-sends

This is pure bullshit, pardon my French. How does FTP save you from a connection trouble? How does FTP have less downtime? FTP is a stateful protocol, cannot be simply load balanced and made HA. Also idempotency makes some HTTP operations safe to redo if connection troubles arouse.

For really huge amounts of data there is BitTorrent.

I don't have a fr-en translator available so I will try to keep it simple for you. FTP does not require restarts or reloads, and lets you continue broken uploads. The only scaling is you can do here is vertical scaling. Sorry if that doesn't fit your world view where every service must be containerized and horizontally scaled. No matter what you do, some ignorant losers will keep on using their single server ftp and call it reliable because that is their experience.

Do these parts need to communicate rarely, but with HUGE binary blobs? Because in this case it does sound like a good design, actually.

Eve then a HTTP POST/PUT is better than FTP, but the parent sated this was not their decision, but a constraint.

>I’ve slowly been losing faith in .NET.

That piece is interesting. I don't know many .NET developers that aren't excited with what Microsoft has been doing with .NET over the last couple years. Can anyone shed light on why someone would be losing faith in it?

They mentioned .Net 3.5, which is ancient by modern programming standards; if I had to guess, the general direction towards generics, dynamic, and functional support? But take that with a huge grain of salt. This post is from a library author, so their opinion is probably going to vary a lot with application developers (especially those of us who never did much with Mono, but are utilizing Core already in production with Linux).

The author's twitter sheds some insight (scroll down a bit): https://mobile.twitter.com/JeroenFrijters

At the same time his blog post states that his recent twitter doings aren't completely the true cause here. Makes you wonder what else happened.

Yes I read the blog. My comment is an attempt to help answer the GP's question ("Can anyone shed light on why someone would be losing faith in it?") not "why did IKVM end?"

Something I know has been a big roadblock for IKVM is the fragmentation of .NET with all the different profiles. The main branch of IKVM only works with the full .NET framework versions, not WinRT/Silverlight/Xamarin etc. There was a fork that supported Xamarin iOS but it was very rough and there hasn't been much interest in it since RoboVM and Multi-OS Engine came onto the scene.

The best analogy I can think of is that .NET has gone chasing after the Node.js development experience. (And, much more speculatively: has at least the potential to keep a lot of the worst from both what it was and what it is trying to become.)

In any case, the current transition has pros and cons, and even these are categorized differently by each dev.

In addition, there are new alternatives that could cater to a particular dev's exact style.

As someone who is paid to do .Net development, I'm continually disappointed by the .Net ecosystem. .Net core SHOULD be awesome, but I'm not seeing much movement in it the areas I particularly care about (like the SDK for our ECM, database drivers for the IBM i) as well as the larger open source ecosystem.

Honestly, I'm much happier writing stuff in Java or Python than I am .Net - both have substantially healthier ecosystems and I feel like I'm getting work done BECAUSE of my tools rather than in spite of them. I have to suck it up at work most of the time because we are a ".Net shop", but any personal projects I work on will likely never be done in C# unless it's a Windows desktop app.

Oh my God I feel exactly the same. At home I don't touch C# if I can avoid it

> as well as the larger open source ecosystem.

There must be a reason for this though, one of the reasons why Java has a good ecosystem is because it's had a huge head start in terms of time and mindshare.

At the same time though, what's stopping people from making the open source ecosystem in .NET really good? There must be a reason, is it cultural?

Could it just be time? Since VS Community was released, there's no huge blocker for someone to develop for .NET (other than Windows itself).

95% of companies cannot use VS Community Edition because their revenue is too high.

There must be a reason for this though, one of the reasons why Java has a good ecosystem is because it's had a huge head start in terms of time and mindshare.

This doesn't seem to be a complete explanation. I was doing Java heavily in the early 2000s, and open source Java was pretty new still. Apache Struts[1] was possibly the first big OS Java project, and it was only released in 2000. The first version of .NET was released in 2002, and something like Rails was only released in 2004.

"Head start" doesn't seem to explain this.

[1] https://en.wikipedia.org/wiki/Apache_Struts_1

Until very recently, .NET has only really been usable on Windows. Nobody uses Windows for 'web scale' (ugh) stuff; it's expensive and historically was difficult to automate. So there's less incentive to make really high quality libraries for it; Guava would never happen, say, because companies like Google don't use Windows.

.NET is primarily used by two cultures that don't place a big emphasis on open source development: Windows and giant in-house enterprise IT projects, often at banks. Banks have historically struggled with open source: it took a long time for them to start using it, and much longer still to start contributing.

Java's focus on cross-platform support from the start probably seemed like a waste of resources back in the 1990s when Windows was so dominant, but it had the advantage of making it more popular amongst UNIX users and the existing open source culture. Java going open source long before .NET also contributed to this. The end result is that you get organisations like Red Hat, Apache, IBM that create vast quantities of high quality open source Java code, and a culture that is steeped in open source development. Whereas in .NET it's rare to use components not built by Microsoft and when they do exist they are typically proprietary, same as in the 1990s.

Just look at VS 2017. A rushed IDE that has all sorts of weird quirks and bugs, non-backwards compatible with VS15 extensions, and now you have to actually create a MS 'insider' account and go through some broken web pages to get the VS15 download. Microsoft is abandoning their software just as fast as JS does now. For something that is built for actual desktops and servers that will run for years and most likely does not have a maintenance team, I think thats dangerous.

Now we take in .net core, which has changing standards and incompatible build files between various versions it has released. To even get .net core V2 you've gotta go to their github releases and grab a beta build. By having VS15 and VS17 with .netcore 2, my toolchain broke and couldn't even compile any modern .net core projects, requiring full wipe of VS. Combine that with working on projects that could be written for .net framework, .net standard, or mono, and you've got one big ball of mud that nobody wants to touch. Maybe in 5 years if things standardize and multi-platformability becomes a real goal of MS, but right now, its easier and more stable to make multi-platform applications with electron than C#. Or just C++ and QT, or really any other language that doesn't have 4 different runtime versions.

I've been a .NET developer for years but I've also been a big Java guy. The lack of an OSS ecosystem in .NET is a huge glaring problem. This is compounded by the echo chamber that is the MS developer world.

There have been multiple projects where lack of a library or database driver have resulted in hacks or passing something to a little Java app and back because it's unrealistic to do the work in C#. Like I said, the MS world seems to be an echo chamber and the vast majority of C# devs shun any solution outside official MS channels. Why do they do this?

Because open source devs generally still dislike MS and until .NET core (which is not ready for prime time) using C# saddled you to Visual Studio, Windows, SQL Server, and IIS. Because of this, the open source community on other languages like Python or Java is maybe 20x bigger.

The other reason open source avoids the MS platform is because they like to take your stuff and replace it with the "MS official" version. Entity framework was originally a poor emulation of NHibernate. WebApi a copy of Spring Boot. Instead of helping your project, or making it official like Java tends to do, MS likes to replace your OSS with something proprietary.

The other big .NET problem is speed. I like C# syntax better, but when I wanna get something done on my own I reach for Java first. It's faster and more flexible. In some areas the execution speed difference is 100x. The CLR might be quick but MS never considered performance a priority until .NET core, because before core they were only competing with themselves.

The echo chamberyness is leaving the MS stack in the dust. Everyone else runs on Linux now. Everyone else is using containers and SPA frameworks and Postgres. In the MS world, the unofficial rule is that if it's not a visual studio project template don't use it. It encourages reaching out of the Microsoft ecosystem as little as possible.

Big sites like stackoverflow that have chosen to go with C# have blogged about their adventures. Most of these adventures involve building things that are already available from the community in most languages. Core may save .NET but it might be too little too late. Windows has already lost the war for server operating system and that leaves little reason to use C# over the primary competitors Java and Go. Both of those have ecosystems far larger and far better support for things like databases, mapreduce, Linux, containers, etc...

I'm curious, in what areas is Java 100x faster than C#?

Aggressive inlining and devirtualization is one thing. Escape analysis that allows objects that one would expect by all rational and technological reason to be required to be allocated on the heap being allowed to be allocated on the stack.

It's not just a handful of optimisations. The entire JVM is performance focused in a way the CLR just isn't. Microsoft historically put their resources into the C# language and the IDE. Sun/Oracle put their efforts into the runtime.

For instance, the CLR doesn't do any profile guided or speculative optimisations at all. That's a 20% win for most Java apps and even more still for languages with higher levels of abstraction like Scala. So right there from the start .NET is 20% behind. The CLR doesn't have an interpreter, so, it spends a lot of time JIT compiling code that isn't particularly important. That takes CPU time away from your app, not sure how much of an effect that is but I can imagine it's at least another 10% down. C# asks devs to control de-virtualisation by hand to try and compensate, but the JVM can do a better job automatically. CLR is only now starting to look at tiered compilation and even then only a very basic form compared to Java which has had it since Java 8.

But not only is the base infrastructure and approach far more advanced, the JVM's JIT compilers are way ahead of even the new RyuJIT. Not just fancy optimisations like devirt and escape analysis/scalar replacement, but even basic things like profile-guided basic block ordering. JVM can do auto-vectorisation of loops, lock optimisations, it can even replace speculatively profile and replace synchronised blocks with hardware (TSX) transactional memory. The CLR is multiple generations behind where HotSpot is. And the JVM team is extending its lead even further with projects like Graal.

Not a ton of places, but in my case forwarding HTTP requests. Netty is close to 100x faster than regular .NET. Another example is JSON serialization. Jackson/GSON are maybe 30x faster than the built-in JSON handling in C#. Everyone smart uses Newtonsoft now, but it was a huge bottleneck until a few years ago.

.NET seems to have a lot of rough edges where MS said "fuck it, nobody will complain if this is slow". If you happen to use one of those features that didn't get enough love you get burned. Java is generally polished throughout, most likely due to the sheer volume of software written for the JVM

It is faster practically everywhere from 2x and on...

I seem to be in the minority here in being largely happy with the .NET OSS ecosystem. Look at github or nuget - it's rare I can't find a library to fulfil my needs.

The only issue I really do have is down to fragmentation - library authors have too many targets to supports support. Libraries may support .NET Standard, but not the .NET framework before 4.6, for example.

You are definitely in the majority among .NET engineers. Like everything it seems like people get pigeonholed into certain families of tech after being in the field for a while. Microsoft is one of those families, and so is Java.

.NET community ain't terrible, but it's nothing compared to Python and Java. I have tried to convince my co-workers of this fruitlessly over the years but basically all of them are .NET for life. There's no point in arguing that another product is better if the person you're arguing with has never seen it.

I used to share the same opinion as you until a few years ago when I got bored of making the same old .NET CRUD "line of business" apps at work. I decided to do some cool open source stuff that I always enjoyed reading about.

At first I wanted to use .NET but I quickly abandoned it after playing with Linux on AWS and learning about Cassandra, React, rabbitmq, elastic search, and Postgres. I had never even touched all of these great things. At an MS shop it's "SQL Server, SQL Server, SQL Server" for anything with even the slightest resemblance to data storage. Web development is "Angular" or "MVC" with little variation.

I started writing some cool open source stuff and realized I would be alienating myself from most of my users if I made it in C#. So, I picked up Java and never went back, at least at home.

I'm the only developer at our company out of ~35 that prefers Java over C# and the only one that contributes to free software. I don't think that correlation is a coincidence.

It's true that I don't use Python or Java (although I have used it in the past - wasn't a big fan, and now C# seems so mch more powerful) and do use Typescript and (unfortunately!) Javascript. Python is something I do want to get into though, just to find out for myself.

There are some great .NET libraries for working with RabbitMQ, such as EasyNetQ, Chinchilla and more recently I'm loving RawRabbit. There are also good libraries for working with ElasticSearch, and I use Marten a lot for using Postgres as a document store (great library).

The place I work is indeed an MS shop, but we're all open minded and use other stuff occasionally at work, and quite often outside of work. Maybe we're in the minority there too though; I know plenty .NET devs who do have tunnel vision, but I suppose you get that across al languages.

My main grief again .net now is rather that it has lost its simplicity. There are multiple frameworks to do the same things. For desktop you have winform, wpf, windows 8 apps, universal windows apps, xamarin, etc. For interoperability you have pcl, .net core, .net standard, mono/xamarin, etc. For web development you have webforms, mvc, mvc core. When they introduce a new language feature like tuples, you need to load some external libraries to be able to use it, it doesn't work straight out of the box. And I fear that as they will try to integrate all of this while keeping backward compatibility it will create yet even more fragmentation.

Simplicity is I think why python is so popular and why it is even used in all sort of odd places (like doing computationally intensive maths).

Python is popular in science because

a) it had f2py at a really important (early) point

b) matlab is insanely expensive.

I had always wondered how he funded his work on IKVM.NET anyway. He worked on it so tirelessly, it felt like he was a full-time employee of it.

Told you so. Give a couple more years to .NET Core et al guys in reign, and they will totally destroy .NET. J Duffy I'm looking at you.

Haven't followed the .net stack for a long time, and core seemed like a pretty good idea to me ( aka multiplatform was the roadblock for .net). care to explain a bit what's wrong with current direction ?

What in particular is worrying you about NET Core?

I guess that the platform and tooling is pretty much in motion yet. I think this is totally OK, it is in its early stage of life, and agile projects are like this in that stage. This is a cost for us, as we use them, yet we accept this, as the benefits will be larger for us, especially in the long run.

We can see how the development works, and maybe people with more enterprisey (it here a word for this?) background find this problematic, as they are more accustomed to the slow pace of innovation/changes in that area.

For me, with pretty much FLOSS experience (mostly as user) this is nothing new or worrying. This is how business is done in the open, where you see experimentation. This is the way if you want to listen to your users: show them what you do, and listen to them. Do this often, not once every 3-5 years, as in the enterprise.

IKVM was always the king of the edge cases.

I will follow anything Jeroen publishes in the future with interest!

This is sad. IKVM should have been supported by MS a lot. Being able to use Java libraries would be a huge help for .NET.

As a .NET developer, I only use wrappers for unmanaged code as a last resort. Having to introduce a dependency on something as slow and security-bug-rich as Java would be a hard sell in most .NET shops.

That's not what IKVM does. It transpiles JVM bytecode to .NET CIL so you only need one virtual machine.

It depends on what you are doing but there are a ton of libraries in Java that have no equivalent in .NET. For a lot of projects it would be very useful to use Java libraries.

Out of curiosity would you mind providing a few examples?

Since Java is the most similar language and what I'm familiar with, here's some things where no C# equivalent exists:

Lucene, Guava, Apache Commons, Redis driver, Postgres driver, Cassandra driver, Kafka driver, gRPC, Http2 support(on all platforms, not just windows 10)

Notice I said "equivalent". C# ports exist for some of these but they're unofficial, unmaintained, or both. The most heinous thing I've seen MS do recently is only support Http2 on newer versions of Windows. Http2 is a high level protocol and there's absolutely no reason for this. In Java you can use Http2 on any platform using Jetty, Netty, or soon built into Java 9.

I think you're being a bit unfair.

I am not properly familiar with Guava, but aren't most things available in .NET's collections classes?

A lot of what's in Commons is available in the .NET BCL.

https://redis.io/clients#c looks fine to me (I'd probably pick the StackExchange client)

NPgSQL seems to be the recommended library for Postgres.

https://www.nuget.org/packages/CassandraCSharpDriver/ was updated in February.

https://github.com/Microsoft/CSharpClient-for-Kafka starts to show some of the issues you're talking about - Microsoft aren't supporting this one anymore, but they point to https://github.com/confluentinc/confluent-kafka-dotnet which wraps librdkafka - seems sensible

I'll definitely give you a point for the HTTP2/IIS issue - although there might be more technical reasons than you think for that. From what I recall, a lot of NET and Windows HTTP stuff is implemented in http.sys or WinHTTP which is a low level component. They're not going to ship a large update to anything before Win10, so that's probably why it's missing. In this case I'd just run nginx in front of IIS if you needed to, but I'd hope that most people running IIS in production can afford to update to Windows Server 2012 or 2016.

Guava/Commons contains a lot more than collections. The standard class library in .NET has maybe a third of what's in Guava. Keep in mind that Java's built in library is probably just as big as C#. I won't bore everyone going over the list but check out the summary https://github.com/google/guava/wiki

Things I've used recently include Guavas automatic argument tester, in memory caches/queues, high speed hashing algorithms, and Bloom filter. None of that stuff has real equivalents in C#.

That redis client looks solid, so I may got a bit carried trying to prove a point. The Postgres driver looks good too, but is not officially maintain by the PG team so it could evaporate some day. The Java equivalent IS an official Postgres driver. I see this with C# frequently, it's treated as second class by a lot of OSS projects.

You didn't make a counterpoint to Lucene, I assume because there was really no equal out there for C#.

These days tying your language to Windows, visual studio, and IIS is unforgivable. MS is trying to undo this with .NET core but for the time being I find it rediculous to need to pay for all these licenses. If my employer wasn't paying for my enterprise edition of VS and copies of IIS, Windows Server, and SQL Server I wouldn't be touching C# at all.

At home I use OpenJDK with eclipse and Dropwizard running on Linux with Postgres. The quality of the tech is the same and everything is free and open source.

That's the thing. With .NET and windows you are second class citizen for a lot of open source stuff. A lot of the latest and best stuff is done on Linux and often on Java.

I did a project around full text search and the amount of libraries in Java was just staggering whereas with .NET you often only had some half baked port that was way out of date. I don't think too many researchers do their stuff in .NET. It's Java or something like Python.

I’m sorry, could you expand on that?

I’m not sure if I’m understanding you correctly, that you’re saying Java is slower than .NET, and the JVM more vulnerable than the CLR?

Lat time I played with Java was in 2015. It seemed like there was a new JVM zero-day every month, and every time I upgraded, the Java installer tried to install the Ask toolbar.

After that, I started joking that installing malware one way or the other was Oracle's primary goal.

Considering that Java runs on many more servers than .NET it can't be that bad.

Compared to most of today's more recent frameworks, that doesn't mean it's actually great. And while I appreciate the direction of .Net (Core), I am hoping the integrated tooling story gets a bit better (outside VS for windows). Code is okay, but not great, and other editors are mostly non-starters. Installing VS for Mac was a horrible experience that had to be done via manual steps for all the dependencies, etc.

My understanding is Java tooling has gotten better, but being able to setup a hello world application in Java, or any established application without a ton of weird dependencies to discover always seemed painful, and "Enterprise" .Net applications didn't feel much better.

Today, my world tends to mostly center around Node.js and git... I've dipped my feet into some new .Net bits, and a little bit of go, and that's about it. I find the learning curve steep, but the actual implementation WTFs are nearly non existent. With Java/.Net it's always been a relatively steep learning curve (worse with Java) and a lot of WTFs along the way.

Eh, lol?

Setting up new applications in Java or .NET is by far easier than Node.JS.

It's Node.JS where you need 400 dependencies just to use the latest version of the language.

That said, there's many easy to use and simple frameworks for Java, and you can try also other JVM languages such as Kotlin, Clojure, Scala or Eta.

The JVM hosts the most powerful and fastest managed languages at the moment (via eta and clojure also allowing haskell and lisp on the JVM).

.NET is nice, but there's quite a few reasons why Java is used everywhere.

Setting up new applications in Java or .NET is by far easier than Node.JS

I'm far from a node fan, but that is simply not true. When it comes to going from zero to a "Hello World" webapp (super simple rest api that grabs data from db and returns as JSON) nothing really beats node in my opinion.

Install npm, npm install express (or restify), npm install database-driver (and there are drivers for everything), type a dozen lines of code into a single file and you're done. Sure npm is probably doing some crazy things with dependencies in the background, but you don't have to worry about it to just get started. Doing the same with Java or C# is much more involved.

Of course going from there to a large complete application is far from equally trivial and I definitely prefer working in something else in most cases, but node has the whole getting started experience down pat and that's probably the reason it's become so popular.

Much more involved? With Java and co it’s literally the same.

You add two dependencies to your gradle, write a dozen lines of code, and you’re done.

Even if you go full enterprise it’s not much more. Let’s go full Java Enterprise:

    // Enterprisify everything!
    compile group: 'org.springframework.boot', name: 'spring-boot-starter-data-jpa', version: '1.5.0.RELEASE'
    compile group: 'org.springframework.data', name: 'spring-data-jpa', version: '1.11.0.RELEASE'
    compile group: 'org.springframework.data', name: 'spring-data-commons', version: '1.13.0.RELEASE'

    // persistence framework
    compile group: 'org.hibernate.javax.persistence', name: 'hibernate-jpa-2.1-api', version: '1.0.0.Final'

    // database driver
    compile group: 'org.postgresql', name: 'postgresql', version: '9.4.1212'

    // to auto-generate getters, setters etc.
    compileOnly "org.projectlombok:lombok:1.16.16"

Now we’ve imported spring, our database driver and an ORM. Let’s write the code.

First, let’s config:

    // application config
    spring.application.name=ourapp
    server.port=8090

    // database config
    spring.datasource.url=<our database url>
    spring.datasource.username=<username>
    spring.datasource.password=<password>
    spring.datasource.driver-class-name=org.postgresql.Driver

Then add the database layer, defining our model:

    @Entity @Table // To auto-generate mapping for the ORM
    @Getter @Setter // To auto-generate getters and setters
    public class Book {
      @Id
      private long id;

      @Column
      private String name;

      @Column
      private String description;
    }

And our access layer:

    public interface BookRepository extends CrudRepository<Book, Long> {
      Optional<Book> findById(long id);
    }

And our application:

    @RestController
    @SpringBootApplication
    @EnableJpaRepositories
    public class OurApplication {

      @Autowired private BookRepository books;

      @RequestMapping(path = "/{id}")
      public Optional<Book> getBookById(@PathVariable long id) {
        return books.findById(id);
      }

      public static void main(String[] args) {
        SpringApplication.run(OurApplication.class, args);
      }
    }

So. This is if you go full insanely Java Enterprise, want full Spring, and everything. If you choose sanely, it’s obviously far less code.

Notice how I don’t have to use any transpilers, etc, and still get typing and the latest language features.

You can downvote this, sure, it’s now so far down that most users can’t see it anymore.

But that doesn’t change the facts. Good luck getting modern JavaScript or TypeScript, without using any templates, in equal or less LOC, and easier to understand for a newbie, than my Java Spring Enterprise example below.

JavaScript is easy if you want to do tiny things, but as soon as it gets to larger projects, it has the same issues as PHP and other similar languages. Every language has some things it can do better, and some it does worse. Until JavaScript development slows down, and the compilation pipelines standardize, and there’s simpler ways to handle that, setting up a node.JS project will always be more work than a language where that has already happened.

I've done some relatively large projects in Node... though I tend to break things down into discrete components either based on deployable assets, or reusable assets.

Node pipelines are pretty nice, not quite as nice as go's channels, but nice none the less. There are different options depending on libraries. I don't find it to be significantly more cumbersome than C#/.Net (which I have more experience than with Java). Also, your "example" has a LOT of assumed knowledge, more than a relatively simple express app, that's for certain.

It really depends on the approach.

Well, I don’t think so.

I had never worked with Spring or Java Enterprise, and could write the example after 1 hour of reading docs.

After years of working with vanilla JS, and weeks of reading docs, I still can’t get a typescript compilation and CSS/SCSS compilation and minification pipeline right. Seriously, I still can’t get it working.

I've had better luck with flow over typescript, though frankly, I don't use either... I used flow instead of typescript for an angular 2 project a while ago. Not sure if the webpack story for typescript has improved.

I've managed to get webpack + babel + sass working pretty readily, in about the same time you mention above.

a JVM browser plugin zero day, totally unrelated to java for server programming

Can you name a few specific examples of where you are using .NET/CLR that Java would have introduced security holes? Basically all the high profile ones that people think of are code-loading issues, similar to XBAP and other .NET tech's bugs. In other words, the "Java insecure" meme applies to very little actual Java dev.

You have to install a whole extra runtime on all of your servers, including production internet-facing servers to use Java. If you can't see that would add to your potential attack surface, I can't help you.

you also need to install the .net runtime on all of your servers.

Please list a few remote access vulnerabilities caused by the JVM and not app.

I don't know about security but the fact that the java installer tries to install crapware or change my browser settings doesn't do much for its reputation.

Hey I have a real world example, it's not a problem with the JVM but with the way JVM interop would work for a .NET shop.

A company I was working at was using a java library to do one specific thing related to file uploads, despite all their code being .NET. The library became a bit of a black box and no one bothered to keep up with updating it as it was essentially a binary blob that sit outside the normal update mechanisms (visual studio references)

Turns out the library had patched a RCE vulnerability a while back, spent a fun afternoon making a PoC exploit for it (tricky because we had some other file validation in place) to win the unofficial office competition to find a security hole in our product.

I would agree with your point in general, but the moral of the story is that adding complexity is not good considering most people are too lazy/incompetent to understand the full implication of something like "I'll just use a third party binary / library here" to their ongoing maintenance.

I don't think Java is really much slower than .NET code.

What makes you think it is even slower? Care to show real numbers?

I don't.

It's faster. The JVM is almost always faster than the CLR, look at the techempower framework shootouts. .NET core is fast but regular .NET get destroyed by multiple Java frameworks.

The techempower Benchmarks are related to ASP.NET core, that one you can use on Desktop too.

The coreclr is only maybe 10-15% faster than Desktop, but not a magnitude or more compared to old ASP.net.

I don't think that the clr is slower than the jvm, but quite a few basic frameworks are compared to their Java counterparts

Look at the older techempower benchmarks where they include the regular .NET framework. It's slow as hell compared to java.

And yes that's the problem. The CLR itself probably isn't slower than JVM but most of the .NET stack is. It just wasn't written with performance in mind.

> The CLR itself probably isn't slower than JVM but most of the .NET stack is. It just wasn't written with performance in mind.

I don't really think that's true.

Java code is, of course, managed. In any case, this isn't a wrapper for Java code running in a JVM; it's an implementation of Java for the CLR.

Not sure what makes you think Oracle's JVM is slower than the CLR, in any case...

Yeah, because as a .NET developer, you would not of course know all about Java :)

Right, tell me the ecosystem of .NET vs Java and deployment statistics...

Back in the day MS created a propriety native code interface for their "Java for windows" runtime instead of supporting JNI. Sun sued them for this and other BS and eventually MS settled out of court for somewhere over $2,000,000,000 . Basically, MS got caught red handed trying to break cross platform compatibility of java applications.

After this they tossed their Java runtime, added ActiveX to IE and started pretending that Java didn't exist. I'm not surprised at all that MS doesn't go near this project

That's their usual EEE tactics. After hey got caught, they renamed their efforts (C# v1), refactored the code. Don't waste your time with dotNetCore v1 or legacy dotNetFramework, use Java/PHP/Node/Go/Python/Ruby/etc and stay away from their vendor lock-in.

They do this again and again.

* Look at what they do with programming language R, adding incompatible changes and calling it R. Don't use their R fork!

* Look at ES2016 and TypeScript, they lobbied to get Class syntax added to Javascript and now do an EEE with TypeScript and WebAssembly. Don't use TypeScript! Learn how to use Javascript and what prototype-based inheritance actually means - it's a rather great concept. Don't use VSCode! Use Atom, Sublime, IDEA, Eclipse, etc.

* Look at Nodejs, they are lobbying to get their IE11/Edge's Chakra JS engine instead of V8 as default JS for Windows builds.

* Look at Python, they have their hands reached out to it.

* Look at Nokia, the former number one smartphone manufacturer, they implanted a Trojan horse manager that canceled various successful smartphone product lines to go full in with WinPhone. He single handed managed to destroy Nokia, drive the company value down so they in the end bought it for little. Now even this devision is dead, what a waste.

* Look at Ubuntu, they sponsored the project to get a Linux usermode for Win10. Who ever steered up the community, at least they succeeded that Ubuntu now canceled their projects to have the rather polished Unity desktop and now goes back to the unpolished mess called Gnome. It also means the end of Ubuntu Phone with it's desktop mode - the only left competitor of WinPhone10 continuum desktop mode. They forgot about Samsung, they have now such a fearure in their recent flagship smartphones, and WinPhone10 is now merely supported on 13 devices.

* Look at Silverlight, they tried to clone Flash, they went as far as make the whole WinPhone7 Silverlight-land based on WinCE and lobbied Netflix and others to use their Silverlight video DRM.

Microsoft's settlement was $20M, not $2B[1]. ActiveX was in IE before the settlement, and Microsoft's "Java" was one possible way to write ActiveX controls.

[1] https://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine...

You're looking at the wrong settlement. It was 1.95 billion. https://m.theregister.co.uk/2004/04/03/why_sun_threw/

This is disappointing. I've used IKVM to convert a few Java libraries written by academics where no .NET equivalent existed at the time (NLP and some other math libraries).