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

Welcome to C# 10

devblogs.microsoft.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Welcome to C# 10

#41

Post by cogman10 »

int_19h wrote: post #31
azth wrote: post #16

Earlier quoted context omitted.

I find Java's features to be very well balanced, and only make it into the language after they've been vetted and tested in the wild by other languages. e.g. see their take on concurrency by means of project Loom. No need for async/await and providing separate APIs for sync vs async operations. It has records and sealed types and pattern matching, and is getting destructuring soon.

.NET async interops nicely with any other language that can do basic callbacks (even C!). How does that work in Loom?

For VM languages no problem, all those languages will support threads or using threads.

For non-VM interopt it will block the carrier thread if a native call causes any sort of blocking.

In Java, external to the VM calls are almost non-existent so it's not much of an issue. Likely you'd do those sorts of calls as regular kernel threads instead of the Loom virtual threads.

Re: Welcome to C# 10

#42

Post by xonix »

alberth wrote: post #12

Dumb questions: why does it seem like languages always continually add features? Can a language not become "feature complete", while still improving over time?

There is Awk - fascinating mini-language almost unchanged for decades. Therefore very portable. You can learn it once and be sure you know it all.

Re: Welcome to C# 10

#43

Post by Jtsummers »

bmitc wrote: post #27
alberth wrote: post #12

Dumb questions: why does it seem like languages always continually add features? Can a language not become "feature complete", while still improving over time?

I think F#, Clojure, and Elixir are languages that show it's possible to stop adding major features to.

Scheme as well. Notably, these languages are (mostly) capable of letting developers add new models of computing or software design on top of the base language in a way that appears natural as a user.

If you want OO in Scheme, you can do it (and various models of OO at that). If you want a concurrent model, you can do it. If you want a relational programming model, you can have it.

Try doing the same with, for example, C. You can accomplish it, but you have to jump through hoops or rely on OS libraries or other things. And it will rarely, if ever, feel "natural" within the language.

Re: Welcome to C# 10

#44

Post by pharmakom »

azth wrote: post #16
cogman10 wrote: post #13

Earlier quoted context omitted.

Does that make Java the C of managed languages? The great thing about C#/kotlin throwing the kitchen sink at stuff is the good stuff eventually makes it's way into Java.

I find Java's features to be very well balanced, and only make it into the language after they've been vetted and tested in the wild by other languages. e.g. see their take on concurrency by means of project Loom. No need for async/await and providing separate APIs for sync vs async operations. It has records and sealed types and pattern matching, and is getting destructuring soon.

I much prefer the Haskell / F# approach of using do-notation to allow the user to build their own syntax.

I don’t think I can build an Async> expression with Loom, for example.

Re: Welcome to C# 10

#45

Post by int_19h »

cogman10 wrote: post #41
int_19h wrote: post #31

Earlier quoted context omitted.

.NET async interops nicely with any other language that can do basic callbacks (even C!). How does that work in Loom?

For VM languages no problem, all those languages will support threads or using threads. For non-VM interopt it will block the carrier thread if a native call causes any sort of blocking. In Java, external to the VM calls are almost non-existent so it's not much of an issue. Likely you'd do those sorts of calls as regular kernel threads instead of the Loom virtual threads.

To clarify, by interop here I don't just mean calling foreign functions. I mean calling async foreign functions. When async is explicit, it's easy to handle it on ABI level - it's just a bunch of callbacks (or abstractions wrapping them, like tasks/futures).

For example, suppose you're writing a Windows desktop app, and you decide to do so in Java. Modern Windows APIs are async. How would you asynchronously invoke such an API? In C#, you'd just use await.

Re: Welcome to C# 10

#46

Post by int_19h »

rvcdbn wrote: post #40
int_19h wrote: post #31

Earlier quoted context omitted.

.NET async interops nicely with any other language that can do basic callbacks (even C!). How does that work in Loom?

Definitely not as easy but Go managed to get it to work fairly well with some extra overhead. I would rather the language design for pure Java first and C interop second.

This approach results in more closed ecosystems, though, where everything has to be re-implemented to work well, instead of reusing existing libraries (that have been polished for decades in some cases).

Also, what about OS APIs? Those always going to be at the bottom of the stack, and they are increasingly async themselves.

Re: Welcome to C# 10

#48

Post by colejohnson66 »

metaltyphoon wrote: post #14
pharmakom wrote: post #5

C# is becoming the C++ of managed languages. I wish they would stick to a smaller set of more powerful features… like an earlier C# with hygienic macros or something.

I agree in a sense but I would do it another way. Either change to the Rust edition equivalent, or simply drop old stuff and keep in the newer bits.

There is a Rust edition equivalent in C#…kindof. The csproj file has a property to specify which version of the language you want to use. So if you set it to 9, the compiler won’t allow features from 10 (supposedly; I haven’t tested it).

Re: Welcome to C# 10

#49

Post by lostmsu »

bmitc wrote: post #27
alberth wrote: post #12

Dumb questions: why does it seem like languages always continually add features? Can a language not become "feature complete", while still improving over time?

I think F#, Clojure, and Elixir are languages that show it's possible to stop adding major features to.

I don't think F# did that by choice. The reference compiler implementation is simply too complicated, which makes it hard to add new features. It is, ironically, also written in F#.

Re: Welcome to C# 10

#50

Post by bmitc »

lostmsu wrote: post #49
bmitc wrote: post #27

Earlier quoted context omitted.

I think F#, Clojure, and Elixir are languages that show it's possible to stop adding major features to.

I don't think F# did that by choice. The reference compiler implementation is simply too complicated, which makes it hard to add new features. It is, ironically, also written in F#.

From what I have seen, Don Syme is a very pragmatic language designer and doesn't want to include features just to add them, and he holds .NET interoperability extremely high on the priority list, which further limits adding more functional programming features.

I imagine the compiler implementation is complicated, and I would guess it is due to the .NET interoperability.

Post reply on HN