C# 9 top-level programs and target-typed expressions • Hacker News Board

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

#141

Post by josteink » Wed, Mar 31, 2021, 8:50 AM UTC

goto11 wrote: post #14

lwansbrough wrote: post #4

Earlier quoted context omitted.

Allegedly there's an upgrade path from .NET 4.8 to .NET 5.

The upgrade path is massive rewrites, something most business are wary of. For good reasons. MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. This means all projects on the .NET framework is now also stuck with an obsolete language version for no good reason. It is becoming a a lot less fun to be a C# developer because you more often will have to work with obsolete tool…

> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version.

It’s not directly coupled, but each version of C# has a minimum .NET version it can support, due to the requirements of the features in the language itself (like LInQ in the past).

And MS has been very up front about .NET framework being legacy and not getting any future upgrades for years now.

Keeping every new C# feature compatible with every obsolete .NET version obviously has a big technical cost. MS has clearly decided it would rather spend its effort to improve C# for those keeping up to date.

> It is becoming a a lot less fun to be a C# developer because you more often will have to work with obsolete tools.

On the contrary. The language and platform is better to work with than ever and I can do everything I need, on Linux, with just Emacs and the CLI.

I couldn’t be happier!

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

#142

Post by goto11 » Wed, Mar 31, 2021, 9:56 AM UTC

starik36 wrote: post #62

keithnz wrote: post #6

Earlier quoted context omitted.

if you have built anything on web forms, then you really have no way forward other than rewriting all that. That alone will keep many an enterprise locked on .NET Framework for quite some time.

You can give it a shot with this project. https://github.com/FritzAndFriends/BlazorWebFormsComponents It emulates WebForms component with Blazor. Although I would just start from scratch.

> Although I would just start from scratch.

Which is fine if you are a hobbyist developing for fun.

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

#143

Post by goto11 » Wed, Mar 31, 2021, 10:08 AM UTC

Cshelton wrote: post #35

keithnz wrote: post #10

Earlier quoted context omitted.

I can't see var going anywhere, many times you aren't directly creating a new object, but getting a generated object from something ( like linq) which tends to have more complicated type signatures.

I hate hate hate var. Sure, in your own IDE, and reading the code you just wrote, no problem. But when doing code reviews and jumping all over, I want to see the type right there. Nothing more frustrating than reviewing a PR with var's all over. This isn't even up for debate anymore... No more var! It is frustrating to still see var as the recommended way by Microsoft... You can even put in a rule to format the docum…

Even then, you only see the type signature when you are initializing the variable, not every time you use it.

If you really want to see type signatures everywhere, you should use something like Hungarian notation which embed type information in the name. And you should disallow method chaining and having methods or properties as parts of expressions.

But I would recommend just using an IDE instead.

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

#144

Post by goto11 » Wed, Mar 31, 2021, 10:25 AM UTC

josteink wrote: post #141

goto11 wrote: post #14

Earlier quoted context omitted.

The upgrade path is massive rewrites, something most business are wary of. For good reasons. MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. This means all projects on the .NET framework is now also stuck with an obsolete language version for no good reason. It is becoming a a lot less fun to be a C# developer because you more often will have to work with obsolete tool…

> MS really made a grave mistake by coupling the evolution of the C# language to the .NET version. It’s not directly coupled, but each version of C# has a minimum .NET version it can support, due to the requirements of the features in the language itself (like LInQ in the past). And MS has been very up front about .NET framework being legacy and not getting any future upgrades for years now. Keeping every new C# feat…

> 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 will never be migrated. That is just reality. Startups who rewrite their whole tech stack every six months is not the norm outside of Silicon Valley.

So for the foreseeable future, .net will have these two platforms in parallel. And unless you are a hobbyist, you probably don't get to decide which one to use.

Microsoft have forgotten how important developer enthusiasm is for the success of a platform. Nobody likes to work on legacy code with obsolete tools with no end in sight.

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

#145

Post by flohofwoe » Wed, Mar 31, 2021, 10:28 AM UTC

twodave wrote: post #91

I mean, top-level programs are nice, I guess? IMO it's more of a means of attracting non-.NET developers into the fold. I work in a .NET shop and we probably won't use this in our production code. The benefit of target-typed expressions IMO is that it changes property syntax from: public List Foos = new List (); to simply: public List Foos = new(); It may seem subtle, but if you write C# you see this pattern constant…

Top-level programs seem like a nice feature for shell scripting, assuming that the C# compiler has a "compile and run" feature (without littering intermediate files of course).

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

#146

Post by linknoid » Wed, Mar 31, 2021, 10:55 AM UTC

scott00 wrote: post #102

dataflow wrote: post #33

Earlier quoted context omitted.

A bit of a tangent but is it possible yet to compile C# to native code easily (like calling a normal compiler on the command-line)? Last time I checked I needed to jump through a bunch of hoops through Visual Studio, and create some XML or other nonsense. I don't get why they've made it so hard compared to just compiling managed code.

I think the short answer to your question is "no". For single-file-no-project simplicity your best bet is dotnet-script: https://github.com/filipw/dotnet-script For native code your best bet is NativeAOT: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT I'm not aware of anything that combines the two. As to why: it's not so much that they've made it hard as they haven't made it easy. The reason they haven'…

The C# compiler has always been included with the .NET Framework, it has never required Visual Studio:

https://stackoverflow.com/questions/861384/is-it-possible-to...

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

#147

Post by joshsyn » Wed, Mar 31, 2021, 10:55 AM UTC

jongalloway2 wrote: post #107

joshsyn wrote: post #98

Scala 3 kills C# by a large margin, imho. C# is not a good pursuit unless you are stuck with .Net codebase.

How so? .NET is 2-4x faster than Scala in benchmarks ( https://www.techempower.com/benchmarks/#section=data-r20&hw=... ). Do you just prefer the syntax and language features?

I like the expressibility, its easy to improve performance in the compiler later.

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

#148

Post by linknoid » Wed, Mar 31, 2021, 11:11 AM UTC

nycdotnet wrote: post #22

belinder wrote: post #2

Unfortunately the new tricks can't be used when the codebase is still stuck on .net framework :(

We use C# 9 in our WebForms monolith and it works fine. Just add ` latest ` to your .csproj file. (This assumes you're using recent Visual Studio version and use a recent version of MSBuild as well)

There are a few language features which require a specific type to be defined, but you can define those types yourself.

For example, to use record syntax, you need to define this attribute:

    namespace System.Runtime.CompilerServices { public class IsExternalInit : Attribute { } }

And supporting the new indexing syntax requires you to define System.Index and System.Range types, which are a bit more involved, but still pretty trivial:

https://docs.microsoft.com/en-us/dotnet/api/system.index?vie... https://docs.microsoft.com/en-us/dotnet/api/system.range?vie...

But pretty much all the other new C# language features I've tried have just worked straight out of the box with .NET 4.7.2.

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

#149

Post by merb » Wed, Mar 31, 2021, 11:21 AM UTC

zwieback wrote: post #121

binarynate wrote: post #103

Earlier quoted context omitted.

Yes, native interop works the same across all platforms (Linux, macOS, Windows, Android, iOS). You can just place a dynamic library with C linkage (.so, .dylib, or .dll file) into your app's folder, and then you can call the native functions as external functions in C#. For example, if your library exports the following C function: void printMessage(char *message) { printf("Message from C#: %s", message) } You can ca…

Thanks, I'll give it a try. I've done a lot of interop in Windows so it'll be good to leverage to Linux.

it's a little bit harder when your linux library is not inside LD_LIBRARY_PATH or the windows one is not inside a path. but there are tricks to override the loading behavior, it's just a little bit tricky since you need a loading context, which can load other c# dll's without having a reference to them.

it's basically like that: AssemblyLoadContext loads the managed assembly (like YourPackage.NativeApi which contains the DllImport) and the AssemblyLoadContext that loads via LoadUnmanagedDll all paths to the DllImports. you also need a Shared Library for the calling package and the dll import package so that you can do (Type)Activator.CreateInstance(LoadContext.LoadFromAssemblyName(YourDllImportAssemblyName))

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

#150

Post by ninkendo » Wed, Mar 31, 2021, 11:29 AM UTC

unnouinceput wrote: post #136

ninkendo wrote: post #97

Earlier quoted context omitted.

To give an example, in Swift, I can write a hello.swift with: #!/usr/bin/env swift print("Hello") And after a chmod +x, it works. Granted, anyone who I distribute this to will need a swift compiler installed, but that’s to be expected (and similar for Python.) Golang and other “compiled” languages have similar ways of making this work too.

Oh, I get it. You mean install some sort of interpreter that is called by the OS for that language. Sorry, I live in real world, where customers don't allow you to install a gazzilion files just to run your application, they expect a proper installer that is under strict supervision by their admin team and you only deliver executables.

I don’t think the use case for this is anything you’re shipping to “customers”... more for just personal code you can use as scripts/playgrounds.

To use the swift example, often I want to double check whether something in the language works as I expect, so I write a quick test.swift and run it. It’s a useful thing even if you don’t personally want it.