Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing .NET Core 2.0

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

141–145 of 145 posts

Re: Announcing .NET Core 2.0

#141

Post by pjmlp »

TensorMetric wrote: post #140
pjmlp wrote: post #138

Earlier quoted context omitted.

We can forget about UWP support, it isn't going to happen in the near future, who knows if it ever will. "The F# team is currently focused on .NET Core tooling in Visual Studio and further support for .NET Core as it evolves. There is no ETA for .NET Native/UWP support at this time." -- Phillip Carter [MSFT] https://blogs.msdn.microsoft.com/dotnet/2017/08/14/f-and-net... Better focus on C# and C++ and call it a day.

I really can't stand C#. F# is what drove me to .NET in the first place. And I don't like going back to C++, is there any GUI/XAML tooling for it? If not, I'd rather use something like Rust.

With UWP, Visual C++ kind of finally caught up with C++ Builder, it even has support from Blend for UI design.

MFC is mostly on maintenance and new application should use XAML + C++/CX.

C++/CX makes use of the C++/CLI extensions but it targets AOT compilation to native code instead.

The alternatives are C++ with WRL (Windows Runtime Library), basically ATL replacement, and what most Microsoft teams actually use for the UWP kernel components.

https://docs.microsoft.com/en-us/cpp/windows/universal-windo...

Because most C++ devs would rather use something more standards friendly, there is work in progress to eventually replace C++/CX with C++/WinRT, taking advantage of C++17 features.

“Embracing Standard C++ for the Windows Runtime"

https://www.youtube.com/watch?v=lm4IwfiJ3EU

“Putting Coroutines to Work with the Windows Runtime"

https://www.youtube.com/watch?v=v0SjumbIips

Re: Announcing .NET Core 2.0

#142

Post by TensorMetric »

pjmlp wrote: post #141
TensorMetric wrote: post #140

Earlier quoted context omitted.

I really can't stand C#. F# is what drove me to .NET in the first place. And I don't like going back to C++, is there any GUI/XAML tooling for it? If not, I'd rather use something like Rust.

With UWP, Visual C++ kind of finally caught up with C++ Builder, it even has support from Blend for UI design. MFC is mostly on maintenance and new application should use XAML + C++/CX. C++/CX makes use of the C++/CLI extensions but it targets AOT compilation to native code instead. The alternatives are C++ with WRL (Windows Runtime Library), basically ATL replacement, and what most Microsoft teams actually use for t…

Thanks this is great information. Have you looked into using Scala or Rust for UWP apps?

Re: Announcing .NET Core 2.0

#143

Post by jdc0589 »

vorg wrote: post #117
jdc0589 wrote: post #84

Earlier quoted context omitted.

I'd argue it still could be true. The CLR has variants of a lot of those too, but they are much less popular. All those alternative languages for the JVM probably still would have been born at some point even if Java adapted faster, but they are as popular as they are due to Java's slow adaptation. This isn't a very good argument, but name recognition is on totally different level with alternative JVM languages too.…

Beanshell came before Apache Groovy and had many dynamic features useful in scripting for the JVM. Groovy essential copied many of those Beanshell features, then added closures, which was Groovy's real contribution to the JVM ecosystem. Soon after there was some disagreement among its leaders over the syntax when closures are used as Kotlin-style builders.

Huh, I did't know there was lineage there. Coincidentally, I've actually used Beanshell; integrating it in to a project was a SUPER pleasant experience.

It was some weird find/replace thing I contrived in college to let you do weird crap like define a bunch named regexes and use them to match and transform stuff. Contrived example that chops the "L" off long literals in files with the (optional) beanshell integration:

  integer {
        -?[0-9]+
  }

  really_bad_long_chopper {
    L
  } -> {
    String original = match.group(0);
    return original.substring(0, original.length() -1);
  }

Re: Announcing .NET Core 2.0

#144

Post by pjmlp »

TensorMetric wrote: post #142
pjmlp wrote: post #141

Earlier quoted context omitted.

With UWP, Visual C++ kind of finally caught up with C++ Builder, it even has support from Blend for UI design. MFC is mostly on maintenance and new application should use XAML + C++/CX. C++/CX makes use of the C++/CLI extensions but it targets AOT compilation to native code instead. The alternatives are C++ with WRL (Windows Runtime Library), basically ATL replacement, and what most Microsoft teams actually use for t…

Thanks this is great information. Have you looked into using Scala or Rust for UWP apps?

Not much, throughout my career I have learned that the best path is always to only use the officially supported SDK languages for production code.

All productivity or enjoyment using alternative languages gets lost in extra FFI layer, unavailable platform documentation, lack of support on the IDEs, poorer debugging, GUI tooling and code generation.

So I only use alternative languages to learn about new concepts and ways to improve my skillset, but in what concerns production code, the golden rule is 100% SDK languages.

Going back to your question, Java on UWP is only possible via the JVM provided by CodenameOne and I think it actually makes use of the Desktop Bridge, so that rules out Scala.

Rust still has a lot to catch up with C++ for using COM in a productive way, let alone .NET based languages.

UWP is basically what .NET should have been, if they had kept the original COM+ plans instead of going with the CLR. So any language targeting UWP needs to have seamless COM support, and ability to handle .NET metadata.

Re: Announcing .NET Core 2.0

#145

Post by JamesBarney »

mike_hearn wrote: post #61
sandGorgon wrote: post #19

Why are there so few new languages built on the .NET platform ? This is a genuine question - is there something about the JVM that gives rise to such vibrant ecosystems. Clojure, Scala, Kotlin, Groovy, JRuby : Most importantly, every one of them is in production use - not just as toy/experimental languages. And we havent even opened the Pandora's box that is Java 9+Truffle. There's a lot of broscience that .NET is su…

The .NET runtime is not superior to the JVM and probably never has been. Certainly not in performance. The JVM stomps .NET CLR in performance. C# has been superior to Java, as a language, for quite a long time (IMHO) and likely always will be. The libraries, well, I don't know. Pretty similar I guess. The thing to consider about programming languages is there's no way to make money from them anymore. That means they'…

It was my understanding that it was hard to compare the JVM and the CLR in terms of performance. But I'd always heard that the CLR was faster because of support for true generics, unsafe code, and value types.

I'm really interested in this, mind going into a bit more details?

Post reply on HN