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

C# 9 top-level programs and target-typed expressions

developers.redhat.com

Post reply on HN
Print view View original

181–188 of 188 posts

Re: C# 9 top-level programs and target-typed expressions

#181

Post by twodave »

lostmsu wrote: post #105
int_19h wrote: post #57

Earlier quoted context omitted.

The C# language design process is very much in the open, so anybody can go and take a look at the rationale etc. https://github.com/dotnet/csharplang

I think it suffers from the design by a self-selected committee now. Very little of recent changes have long-term vision behind them now, and seem to be quick patches. Specifically, I just tried disabling 7.0+ features in an open source project I run, and we only actively used pattern matching for "is MyType inst", ref structs (hi Rust!, that one is really fundamental), and natively sized integers (which are still po…

For contrast, I'm looking at the old C#7 and C#8 release notes--I can say our team frequently uses:

C# 7

  - value tuples
  - local functions
  - throw expressions
  - default literals
  - out variables
C# 8

  - switch expressions
  - using declarations
  - static local functions
  - asynchronous streams
  - null-coalescing assignment
  - enhance string interpolation e.g. via @$ prefix

Re: C# 9 top-level programs and target-typed expressions

#182

Post by flukus »

kwertyoowiyop wrote: post #88

Can I just create a single .cs file somewhere, and execute it by typing its name? No Visual Studio solution/project shenanigans? That’s my dream. Top-level programs to eliminate boilerplate is a nice related step.

It's fairly trivial to write your own for any language, I have a c version where you simply start the file with "#!/usr/bin/env crun" the guts of the script is:

  gcc -x c -ggdb -Wall -Wextra -Wno-main -Wno-unused-parameter -o $out $CFLAGS -include $header - $LDFLAGS
Obviously gcc would be replaced with csc, you wouldn't need CFLAGS and you might need a temp file or something.

Re: C# 9 top-level programs and target-typed expressions

#183

Post by UweSchmidt »

WorldMaker wrote: post #92
UweSchmidt wrote: post #26

Earlier quoted context omitted.

Could you expand a little on that? How exactly does an REST API backed desktop/forms application look like in 2021, and how is the decoupling accomplished?

A lot of the decoupling is naturally accomplished by just not being backward compatible with previous WCF bindings and throwing out the whole mess. The easiest place to start with is your data contracts. You may not have many depending on which side of the RPC/not-RPC boundary you were on, but it may be as simple as creating plain classes that implement those data contracts and then double checking that the Newtonsof…

Thanks!

Re: C# 9 top-level programs and target-typed expressions

#184

Post by SideburnsOfDoom »

emodendroket wrote: post #173
SideburnsOfDoom wrote: post #172

Earlier quoted context omitted.

So you're going to go with a top-level entry point even with a substantial program? OK, I can see that happening. I guess the point is that your substantial program will also have plenty of classes and methods elsewhere, so the idea that "you can do a one-liner without having to first learn about declaring classes and methods and namespaces" isn't relevant to you. You save a few LOC 1 time over in your top-level entr…

Yeah, true. I don’t find the “for beginners” thing too compelling but I do like the idea of removing boilerplate.

I think that MS is at this point fairly concerned with the "long game" for .NET, i.e. get the next generation onboard now, reap benefits for decades to come. Or equivalently they noticed that .NET wasn't "cool with the kids" and set out to fix that.

Re: C# 9 top-level programs and target-typed expressions

#185

Post by goto11 »

josteink wrote: post #159
goto11 wrote: post #144

Earlier quoted context omitted.

> Keeping every new C# feature compatible with every obsolete .NET version obviously has a big technical cost Strawman there. The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. Going from framework to core will require (risky, expensive) rewrites, which means lots of real-world code wi…

> The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? Why would you expect the SDK of the officially deprecated platform to get updates with the latest compilers and technologies,…

> But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates?

I'm not sure what you mean with "consistent", but the problem is of course creating two incompatible platforms in the first place. All previous releases of .net have been largely backwards compatible (except for rare edge cases and security issues), so it remained a single platform where you could get the latest improvement just by upgrading the framework.

Of course when you have created two incompatible platforms, it would be double the work to keep both updated, so they have to abandon one. Which is why they shouldn't have done it in the first place. They could have upgraded and deprecated components in a modular manner without creating a whole separate incompatible platform.

Re: C# 9 top-level programs and target-typed expressions

#186

Post by goto11 »

syspec wrote: post #167
goto11 wrote: post #132

Earlier quoted context omitted.

You save typing by not having to repeat the class name.

But you could use var instead of Person on the left, so you're only saving 3 characters which likely you're not typing out in most editors

Var is not supported for fields or properties though.

Re: C# 9 top-level programs and target-typed expressions

#187

Post by josteink »

goto11 wrote: post #185
josteink wrote: post #159

Earlier quoted context omitted.

> The problem is not "every obsolete .NET version", the problem is .net in reality have two incompatible platforms at this point, but newer C# versions are only supported on one of them. But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? Why would you expect the SDK of the officially deprecated platform to get updates with the latest compilers and technologies,…

> But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? I'm not sure what you mean with "consistent", but the problem is of course creating two incompatible platforms in the first place. All previous releases of .net have been largely backwards compatible (except for rare edge cases and security issues), so it remained a single platform where you could get the lat…

> the problem is of course creating two incompatible platforms in the first place

Interest in .NET was dwindling because ... it was Windows-only and its APIs and frameworks was a bad fit for the cloud. It was literally heading for a nose-dive.

So if Microsoft wanted to address that and make .NET truly cross-platform, they either had 2 options: Port everything which is Windows-specific to all other platforms, or just strip it from the core .NET APIs.

If they wanted to make it more cloud friendly, again they had 2 options: Make the already complex APIs, even more complex by trying to shoehorn cloud use-cases into a BCL largely designed for a Windows AD-network kind of security model. Or just start over, with a clean slate, and APIs designed for the age we're currently writing software for.

While yes, the latter options creates a new incompatible platform, it's really the only realistic option. And if you're going for the first latter option, you might as well go for the second.

I don't think you will find anyone who believes Microsoft would be able to execute on .NET Core as it did, if it had tried to bring all the old legacy along for the ride.

> All previous releases of .net have been largely backwards compatible

Yes. Which has been a mixed blessing. Look at what a mess classic ASP.Net has become (which ASP.NET MVC is built upon) wrt to page-event life-cycles and what not. Are you not happy to see all that terrible things truly gone, for good?

> Which is why they shouldn't have done it in the first place. They could have upgraded and deprecated components in a modular manner without creating a whole separate incompatible platform.

But that's what they did, really.

They obsoleted classic ASP.NET and WebForms. They obsoleted WCF servers. And they obsoleted the Windows-centric security-model. Anything else?

Everything else is still there. The language, the rest of the BCL, the packages you know and love.

And you were given years after they said "These technologies are not getting any new updates" to migrate to the new ones (while still on classic .NET Framework), which was kindly published as multi-targeted Nuget-packages, to give you a gradual migration path.

Sure. It wasn't perfect, but what is?

If anyone is to blame here, it is how people have kept hanging on to classic .NET for years when the writing has been on the wall, hoping that maybe perhaps if they wait for another .NET Core release... That all those terrible technologies everyone is glad to let go off, will be ported to .NET Core too.

You know what? It didn't happen, because .NET Core was a community project, and the community didn't want it, or at least certainly not enough to warrant the effort.

And not only that! Thanks to being freed from the Windows it was borne into, it has become more vibrant and popular than ever before.

It's no longer a technology threatened with extinction. As someone using and invested in .NET yourself, surely you must appreciate that?

Re: C# 9 top-level programs and target-typed expressions

#188

Post by goto11 »

josteink wrote: post #187
goto11 wrote: post #185

Earlier quoted context omitted.

> But that’s fairly consistent right? An old platform not getting updates and a new platform getting updates? I'm not sure what you mean with "consistent", but the problem is of course creating two incompatible platforms in the first place. All previous releases of .net have been largely backwards compatible (except for rare edge cases and security issues), so it remained a single platform where you could get the lat…

> the problem is of course creating two incompatible platforms in the first place Interest in .NET was dwindling because ... it was Windows-only and its APIs and frameworks was a bad fit for the cloud. It was literally heading for a nose-dive. So if Microsoft wanted to address that and make .NET truly cross-platform, they either had 2 options: Port everything which is Windows-specific to all other platforms, or just…

They could have done all those things but still retained backwards compatibility. Consider how WPF was introduced as a complete replacement for WinForms. This didn't mean WinForms stopped working! You can run both under the same .net version and you can use most recent C# version (and all other libraries) with both.

It is great that MS delivered a ground-up rewrite of ASP.NET. There is no reason this should cause the old ASP.NET framework to stop working. They could exist in parallel just like WPF and WinForms - one for new code, one for legacy code. Old libraries should just keep working by default.

Post reply on HN