112 comments

[ 3.4 ms ] story [ 202 ms ] thread
>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.

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.

(comment deleted)
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.

(comment deleted)
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.
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.

Your hate of Microsoft clouds your mind. It is a higher moral ideal to oppose proprietary software in general than to oppose one target in particular no matter their actions. Microsoft is not a homogeneous entity. There are plenty of reasons to despise Oracle/Apple/Google too.

I initially intended to write a counter to each of your points but there is no sense arguing this. A comment in a thread will not change your mind from a Microsoft hating one to a corporate proprietary opposing one. BTW, care to give an opinion on systemD?

He makes some good points, others seem like more of a conspiracy mindset. I agree with him that EEE tactics at MS are probably alive and well. We're seeing a friendlier facade because MS is losing it's dominant market position. However technology isn't inherently good or evil so I'll gladly enjoy things like Typescript until the day MS tries to make them proprietary again.

I think MS gave up selling software and wants to sell services like Amazon or Google.

Precisely. Microsoft is known to have various factions fighting for supremacy. Some factions are more willing to play fair in the open source world than others. The Windows faction and Office faction have long been known to engage in EEE tactics and still do when they can. On the other hand the .net team is much more open to releasing things as FLOSS.

As long as something is FLOSS, EEE tactics do not work and can not work, because as long as a project is FLOSS, the mindshare of the project does not belong to the author of the project.

The author should not be trusted to have good intentions even if the project is FLOSS. There have been various cases of FLOSS projects that were turned proprietary by the author having a CLA and nobody forking and maintaining the last version released as FLOSS. Should Microsoft or anybody else try to proprietar-ize a project, we as a community should absolutely fork the last FLOSS version and support that version instead. Trusting any author (not just Microsoft) not to do that is foolish. Google did it with components of Android and the community didn't do much. Oracle did it with ZFS and now everyone ignores the Oracle version of ZFS and only OpenZFS matters.

I do not see any reason to hate TypeScript, VSCode, or the recent .net work that was released as FLOSS. On the other hand I see no reason to oppose Flash and Silverlight differently. Neither is FLOSS and both have a lot of issues. Unless you have an interest in Flash, hating Silverlight when Flash is the alternative, is either hypocritical or simply doesn't make sense.

Note that while we benefit from Microsoft releasing FLOSS, the general trend of Microsoft/Oracle/Amazon/Google/others to move to selling services is more damaging to freedom in the long term than just proprietary software.

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.
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).
OTOH, without IKVM, there will be a lot of people who will be forced to come out of the .NET ecosystem when using these libraries, which will end up improving both the libraries and the surrounding ecosystem (e.g. many people dislike Java the language, but maybe people will migrate towards Kotlin for maintaining/improving these libraries). Also, any improvements they make can be more easily integrated back into the source.
IKVM exists because library offerings kinda suck in C#, not the other way around. I find it more likely that people will just write these applications in Java.

MS has a long, dark history with open source including attempting to kill both Linux and Java. Many of us have forgiven but will never forget.

They are doing something very bad with Win10 - the private data is at risk. I know about their history, and they haven't changed. They still have a monopoly on desktop/notebook. They just lost the mobile sector to Apple and Google - the end consumer decided.
Huh, I had assumed this was dead for quite some time based on the lack of updates. Here's hoping someone will take this as an opportunity to revive the project.
The lack of updates may have coincided with lack of updates to Java.
He blames ".Net" but the truth is it's the JVM that's a dead end.

Plus who wants to work with MdI.

IKVM was always the king of the edge cases.

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

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.
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
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.
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.

For me, the one thing that .NET has going for it is Visual Studio. Every time I've tried returning to Java, it is not the language but the dev environment that has me running away in horror.
JetBrains IDEA, Eclipse and NetBeans are all pretty good and comparable IDEs. Visual Studio has no unique selling point per se, if you are into C# its a very good choice eecially with the Resharper plugin (some of its features got cloned).
Eclipse is a lot better than it used to be but still has hallmarks of open source applications (confusing UI, giant feature pile). IntelliJ is great but it costs money for the full version. It's closer to a Visual Studio style experience.
really?

Cause VS is good with resharper but without it?

I haven't used it much for java but Intellij is excellent, hell even eclipse was pretty good.

I'd say in many ways dev tools seem better for java, the thing .net has going for it is that C# is a much nicer language.

It's a marvelous piece of technology. You would think when importing a Java dependency with moderately complex dependencies, there'd be some catch; there isn't. You would expect that JNI does not work (how should it?); but it does. You'd expect reflection support to be broken; but it works.

If the folks at Microsoft had any sense, they would have hired this guy, but they're probably busy rewriting Office in TypeScript based on Electron.