Live data from Hacker News

Microsoft Launches Its .NET Distribution for Linux and Mac

techcrunch.com

201–210 of 249 posts

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#201
post #28

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…

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 Sc…

Yeah, I did a presentation at the DC Area Apache Spark meetup... slides: http://www.slideshare.net/RichardSeymour3/2015-0224-washingt... associated blog post: https://www.endgame.com/blog/streaming-data-processing-pyspa...

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.

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#202
post #150
post #28

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…

Also interesting is their F* language: http://fstar-lang.org/ "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 specifi…

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.

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#203
post #28

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…

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.

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#204

Earlier quoted context omitted.

.NET Core team member here. 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…

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 ub…

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.

[1] https://github.com/dotnet/coreclr/blob/master/Documentation/...

[2] https://github.com/dotnet/coreclr/blob/master/Documentation/...

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#205
post #174

Earlier quoted context omitted.

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. edit: Added more context

> 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 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 ...) and Foo(List ...)" 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.

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#206
post #180

Earlier quoted context omitted.

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 Sc…

Would there be a F# equivalent to that Scala/Spark thing?

so I googled and saw this.

one could say they're... looking into it...

https://careers.microsoft.com/jobdetails.aspx?jid=170944&pp=...

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#207

Earlier quoted context omitted.

>Microsoft will support .NetCore for at least 20 years. Without doubt. On Windows for sure. Not on *nix though.

I think they will. I think we're slowly moving to a post-Windows Microsoft world and MS is taking a leap to be a big part of that through tools. I do not think Windows will be a thing in 2025.

>I do not think Windows will be a thing in 2025.

If they open source it (and they hinted that they might), I think it might.

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#208
post #76

Earlier quoted context omitted.

You've listed three very different things there. For Swift, compare it to C# (depends on personal preference) For XCode, compare it to Visual Studio (IMO, VS is light years ahead) For Mac Native, compare to the .NET runtime (IMO .NET is better but it's not as clear cut)

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

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.

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#209

Earlier quoted context omitted.

You can always compile the .NET Framework into your app... https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110)....

This only works for Windows Store applications, which is a tiny subset of all the .NET applications out there.

.NET Native will expand to other app types. See the last paragraph of this section: http://blogs.msdn.com/b/dotnet/archive/2015/04/29/net-announ... .

Re: Microsoft Launches Its .NET Distribution for Linux and Mac

#210
post #28

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…

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 Sc…

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

Post reply on HN