The Weakness of the .NET OSS Ecosystem • Hacker News Board

Re: The Weakness of the .NET OSS Ecosystem

#161

Post by verinus » Fri, Jul 24, 2015, 8:36 AM UTC

tacos wrote: post #40

vdnkh wrote: post #17

Yes, the author is correct. There is a distinct lack of OSS in .NET. I've been trying to find a project to contribute to among the graveyard on Github. However, I think the author falls flat explaining the why. I have a few thory on this. For so long C# has been a walled garden of closed source software. This closed source software, for the most part, works damn well. Why reinvent a square wheel when there is a shop…

The tools and libraries from Microsoft are so solid that frankly you don't need an entire class of open source projects. I don't need to "contribute" and "socialize" with some Python craziness named after a dolphin (though I did!) because Amazon provides a real .NET SDK for talking to AWS. I don't need to wrestle with three different constantly-patched Ruby image libraries because .NET has been able to load and save…

funny thing is I don't think that the tools or libs are still far from perfect:

- WPF tooling is severely lacking in regard to databindings. - libs such as collection classes were far from java standards when release- there is even a pretty good OSS alternative: C5 - there is no standard for filepaths in .Net but even there a good OSS alternative exists: NDepend Path

but I see a lot of improvement in the last years: Rx, ReactiveUI, NuGet, FAKE and much more high quality OSS is beeing created.

Re: The Weakness of the .NET OSS Ecosystem

#162

Post by sklogic » Fri, Jul 24, 2015, 8:53 AM UTC

daxfohl wrote: post #25

platz wrote: post #12

My perception is that F# is attracting the open source folks in the .Net community http://tomasp.net/blog/2015/why-fsharp-in-2015/

Ironically, I love F# but still waiting for F# on JVM before beginning any serious work.

JVM is incapable of running anything like F# efficiently.

Re: The Weakness of the .NET OSS Ecosystem

#163

Post by [deleted] » Fri, Jul 24, 2015, 8:54 AM UTC

cbd1984 wrote: post #152

fr0styMatt2 wrote: post #146

Earlier quoted context omitted.

I think the status of the development tools has/had a lot to do with it. As a .NET developer, it's always been unclear until a few years ago as to how you could get the free tools and what you could do with them. I'm specifically talking about Visual Studio here. So there was always this perceived barrier to entry, even if it wasn't true -- for example with C++ I know I can just grab a linux box and have gcc and use…

> They aren't seen as "hacker's languages" but "ewww yuck big bank enterprise-y languages". They're seen as "Languages this evil SOB of a company owns and who knows if it could decide to patent something and enforce it against me". As in, patent law is complex. Guarantees sound more like marketing of the used-car-dealer and sawdust-transmission variety than actual known-good documents like the GPL, which is, after al…

[deleted]

Re: The Weakness of the .NET OSS Ecosystem

#164

Post by ectoplasm » Fri, Jul 24, 2015, 8:57 AM UTC

sklogic wrote: post #162

daxfohl wrote: post #25

Earlier quoted context omitted.

Ironically, I love F# but still waiting for F# on JVM before beginning any serious work.

JVM is incapable of running anything like F# efficiently.

How come?

Re: The Weakness of the .NET OSS Ecosystem

#165

Post by skc » Fri, Jul 24, 2015, 9:01 AM UTC

How about maybe we've reached a point where there are very few things you can't already do/achieve quite well in C#/.Net without having to dip into OSS land?

I'm a C# dev and I keep close tabs on the plethora of tools that become the new cool thing in OSS for other platforms, and maybe it's a case that I don't work on interesting things...but I've never found myself hindered by C#/.Net.

In any case, the major OSS tools out there do have .Net ports that are actively maintained, perhaps only the bleeding edge stuff is slow on the uptake.

Re: The Weakness of the .NET OSS Ecosystem

#166

Post by sklogic » Fri, Jul 24, 2015, 9:27 AM UTC

ectoplasm wrote: post #164

sklogic wrote: post #162

Earlier quoted context omitted.

JVM is incapable of running anything like F# efficiently.

How come?

It's got some severe built-in limitations. Firstly and most importantly, there is no support whatsoever for the proper tail calls (and F# is using the .tail prefix quite a lot).

Secondly, no stack allocation (value types in .NET).

Another thing which may harm optimisation significantly (although not sure if F# is using it - but the other functional languages most definitely would have benefited from this) is a very low hard limit on a method size, which forbids any extensive inlining and specialisation.

Re: The Weakness of the .NET OSS Ecosystem

#167

Post by Olivier26 » Fri, Jul 24, 2015, 9:37 AM UTC

What's missing is a .Net, open, powerful CMS à la Drupal 8. It's hard to understand MS doesn't take this point seriously with its Azure strategy. Orchard CMS is interesting but has little momentum and very few developers.

Re: The Weakness of the .NET OSS Ecosystem

#168

Post by ectoplasm » Fri, Jul 24, 2015, 9:52 AM UTC

sklogic wrote: post #166

ectoplasm wrote: post #164

Earlier quoted context omitted.

How come?

It's got some severe built-in limitations. Firstly and most importantly, there is no support whatsoever for the proper tail calls (and F# is using the .tail prefix quite a lot). Secondly, no stack allocation (value types in .NET). Another thing which may harm optimisation significantly (although not sure if F# is using it - but the other functional languages most definitely would have benefited from this) is a very l…

Thanks for clarifying. I think tail call conversion to iteration for Java bytecode could be added to a JVM implementation without changing the spec, and you could also do it when converting F# to bytecode. Apparently it's on the todo list but not high priority.

Stack allocation is trickier if it's specified in F# code, because it isn't part of the VM spec, but automatic stack allocation for Java has been demonstrated in a research context and I think either HotSpot or J9 can do it too.

The method size limit is something like 2^16 bytecodes, but even if that's a problem, JITs are free to inline beyond that as much as they want.

So, I agree it would take some work but I don't think it's fundamentally impractical. Adding stack allocation to the class file format would be the hardest thing to push through I think.

Re: The Weakness of the .NET OSS Ecosystem

#169

Post by cmdkeen » Fri, Jul 24, 2015, 10:01 AM UTC

jasode wrote: post #70

maxlybbert wrote: post #67

Earlier quoted context omitted.

But Java had a lot of open source projects around it before Sun released the source code.

Whether/when Sun released the source code isn't as relevant as the fact that JDK and JRE 1.0 in 1995 were free . Microsoft .NET 1.0 development in 2002 required paid tools and a free version (Visual Studio Express) didn't happen until 2005. VS Express was also crippled in comparison to the paid product (VS Professional). We can't just look at the technical features and syntax of C# and compare to Java. (E.g. they bot…

The significant word there is student. CS departments started using Java for an awful lot of teaching. I would wager that plenty of those "hard" OSS projects have a genesis in academia, and even if not that Java became a sort of lingua franca for writing code you wanted discussed or accepted in that sort of way.

Re: The Weakness of the .NET OSS Ecosystem

#170

Post by reubenbond » Fri, Jul 24, 2015, 10:03 AM UTC

The half-assed actor project mentioned by the article is probably ActorFx - which is an interesting project with some cool ideas. For exammple, you could write actors in a mix of languages like Python, JS, & C#. It had automatic state replication after each turn. Actors were observable, Rx-style. Actor behavior could be specified at runtime: you could effectively throw a JS closure into the cluster and it create an actor out of it.

I wonder, though why it became stagnant so soon and never gained momentum. I'm don't know, but I have a theory. The team were using some tech which was semi-secret at the time, which they weren't allowed to talk about: Service Fabric (known as Windows Fabric at the time). Fabric was in use in projects like Lync Server and Service Bus Server, but no one could talk openly about it.

How can you develop an open-source distributed system without being able to mention the framework which makes it all possible? Fabric handles ActorFx' high availability, service discovery, code distribution/upgrades, and their state replication. It's pretty difficult... Forum posts asking what this fabric thing was went unanswered and the people who may have been interested in ActorFx just moved on.

Regarding Orleans, there were probably a couple of internal actor frameworks in use at some large .NET houses, but they were never released to the public. I think it was more of a cultural issue than a lack of devs: .NET devs weren't used to sharing code.

Things are getting better. The community around Orleans is great (come join us on Gitter! https://gitter.im/dotnet/orleans) and the ecosystem as a whole feels to be gaining momentum.