F# is a real breath of fresh air in comparison to something like Scala. It's direct ML heritage really shows, also just diving in with an IDE (like Xamarin, or I suppose Visual Studio) is super easy.
I see it as the future of pop-functional programming. For example look at the way it handles type inference w/ JSON parsing. Compare that to what you have to do to parse JSON in Scala. It's subtle, but a major usability win.
Scala is getting really interesting lately though with projects like Spark and SparkSQL. Spark takes a Scala AST tree and computes a plan on it in order to distribute it to a cluster of possibly thousands of nodes and then uses transformations on that plan, similar to how an SQL query optimizer works, to make the plan more efficient. The cluster compute benchmarks on it are crazy good.
The only problem I have with Scala is that it has so many features that it tends to have a steeper learning curve than most languages. However, this is mitigated somewhat in that it lets one switch between object and functional depending on what's more convenient or performant, thus making it easier for programmers who are not highly skilled in functional programming to pick up.
I've done a bit of scala spark as well, and my initial thought was prototype in pyspark and then rewrite in scala if necessary. Just this week DataBricks announced they are working on changing some of the data structures behind RDDs to save on unnecessary java object creation hubbub https://databricks.com/blog/2015/04/28/project-tungsten-brin...
That and the SQL compiler thing seems pretty darn awesome. Spark has the nice benefit of being plug and play (w/ a joyful time of compiling and deploying) with legacy HDFS/Hadoop systems. That alone will keep it in toolboxes for a long time to come.
>Spark takes a Scala AST tree and computes a plan on it in order to distribute it to a cluster of possibly thousands of nodes
Unless Spark has changed dramatically in the year since I used it, that's not really how it works. You lazily construct an expression graph of RDD operators but the actual Scala code (the functional payload of e.g. flatMap) doesn't get analyzed. Are you talking specifically about Spark SQL's code generator?
>The cluster compute benchmarks on it are crazy good.
...and also carefully chosen to show off the niche cases where Spark shines. More commonly, you'll encounter crippling garbage collector stalls leading to mysterious and undebuggable job failures.
Spark has a very clean API but the implementation (at least for Spark versions 0.8-1.0) is still prototype quality.
The implication of this work I thought is that it could be further expanded to other languages and DSLs. However, Spark's SQL generator still being very JVM-dependent and this optimizer generating bytecode kind of makes it pretty specific to JVM-supporting languages only. This would probably leave out Haskell and Erlang / Elixir in the short term, which is probably where I'd expect to see a different perspective on the whole data analytics front. We have Datomic, sure, (and I guess Clojure is enough for a lot of folks) but it'd be nice to have something other than "we want to make Hadoop... BUT BETTER" as a lot of the motivations.
> Inspired by Spark, we are building OneNet, a distributed functional programming platform based on F# that allows programmer to build distributed system at >3x productivity. OneNet offer similar programming model and extensibility of Spark, but goes much beyond in distributed functional programming to offer additional capability and performance (e.g., in-memory sharing of instantiated object with concurrent operation, use of both managed code & unmanaged code in functional programming, use of model and/or key value store, multi cluster with EDGE + cloud, private + public cloud compute, use of GPGPU/FPGA in cluster)
I did a toy comparison of ML-derived languages running on Linux the other day (http://thebreakfastpost.com/2015/04/22/four-mls-and-a-python...) and found F# already simple to get along with and fast to run, at this beginner level. It could become a really interesting option.
No, I haven't even downloaded Core. I am more ignorant about OCaml than any of the others. I'd love it if someone else here could weigh in on the pros and cons.
"F* is a new higher order, effectful programming language (like ML) designed with program verification in mind. Its type system is based on a core that resembles System Fω (hence the name), but is extended with dependent types, refined monadic effects, refinement types, and higher kinds. Together, these features allow expressing precise and compact specifications for programs, including functional correctness properties. The F* type-checker aims to prove that programs meet their specifications using an automated theorem prover (usually Z3) behind the scenes to discharge proof obligations. Programs written in F* can be translated to OCaml, F#, or JavaScript for execution. "
Gotta love automatic theorem proving. I read the Shen language book on "logic, proof and computation" which got me into the idea of a theorem prover inside of your normal language.
They do seem like very similar languages. I imagine in most cases your choice would have effectively already been made for you by the context -- e.g. whether you wanted the option of fast native binaries (OCaml) or deep .NET integration (F#).
I'm not sure I buy the ecosystem argument. We've recently seem other languages come from out of nowhere, with no ecosystem, to become major languages (Golang, for example).
I don't think there's really anything stopping OCaml from being more widely adopted, except for lack of attention from trend-setters.
Well, one is sponsored by and used in production by Google, and the other is maintained by the French Institute for Research in Computer Science and Automation.
I don't agree, it's 'direct ML heritage' is quite superficial, as it omits ML's most powerful feature, functor modules.
Scala however has all kinds of super powered functional programming features that F# is missing, implicit parameters for type class constraints, ADTs, higher kinded types, etc.
I know it doesn't say much, but having never coded in ML and having tried F# briefly (I code mostly C#, and it'd be easy to have mixed F#/C#), I think Scala has much clearer syntax, or perhaps it's just more familiar for someone who's coming from imperative languages like C++ or C#.
case class Fruit(name: String, variants: Set[String])
val fruitJson =
Json.parse(
"""{
"name": "apple",
"variants": ["cox", "braeburn"]
}""")
val fruit = fruitJson.as[Fruit]
Doesn't seem to be too painful to me.
I agree that F# is syntactically closer to ML (though Scala is closer to ML with its module system which F# gave up completely).
In this base case, no, it isn't too painful. But once you get to larger and more complicated structures, F#'s type provider system can be a tangible timesaver. Especially if you're doing exploratory programming.
TBH, I think the JSON example might underrate things a bit anyway. Where type providers really start to feel impressive is when you get to tricks like being able to noodle around inside undocumented (or poorly documented) COM interfaces with the help of CodeSense, or getting red squigglies in your editor (and compile time errors) when there's a problem with an SQL query.
F# isn't all roses, of course. I really wish it had typeclasses, and discriminated unions are less powerful than Scala's case classes in some tangible ways. But from a purely pragmatic perspective, my (almost certainly biased) sense is that I can usually Get Things Done™ with less ceremony in F#, and type providers are a shining example of that pragmatism.
Well, then I think JSON is a petty bad example, because pretty much no service provides some schema-like specification of their protocol in JSON.
If there is one thing I learned using type providers it is that maintaining your own "description"–be it as sample data or a schema file–loses most benefits of using type providers in the first case.
On the other hand, want a type provider for X in Scala? Just write it.
Stuff is still moving around because Scala devs want to get the meta APIs right first, but if adapting things from time to time is not an issue, then go ahead.
I never have seen a use-case where this would have been an issue. Sure, it "looks" unfortunate, but there is only so much you can do when running on a completely uncooperative runtime.
If devs need a typed representation of unlimited length, they provide a HList and move on.
Such a representation will replace the length-limited tuples in a future version of Scala.
For those of you who want to save the click: you need to build half the stuff on a windows machine and the copy it over - and you need mono to fetch the dependencies(!).
This is interesting but is there any commitment to support it long term? I remember when Silverlight was supposed to be the savior that brought .NET to Mac and Linux, but that didn't last more than 5 years. Would be nice for MS to say they guarantee support for 10, 15, etc. years.
I'm playing devil's advocate: But Silverlight was too little too late. It arrived right as Flash was effectively dying. I don't blame them for killing it, it was dead on arrival.
I can explain the entire problem with Silverlight using two dates:
- iPhone initial release: 29th of June 2007
- Silverlight initial release: 5th of September 2007
Now, we can argue if iOS killed Flash, but I think between iOS's lack of support and all of the security issues associated with Flash, it was set up to lose popular support (and then HTML5/HTML5 DRM filled in the gap, even if it took years ultimately).
Silverlight was a Flash competitor in a world that decided it didn't need Flash.
Silverlight was a half-assed, brain-dead attempt at trying to compete with Flash. It started out as a cool demo and then blew up into a role that didn't fit it well with insufficient support on the dev side. What it should have been was a competitor for AJAX/jQuery. What it turned into was just another video player browser plug-in.
Indeed, and yet we somehow ended up with a whole bunch of Line-of-Business desktop apps written in Silverlight. I did a brief stint at a windows-shop that made and maintained a variety of such apps.
This is the thing with Microsoft is this is never in doubt. It is Google who ends of life's things and stops support. Microsoft still has supports things in Windows 8.1 that were BUGS in MS-DOS in order to allow programs from that era to run.
Microsoft will support .NetCore for at least 20 years. Without doubt.
I think, you think... any CTO, or CEO/owner of a company won't as easily put so much at stake (and IT is crucial part of every major company of any type). MS has a long history of hating and subverting anything other than Windows, it's almost cartoonish when looking back.
This might be just my experience (over 11 years, over +-10 companies) that noone takes MS servers seriously. Only exceptions are Active directory, Exchange and some special reasons where MS SQL server needs to be used (for whatever reasons). Never seen any bussiness-critical app apart from those mentioned running on anything except Linux or Unix.
They're moving in right direction, but thy need to climb really big hill, which they built themselves.
I have the largest cable provider in the country and when I click "watch TV on my laptop" it launches Silverlight. (It sucks, by the way). But people pretending the thing isn't used and isn't supported are really grasping at straws here.
If you're going to bring a plastic knife to a watergun fight, at least point it in the right direction...
You know who didn't (and does not) support Silverlight? Developers!
We moved on from Silverlight well before Microsoft did. That's the important distinction when you talk about sunsetting technologies. Microsoft's track record here is FAR better than that of Google or Apple.
Netflix now use HTML5 where possible (they need Media Source Extensions and Encrypted Media Extensions) but they do fall-back on Silverlight with unsupported browsers[1] (Firefox and old browsers).
Supported with bug fixes, sure. Supported well enough to do modern application development (with the latest C#, .NET framework features, etc)? No. The last major release (Silverlight 5) was 4 years ago.
This is the CLR and .NET class libs. Unlike Silveright they have been supported for 15 years already, and will be aggresively developed in the future too. Besides, they've just been opensourced, even if this IDE project dies, those will stick around as long as Java will...
One thing that's nice is that it's now open source, so as long as it remains open source, it will likely remain cross platform. Contributers that are on non-windows platforms will likely notice when something breaks on their platform, and get it fixed.
Only core components and now a stripped down IDE are open source (core is actually free software IIRC). I will only be impressed if the entire runtime stack becomes open source. Otherwise it's still a platform for DRM or other forms of lockdown.
If you're not porting a .net application to MAC or Linux, I would avoid this for quite a while still. We don't know where this is going long term.
Windows Forms is only a subset of the framework. I don't think exposing Windows Forms as an open source GUI stack would be worth while. It's old and clunky compared to WPF and XAML.
Even without a open source GUI stack the open source .Net Runtime and Framework provide value to .Net developers like myself who enjoy C# (and the F# lovers too!) to develop on Linux, FreeBSD, and OS X with much less pain than in the past. Not fitting each and every scenario doesn't diminish its significance.
It's a bit different when there's a runtime required to run the apps. An app written in Go/Rust today will run on a machine 10, 20, 100 years from now as it's just an entirely self-contained executable. A .NET app will only run on a machine that has a functioning and supported .NET framework.
> Silverlight was supposed to be the savior that brought .NET to Mac and Linux
Silverlight was supposed to bring .NET to browsers on Mac and Linux. Someone1234's comment is IMHO correct and very astute - Silverlight wasn't all bad, but it solved the wrong problem.
On the other hand, this is all about bringing .Net to web servers on Mac and Linux. particularly Linux boxes and container in clouds. My experience may not be typical, but to me that's the right problem. The MS Azure team probably agrees.
They're still charging and threatening people for Android patents without really telling anybody what patents they hold over Android.
I think they realize they can make money via open source now and they might do this for future product. Threaten people via patents or some kind of trojan horse.
While it's great we have another programming language and platform option but their actions so far in the past and present isn't so great.
They also tried to make a Hadoop clone that failed miserably so now they team up with Hortonworks.
Perhaps that opening sourcing their VM they can have big data projects like Hadoop and such. Oracle have big sway over Java and JVM. Perhaps that's what Microsoft wants. People might forget about Oracle and JVM but I still remembered and it really sucks for Apache.
In general, I'm not taking this bet and I'll wait on it.
Also with my current skill set which is mainly open source, it is fine not dealing with Microsoft. Unless they have a better market share and momentum in some niche market like big data with Hadoop, spark or whatever I wouldn't even think about touching their open source stuff.
They had already announced the various parts of this, and the only link I see in here is a GitHub repo with links to other GitHub repos that we've already seen. Is there anything new in this announcement?
Not really. I'm a big fan of MIT style licenses, but it also means that Microsoft could at anytime start making proprietary updates.
It could mean we could start adopting it and then at some point down the road they could discontinue the open version and start making closed features/updates.
Don't get me wrong, I'm very pleased that this is the direction Microsoft is taking. I am just still very skeptical.
> It could mean we could start adopting it and then at some point down the road they could discontinue the open version and start making closed features/updates.
They could do that if it was GPL, too.
With MIT or GPL or any other FOSS license, if there is a sufficiently interested party, they can, however, maintain their own version starting with any Microsoft FOSS release; Free software doesn't mean that the original owner can't release proprietary derivatives in the future, it means that what has been released Free can always be used -- and maintained -- as Free software by anyone who wants.
Of course, there is a cost to that maintenance role, and you have no guarantee that someone will take it up if the original maintainer drops it or decides to release proprietary software instead. Free software gives you the right to spend your own resources to maintain it, not the entitlement for someone else to maintain it for you indefinitely.
What you're saying is correct, MIT vs GPL is irrelevant if Microsoft owns the whole copyright to the project.
Contributors to .NET need to assign their copyright to the .NET Foundation (http://www.dotnetfoundation.org/faq), which seems impartial but also has a board of 100% Microsoft employees. If .NET were GPL, then only the .NET Foundation would have the power to let others create proprietary extensions, which I guarantee they would give Microsoft.
If you have permission of all the copyright holders to release the code under another license. You can't accept patches and then re-license without explicit permission.
Copyright assignments can preserve freedom if done properly; the FSF's copyright assignment, for example, guarantees that your contributions will always be Free (as in freedom). RMS' rationale in this case was to protect against a scenario in which FSF was overtaken/purchased, so GNU software couldn't be made proprietary.
IANAL, but that would essentially require contributors to sign a waiver correct? That seems like a fairly large barrier compared to just being able to take contributors code and incorporate it into a closed project, no?
All major corporate open source projects have a contributor license agreement (CLA) which contributors must sign. Regardless of whether they intend to close the source in the future or not. See the VLC license change fiasco for why CLAs are very good: http://www.jbkempf.com/blog/post/2012/How-to-properly-relice...
If it's GPL or MIT, then it can be forked, and the original owner can't force anyone to sign a waiver. The waiver idea only works as long as the original owner maintains control of the de facto distribution of a project.
No. Having used the MIT license means that Company X can take .NET, make its own modifications, distribute them in binary form and don't share them back as source code with MS or anybody else. Apparently MS isn't afraid about it.
MS is the copyright holder so they could make proprietary updates whatever FOSS license they used, GPL v3 included.
The MIT License arguably protects against patent litigation (in contrast to BSD).
People who have an issue with the MIT License (on the patent issue) fall into one of two categories:
a) People who've put it in the same category with BSD in their heads at some point, associating with it the same shared caveat about patents, and
b) People who understand the distinction between the two but are unsatisfied with how terse it is (especially in contrast to e.g., Apache 2.0). This isn't helped by the fact that the MIT License doesn't actually use the word "patent", and the closest it gets to saying "irrevocable" is "without restriction"/"without limitation".
In any case, Microsoft also included a custom patent grant at the time they announced the CLR's availability on GitHub and its new, more agreeable license terms. (Unfortunately it doesn't include the word "irrevocable", either.)
Pardon my ignorance, but I've never adventured too much into licensing stuff myself, and always had this kind of silly question roaming in my mind: what would happen if someone - after releasing some code open-source with the most permissive license, say on Github - immediately after changed their mind and changed the license back to a very restrictive one and someone had forked the project in that short range of time? Would their forked repository with the permissive license version be a totally legit code repository ?
I know this is sounds silly, but I wonder if it's a thing or not that when a software company publicly releases some valuable code open-source, then there is always someone thinking: "better fork this as quick as possible! you never know!" :)
They can close-source it again, they can't stop you using the open source version they did release. If you have the licence, you have the licence, and it is perpetual. You can't unscramble the egg.
There are quite a few products around which fit that type of scenario - where an older, free version is still circulating while the company now distributes a close source paid version.
The code that will allow the software to run on Linux and Mac OS has not yet been built. “It will be a few months before you can get your hand on this." -Somasegar
Yes. FreeBSD and OSX support was done 100% by the open-source community w/ support from MSFT whom helped a little bit with domain knowledge (the CLR product managers and developers can be found in the Gitter room)
How? Recent version of Windows come with recent versions of .Net out of the box. How would you 'win' here?
The core clr is supposed to be bundled as far as I understand, so it'll be just another dependency of your application: You don't even NEED to install .Net (on the system/system-wide) anymore.
Recent versions of windows come with whatever version of .net was stable at the time, in order to upgrade you have to download from msdn. This vs. `sudo apt-get install upgrade` etc.
The announcement of the windows package management features should help this though.
New versions often come via windows update (which you _could_ consider easier than manually installing it -> apt).
Plus, this is a thread about the core clr and as I said: That won't be required/necessary in a system wide installation anymore. So you now install RandomApp and .Net is just part of it - just like you can apt-get install random-app.
We're comparing now the package management, not the ease of installation of .Net. There is no installation of .Net anymore (or - see above: It sooner or later lands via windows update).
I'm a Linux guy, but that's [1] just a weird case to make here, both in general and specifically in this context.
1: Easier .Net installation on Linux than on Windows
I don't know about any major project. I was waiting for MS to commit to running CLR on Linux (or any unix like clone) so that I can consider the CLR languages seriously (I am very interested in F# in particular).
Was able to build it and run the HelloWorld.cs example. You need to build coreclr and corefx on windows for the managed components, since only the core cpp source can be built on linux at this time. You also need to install mono and grab nuget and use it to fetch a few packages. But all in all it feels fairly historic.
I'm glad that you were able to make it all work with the instructions[1] we provided. There are two major pieces that we're still working on, which you call out:
- Compiling managed source on OS X and Linux with Roslyn.
- Running DNU (NuGet) on .NET Core to restore packages.
Most everything else functionaly works. Once those are solved (and we are close to it), the experience will be great. In just a few commands, you'll be able to acquire .NET Core, restore packages and run your app, independent of which OS you are on.
For .NET developers, it is indeed historic. Community and corporate developers alike are quite excited and see a lot of new opportunities going forward. You might have noticed that the community is leading the OS X and FreeBSD .NET ports, with support from Microsoft. We added official FreeBSD CI[2] only a week ago, upon the request of the community.
Thanks for chiming in. Really looking forward to further developments. As a 15 year+ Windows development veteran whose been doing python on Ubuntu for 3 years it's great to be playing with .NET again. As far as the HelloWorld instructions go, they worked very well, so kudos on that. I think it's super important for developers to be able to jump in and check it out. I also should have mentioned that I used docker's ubuntu:14.04 image as a launch pad for this exercise, and it worked great as well.
Great. I'm the one (@richlander) who has been spending the most time on docs, including publishing all of the "Book of the Runtime" docs[1]. It's a whole lot easier for others to "follow along at home" if you show them how.
We (and me in particular) are going to continue investing in docs for this reason. Feel free to file an issue if there is anything else you want written/explained. We have operators waiting.
BTW: I highly recommend the "Introduction to the CLR" [2] doc. It has a great fundamental view of the product that I suspect many .NET developers would appreciate and will likely learn something from.
I'm curious, is there enough released yet to build server-side web apps? Would there be an apache mod, or some other web server? Or is there something more akin to a node app? I really enjoy C#, but everything that I did was either a Windows-only desktop app or a web app served through IIS. Thanks for any insight.
There's enough released to build server-side apps. ASP.NET and .NET in general has been decoupled from IIS over the last year via project OWIN. Self-hosting binaries is in big time.
I see a pattern here. People were excited about JVM, then came along CLR. And it is now getting attention as MS is porting it to Linux/OSX. Next cool thing will be BEAM (Erlang's VM) based languages, i.e. Elixir, Lisp Flavored Erlang etc. Reminds me of the hype cycle. So lets get hyped!
Funny thing I cloned their repo yesterday on Mac Os to check the advancement of their project, I could run the hello world and the static Web site but not the MVC one.
In order to stay relevant, Microsoft attempts to supplant Xamarin's stakehold in the Linux/iPhone market, by directly eating their lunch.
This is the same thing Microsoft did to IBM. Microsoft will do it to any "partner" they feel they can cannibalize. The Halloween Documents are not only relevant, but canon with this move.
You can run Unity editor under Wine [1] and you can publish Unity games for Linux [2] but I assume native Unity editor support on Linux would require the use of a cross platform GUI library (Qt, GTK etc) as it probably relies on WinForms [3] which is only supported by mono (and I think OSX) up to .NET 2.0 [4].
Java, with Oracle at the wheel, is not going anywhere. They've added closures in 8, big deal.
C# is centuries ahead of Java 8, and with even more to come faster. And I'm saying that as an old Java dev (for 8 years up until 2008 or so) who have only dabbled in C#.
Yeah, but a lot of the features they're adding or just talking about adding to C# are already in more modern JVM languages like Kotlin / Scala / Ceylon.
Kotlin in particular has quite a lot of the things like people like in C# (no full equivalent to linq though), and some things that are only pencilled in tentatively for the version of C# after next, like full nullability in the type system. And you can convert Java files to Kotlin with a single keypress, and your entire project still compiles, so there's a migration path for Java devs to Kotlin whereas there isn't one from Java to C#, really.
So yes the Java language moves slowly. However Oracle/Sun have barely been trying with the Java language: the bulk of their efforts are going into things like upgrading the standard library, better virtual machines, better support for more types of languages, better performance etc. I think they've pretty much bitten the bullet on letting other companies run with language research and development (like JetBrains)
I have to say, the two best things that happened to language design in the last fifteen years was.
1. Sun sued Microsoft for trying to improve Java. And so Gates went out and hired the guy that designed Turbo Pascal and Delphi to head up C# development. Because of course java and it's libraries are completely unsuitable for desktop development.
2. Oracle bought Sun and suddenly every company that absolutely cannot tolerate being Larry Ellison's b.. started investing in in-house programing languages. All those big companies have spent oodles of money on making sure Larry can't drink their milkshake.
NAnyway as a sometime C#/.net code slopper I welcome Microsoft tossing their hat in ring. Seriously Linux and iOS seriously needs these tools.
IIRC, Sun sued Microsoft for creating & pushing proprietary extension that, when used, limited the created application to Windows platform and MS' JVM.
Think of it as like the Java runtime environment, but not terrible.
You have two main pieces: the Common Language Runtime, which is the virtual machine (like the JVM) that executes the code. Then you have the library it comes with, which is fairly large compared to most languages.
> Think of it as like the Java runtime environment, but not terrible.
What's terrible about the JVM/JRE?
Many people complain about the language Java (conservative language, programmer culture of complexity...), or the web browser plugin for the JVM (security vulnerabilities, bad startup performance...), but I've generally heard good things about the JVM itself.
The JVM type system uses type erasure (which means that any generic type Blah<T> becomes Blah at runtime), so you can't instantiate types based on generics at runtime. In C# it is valid to do "T foo = new T();" and because of reified generics, this works. You can't overload functions based on their generic type ("Foo(List<int> ...) and Foo(List<string> ...)" on the JVM (the <...> bit gets erased!). This was done to preserve binary backward compatibility when generics were introduced in Java.
The CLR supports user-defined value types whereas the JVM doesn't, it relies on a classical uniform data representation. Because value types are stack allocated, in C#, you will have less stress on the GC (because you can define stack-allocated value types), on the other hand, the JVM GC will be doing a lot more work. This is why you see "the JVM is heavily optimized" statements.
Another downside of the JVM is that it has no native support for tail call optimization, this is not that major, but it is a bit silly for functional languages running on the JVM (Clojure). The Scala compiler is intelligent enough to do this by itself, but there's no native support on the VM itself, unlike on the CLR.
Another point is that the CLR was designed as a true language-agnostic virtual machine, so developing new languages on it is easy. It is not hard to do that on the JVM, but more so than on the CLR.
Technically, JVM doesn't have a type system, last I checked. Which is why Java (the language) uses type erasure. CLR does have a type system, but this also makes certain things harder to implement which is why, i think, Scala stopped working on their CLR compiler.
The JVM was also designed as a language agnostic VM, which is why they stabilized their bytecode specification early on. There are certain things you can do in bytecode which cannot be done in Java for instance.
Your criticism on the lack of user-defined value-types is valid, which they are working on for JVM 10. This is agreeably late, but better late than never.
There were experiments done some years ago for automated stack allocation in the JVM, by Azul. They had actual hardware support for it, it was very interesting. Basically they stack allocated everything by default and then moved stuff onto the heap when required.
What they found is that it didn't make a big difference to performance. The problem is that generational GCs make allocating short lived small objects very cheap, basically as cheap as stack allocation. The main difference is that with stack allocation you are (potentially) better exploiting the cpu cache, but whether this makes a noticeable difference depends a lot on complicated things. It's not as clear a win as you would imagine and eventually Azul stopped bothering with it.
I'd still like to see more aggressive stack allocation in the JVM. However, I am not expecting it to be some kind of silver bullet.
Re: generics. It's true that type erasure causes some annoying problems. Oddly though, it has a big advantage too - it allows other JVM languages more flexibility to experiment with different approaches to generics. For example Kotlin uses a different style of generics to regular Java. If the JVM enforced the Java semantics that innovation wouldn't be possible, or at least, not at all easy. And of course one reason the Java world has a larger library ecosystem than .NET is that the .NET designers kept breaking backwards compatibility whereas the Java guys didn't. That's the reason JVM generics works the way it does. So the tradeoffs are rather subtle.
It's not quite true that the CLR was designed to be language agnostic and the JVM wasn't. The JVM was intended to be language agnostic right from day one. However Microsoft had to try and unify the worlds of Visual Basic, Java/C# and C++ which were all popular on Windows at the time, so they emphasised it more from the start. However VB.NET and C# are very similar languages with the bulk of the differences being down to syntax. In particular, VB.NET is not really the same language as classical VB at all (e.g. different handling of threads).
These days the JVM has lots of very different languages running on it with quite acceptable performance. They've done a lot of work on making very dynamic languages fast, through things like invokedynamic and Graal/Truffle. That's because those languages are very popular. They've done less work on functional languages, but I'm sure stuff they would benefit from will come with time.
The real benefit of value types, by the way, is control over memory layout and thus CPU cache usage. Java tends to lose benchmarks against C++ partly because C++ programs naturally lay out data in more cache friendly ways. Value types in the JVM/Java language are likely to make a big difference here, though it's hard to say exactly how much ahead of time.
One of the interesting things I'm waiting to see is if .NET gets good enough to become the "main" platform for compile to VM languages like Clojure. It can already compile to .NET, but it's significantly less used than the JVM version, despite .NET generally being easier to target.
> For XCode, compare it to Visual Studio (IMO, VS is light years ahead)
I agree. VS is the best IDE I've ever used by far.
> For Mac Native, compare to the .NET runtime (IMO .NET is better but it's not as clear cut)
The only thing I wish is that MS made it a bit easier to make .NET transparent for the user. Occasionally you need to install a version of the runtime when you install a new program, it'd be nice if that was all "built-in" and taken care of instead of adding another step to the installation.
Strangely enough, the reason that this install step exists is because the .NET Framework _is_ built-in to Windows. For example, .NET 3.5 was built-in to Windows 7. If your app needed .NET 4, then it needed to formally install it on the system. If we didn't make that an option, then .NET 4 apps would not run on Windows 7, which would be bad.
.NET Core is _not_ built-in to the OS, so apps can carry it within their package, meaning that there is never a need to add another step to the installation. This is a major goal of .NET Core.
Ah thanks for clarifying. I guess I was thinking more along the lines of just always grabbing the most recent .NET through Windows Update automatically.
Makes sense. There is a latency of when .NET Framework versions are released and when they show up on Windows Update. Also, customer do not have to install them even when they do show up. Also, some versions don't show up on Windows Update for various reasons. That's why the install step exists.
It is like the Java runtime, but started afresh with all of Java's learned lessons taken into account (although Java with 7 and 8 in particular is catching up).
Up until now however it has only ran on Windows which was its biggest "downside" Vs. Java which runs on many platforms.
> started afresh with all of Java's learned lessons taken into account
I don't think that's really historically accurate. Java and C# were pretty similar back in 2002. The .NET team was more willing to add complexity and occasionally make breaking changes, like generics in CLR 2.0.
That's not historically accurate either. The .Net team was more willing to break things because in 2002 they had their 1.0 release. By then Java had already lived through 6 years of very aggressive presence in the marketplace, with lots of legacy code already in the wild. The only legacy MS had to worry about was COM, which had its own compatibility wrappers that were not fundamentally intrinsic to the CLR.
So .Net had the advantage of coming years after Java had shown what it could be done (or not, see browser applets) from a technological and commercial point of view, AND quite a few years of development without worrying about backward compatibility.
I'm not saying Sun developers were not slow (they were), but they clearly had a much more "entrenched" position, with all that it entails.
It's not that simple. The CLR has a different feature set to the JVM; or rather, it has a feature superset. If you run Java-like code on the CLR, I would expect it to not be as fast or have as high GC throughput as Hotspot, especially if the Java code has been tuned to Hotspot - there are particular fast paths for certain operations that kick in, where if your code is a little bit too far from the optimized idiom, you end up 3-5x slower. For regular code, I wouldn't expect a big gap between CLR and JVM; a lot of Java code is dominated by pointer chasing because the primary tool of abstraction is a heap-allocated object. C# written in the same way will be bottlenecked in similar ways on cache misses, TLB misses, etc.
There's a larger variety of JVMs designed for a broader range of hardware, the most interesting to me being Azul and their GC tech.
But the CLR gives you some different tactical options. Value types and unsafe code let you do things that are far more expensive or awkward on the JVM. Writing a significant amount of functionality that does no heap allocation is more feasible on the CLR than JVM. Native interop is an order of magnitude easier. The CLR is generally much faster to start up; Java terminal apps don't suit interactive use. The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
True, although the most relevant difference is value types, which Java is getting, too. As to the rest, it's not about the number of features, but the quality of implementation. HotSpot's JIT and GCs are simply years ahead of the CLR, and HotSpot's next-gen JIT, Graal, is another tremendous leap forward.
> The CLR is generally much faster to start up
Compared to HotSpot, yes (but, like you said, there are many JVMs out there), although Java 9's JIT caching will change that.
> The library linking story is much more pleasant too, with a single dynamically linked executable referencing GAC-installed assemblies, rather than stringing together enormously long class paths.
This, too, is no longer the case in Java 9, but the difference in the other direction is much more relevant: the JVM's agent capabilities (both Java and native agents) are one of the things that give the JVM its power. The ability to easily transform code as it's loaded (or after its loaded) packs a lot of oomph.
In general I'd say that the JVM offers fewer abstractions, but more powerful ones and it offers less opportunities for hand-tuned optimizations and more for automatic optimizations. In the end, HotSpot is simply much more advanced internally. The CLR is like a car with more buttons, but HotSpot is the car with the better engine. HotSpot has always opted for constant change that's hidden from the user, while the CLR has been adding more and more user-accessible features.
The work being done on Graal/Truffle is so far ahead of anything anyone else is doing, that it will put HotSpot's JIT beyond the reach of any other technology for years to come. It seems to me that the CLR might even stop competing and C# might switch to AOT compilation, with VB possibly being abandoned. Some of the latest moves by MS seem to hint in that direction (RyuJIT was already done or nearly so).
I assume their purpose is similar, but they are really a framework for building very sophisticated JITs -- much more than HotSpot's current optimizing JIT, which is state-of-the-art -- with user-controlled code generation. The CLR has a very primitive JIT to begin with. So while the purpose might be similar, Graal/Truffle represent the future of JITs, while DLR is just a framework that helps implementing dynamic languages for the CLR.
Minor correction: what I said about a similar purpose is true for Truffle. Graal is a general-purpose, optionally-user-controlled JIT, that can (and probably will) be used to JIT Java bytecode in addition to Truffle AST nodes. So it's basically just Hot Spot's next-gen optimizing JIT compiler.
Most of the things in that answer says are simply irrelevant.
- The biggest relevant difference -- which he mentions -- is indeed value types, which are coming to Java,
- The CLR doesn't have coroutines. Yield/await are what's known as "stackless coroutines" and are, AFAIK, implemented at the language level (and besides, stackless coroutines are a far cry from coroutines, as the most powerful concept of coroutines is the stack). The JVM, OTOH, offers such sophisticated bytecode manipulation capabilities that full coroutines can be implemented as a library (e.g. Quasar).
- What he says of bytecode/package design bears absolutely no relevance to the quality -- or power -- of the VM. Those are just simple design tradeoffs with little effect on results.
The CLR offers a lot of functionality that the JVM doesn't (see Someone123's comment) - which in my opinion makes is it a lot more compelling - so in that way it is more sophisticated than the JVM.
A reference to back your statement up would be great... (i couldn't find a good one quickly). Are you aware of the capabilities of the CLR's next generation RyuJIT? What you say is at odds with what I thought, but I'd love my perceptions to be corrected if they are indeed incorrect.
> The CLR offers a lot of functionality that the JVM doesn't (see Someone123's comment)
Yes, some, but those differences are being quickly erased. The most important one is value types, which are being added to Java. See my reply to someone123.
RyuJIT's capabilities are nowhere near HotSpot's (I'd say they're about 7 years behind), and HotSpot's next-gen JIT (Graal) is another huge leap forward. The CLR's GC is also far behind HotSpot's selection, let alone offerings by other JVMs (there are many JVMs to choose from).
Now more than ever. HotSpot has undergone some revolutionary changes in the past few years -- from the G1 GC through tiered optimizing compilation and all the way to Java Flight Recorder -- while the CLR mostly added some user-facing features with little internal progress other than RyuJIT, which is maybe comparable to HotSpot's C2 JIT circa 2005 or so. Not to mention the awesome work done on Graal now, HotSpot's next-gen JIT, which is another very big leap forward.
One advantage is developing server-side .NET apps without the need of a Windows VM, with the aid of regular Unix tools in your regular dev environment. That's a win in my book.
But a cross-platform CLR opens up some possibilities even for desktop or CLI apps. The wealth of the .NET ecosystem is compelling.
> I guess the whole point is to write cross-platform code, but is the .NET environment that much better than Swift/Xcode?
Well, probably it is better if you have (say) a company full of people who know how to write C# but have never used Swift. And the whole write once run anywhere thing is nice (sure, native apps "feel" better, but if there are no native apps I'd rather have a Java version than nothing).
I am not going to make the same mistake twice and be tied down to a language (Objective-C) and private APIs (Cocoa, iOS, etc) which are useless outside of Apple's ivory tower.
I had always thought of C# and Mono as a potential cross-platform solution, but now that .NET is open-source and Microsoft are pushing it hard, even on Linux, it has become a viable one.
I suspect I am not the only Mac->iOS developer who is thinking along these lines.
Windows and .NET are different things. I'm fairly confident being able to run .NET on unix machines won't affect you very much so you can stay a happy Linux User. Also, times are changing man, for the better. Embrace it.
The only part which scares me is that people will start making Linux apps using dotnet technologies.
>Also, times are changing man, for the better. Embrace it
Yup. That is why MS had to realize that *nix is eclipsing it in cloud and to grab extra some extra pennies out of our pockets, they are releasing their products on these platform just to fool us that they care. Actually they don't care us at all.
I don't think is too little but I'm sure they are late. Too late? Probably not but imagine if they did this 10 years ago, the impact it would have had on Java and many other ecosystems. I bet many of them would have been smaller and MS larger.
The difference is the Microsoft implementation is probably going to be much better quality and better documented. Also, you can't compare Microsoft of ten years ago with the Microsoft of today.
Am I the only one bothered that they didn't include the space between the "OS" and the "X"?
More importantly, this is huge, but as a Linux developer/user I still have no desire to use .NET on my platform. Maybe Mono has scarred my permanently.
Just out of curiosity why? I personally can't imagine why someone would choose it as a favorite. Not because I think it is bad, but because I feel its kind of a kitchen sink language that doesn't really have any clear advantages or features.
In short: because it doesn't make me think about it, freeing me up to think about the problem, and gets out of my way. You're right in that it's a kitchen-sink language, but IMO it's a well-curated one, and I don't find myself having to think about patterns or other crap as I do when using Java (which I've used professionally) or wrestling with poor tooling and spooky-action-at-a-distance language design in Scala (ditto--and I like Scala, but for a lot of things it just won't get out of my way).
Nothing wrong with Microsoft bringing OSX and Linux to parity with Windows. In fact, there's a lot right with it. I like this new Microsoft, and I've been using Linux for years. Keep up the good work Redmond!
Excited to see that interesting tech like C#, F#, CLR, LINQ and friends is heading our way. If anything it'll give Java a run for its money and that's no bad thing.
I don't think anything is giving the JVM a run for its money. There are millions of man hours that have gone into performance tuning the JVM. The CLR has substantially less. Possibly for mid-size projects the CLR _could_ be an alternative but for the foreseeable future any administrator who is comfortable with Linux is likely also comfortable with the JVM tools necessary to troubleshoot and improve JVM performance.
It would've been great if the author knew what 'distribution' means in this context.
"Distribution" is hardly specific to Linux distributions in technical circles. I don't know how you got that impression. The term is synonymous with software bundle, e.g. "Erlang/OTP distribution".
I see it as the future of pop-functional programming. For example look at the way it handles type inference w/ JSON parsing. Compare that to what you have to do to parse JSON in Scala. It's subtle, but a major usability win.