Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

From what I remember ALT.NET was pretty much a movement that was against Microsoft anti or ignorant OSS policies of the time.

For instance NuGet was Microsoft's project which completely ignored the fact that OpenWrap (an OSS project) had existed and was gaining momentum. But then NuGet came along and obviously the Microsoft loud speaker basically killed OpenWrap over night. That is just one example - but there are dozens of others.

ALT.NET was also about the social aspect, such as Twitter, meetups and non-Microsoft-owned .NET conferences.

I don't see the need for any kind of similar movement right now. Microsoft is firing on all cylinders and I believe it will only get stronger, wiser and bolder now.

It isn't long now before the .NET CLR will replace the JVM as the open source standard on which enterprise apps are built (and more) - watch this space!



I think ALT.NET was one of the drivers for this change within Microsoft. Without it or something else like it, we may see the old MS patterns creep back slowly. I think it is good to have alternatives to a lot of the prescriptive MS frameworks and "best practices" - and I say this as a career MS, .NET developer.


I'm not so sure. The leadership at Microsoft nowadays is quite different compared with back then. I do think the need for (something like) ALT.NET perhaps isn't there in the way it was back in 2007-09 because the software development, and particularly the web development, landscape has changed so much over the past 10 years.


One of the reasons we're keen to do this - or at least to try it! - is that both the industry and Microsoft have changed enormously in the last ten years. There's a much richer range of platforms available, and there's all sorts of new protocols and patterns we can use to integrate those platforms - and with stuff like containerization and serverless cloud functions, there's all kinds of interesting ways to use .NET and .NET Core as part of a larger heterogenous application stack.

It will also be interesting - in the widest possible sense of the word - to see how the interactions between altnet and 2017-era Microsoft play out as compared to the 2007-era Microsoft. As the saying goes, watch this space :)


> It isn't long now before the .NET CLR will replace the JVM as the open source standard on which enterprise apps are built (and more) - watch this space!

I work with Java and .NET every day and the day our customers UNIX servers will run .NET is still very far away.


>"I work with Java and .NET every day and the day our customers UNIX servers will run .NET is still very far away."

Why's that true for the customers you mentioned?


Because .NET Core even with the .NET Standard 2.0 only covers part of the APIs for CLI and Web applications, and only targets GNU/Linux, OS X and Windows.

Java is a complete platform, not only CLI and Web, has application servers like Websphere that offer a full server OS abstraction across the cluster and run in several flavours of enterprise grade UNIX and mainframes, not only GNU/Linux.

Also every database worth using in the enterprise space has JDBC drivers, whereas good luck getting ADO.NET drivers or mainframe connectors for .NET Core on those platforms.

And many of the .NET libraries don't run out of the box on either Mono or .NET Core, so unless they get ported, they won't be available.

Oh, and as far as I am aware you still don't get performance monitoring tooling like the JetBrain products talking to .NET Core.

Also they have legions of replaceable programmers used to Java, unless the IT department changes their infrastructure and spends money in trainings, it won't happen, even if .NET Core already had feature parity with Java.


Do you know what "watch this space" means? ;) Enterprise apps are moving to the cloud; you need to think about the future not the past. Legacy JDBC drivers to connect to legacy RDBMS? Please! :)


Curious to hear about these .Net Enterprise devs that are not using RDBMS. It is still very much the status quo even with services like Azure DocumentDB around.

When you get a list of solid points about why Java won't be displaced and the response is watch this space, it reminds me of the folks saying "this is the year of the Linux desktop" without pointing to actual improvements coming to life.

The "new" .Net CLR really only has a compelling story if you are already a .Net shop. Nothing in the new Core and Standard implementations gives you something new if you are outside of it.


There are non-legacy non-mainframey modern RDBMS you know!

Hopefully I don't need to point out the very well publicised and ongoing efforts to revamp the .NET CLR and peripheral items to run on non-Windows systems.


I see. You are just commenting on the mainframe portion of the prior response.

The efforts to revamp .Net CLR to run on non-Windows systems is of little value to shops that are not already running .Net CLR. At best it is removing a negative for running .Net CLR. There is no net gain for a Rails or JVM shop for example.

The gain is only for shops that already paying the Windows tax to get .Net.


Oracle and SQL Server ADO.NET drivers still don't work on .NET Core.



I don't see ODP.NET on that list.

As for SQL Server, it is better than last time I checked. Do you have data about production loads on GNU/Linux?


I don't think, I anwser RFP about what customers are willing to use and pay for.

Regarding .NET, that is only for 100% Windows stacks, even if they run across VMs on Amazon or Azure instalations.

I am yet to see a single RFP asking for .NET deployments on GNU/Linux.


Again, watch this space...


I love being able to use .NET Core on my GNU/Linux netbook, and I prefer .NET projects to Java ones, I just don't believe Fortune 500 customer will suddenly change to it.

They don't have any reason to switch to GNU/Linux VM instances instead of Windows ones, the infrastructure costs are a tiny portion of the overall project costs.


The only thing that could cause such a "ditch and switch" would be Oracle screwing up - which let's face it is quite possible with the way things are going for them. But in any case, I never alluded to that. I simply said enterprise apps that might traditionally have been "built" with JVM will in the future be built on .NET CLR. I stand by it. The JVM is ancient and it seems they are scared to improve it because nobody at Oracle dares touch it these days. Just look at their attempt at lambdas (aka. delegates in .NET as I'm sure you know). And it still doesn't have value types. Anyway, this is highly tangential now.


2017: the year of the Linux desktop!


Java has an enormous foothold in the enterprise with lots and lots of code running and often dating back years, if not a decade or more. That's not going to be replaced easily. The other thing is that Java users seem to be very averse to upgrading. We got a lot of backlash for releasing our newest library version for Java 8 only (so our API could offer a few niceties from that version and be less awkward to use), even though it's the only currently supported Java version by Oracle. We still have customers that use Java 1.4 ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: