[HN Gopher] C# 9 top-level programs and target-typed expressions
___________________________________________________________________
C# 9 top-level programs and target-typed expressions
Author : benaadams
Score : 63 points
Date : 2021-03-30 20:37 UTC (2 hours ago)
(HTM) web link (developers.redhat.com)
(TXT) w3m dump (developers.redhat.com)
| danielovichdk wrote:
| I have been programming with c# since 2000 i think. But I do not
| like where the languages is going.
|
| It is becoming way to loose in a sense and it seems that it wants
| more than it should.
|
| If you want to do functional programming, pick a fp language.
|
| If you want to do dynamic typed programming pick a dp language.
|
| Sure you can mix some things in, but c# is becoming way to
| scattered imo. And it's not pretty i think.
| thrower123 wrote:
| I think I'm going to get diabetes from all the syntax sugar...
|
| On the more substantive changes, it feels a little like the
| language designers have been looting F#.
|
| Combined with how fast Dotnet Core is moving and how many
| breaking changes there are there, it does feel like things are
| getting very fragmented.
|
| Stasis isn't good either; just witness the decade or so of
| stagnation after Java 1.6 as the Sun -> Oracle transition
| happened. But you can go too far in the other direction.
| emodendroket wrote:
| I don't think they're just randomly throwing stuff at the
| wall. These are all things they've been talking about for
| years.
| spaetzleesser wrote:
| I think for a lot of devs having a multiparadigm language is
| the only way to explore new things. For the stuff I am working
| on it's not really feasible to add new languages but you can
| add FP concepts slowly because C# supports it. That would also
| explain the popularity of C++ because it allows gradual
| transition.
| sumnole wrote:
| Personally, I enjoy C# becoming a multi-paradigms language like
| Common Lisp. Multiple inheritance and a good macro system would
| help close the gap. I don't need safety guards in my language,
| I'm looking for the right options when I need them.
| emodendroket wrote:
| People have been saying this all the way back to when Linq came
| out, and who could imagine C# without Linq today?
| outside1234 wrote:
| Who would have believed a decade ago that there would be a RedHat
| developer blog entry on C# today?
|
| If someone had told you that then you would have thought the
| world would have collapsed in the meantime.
| zwieback wrote:
| Exactly my first thought. I remember my first steps with C# and
| it felt very "MS version of Java" and I didn't expect how much
| a) I would like it and b) how successfully it would spread to
| other areas
| whoisthemachine wrote:
| To me, the benefit of "Target-typed new expressions" is more with
| bringing consistency to class-scope member declarations and
| method-scope member declarations, so these two can look the same,
| and a programmer only has to read one way of declaring new
| members in C#: public class MyClass {
| private readonly MyDependency _myDependency = new();
| public void MyMethodThatDoesWork() { MyVariable
| variable = new(); } }
|
| As opposed to the (now old, IMO) var syntax/Java-like syntax
| mixture: public class MyClass { private
| readonly MyDependency _myDependency = new MyDependency();
| public void MyMethodThatDoesWork() { var variable =
| new MyVariable(); } }
|
| Edited for HN formatting.
| keithnz wrote:
| 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.
| whoisthemachine wrote:
| Oh true, there are still use cases where it's valuable. `out
| var ` also comes to mind.
| Cshelton wrote:
| 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
| document and add explicit types as well on save. So
| complicated type signatures for linq aren't a problem!
| wvenable wrote:
| Can't disagree more. var improves readability so much that
| I can't imagine reviewing code anymore with unnecessary
| type declarations everywhere.
| nycdotnet wrote:
| Agreed that `var` isn't going anywhere, but this feature's
| best use case is with complex generics/enumerables and things
| like anonymous tuple types. For example: //
| old: var x = new List<KeyValuePair<string, int>>
| { new KeyValuePair<string, int>("a", 1), new
| KeyValuePair<string, int>("b", 2) }; // new
| var x = new List<KeyValuePair<string, int>> {
| new("a", 1), new("b", 2) };
| wk_end wrote:
| Wow, when I (only a C# dabbler) read about this feature in
| the article I thought it sounded incredibly silly, but this
| really sells it. Was there really no better way to create
| tuples before?
| gnud wrote:
| You could create tuples with `Tuple.Create("a", 1)` since
| at least .NET 4, if not 3.
|
| Since C# 7 you can also create tuples using just `("a",
| 1)`. But tuples are not KeyValuePairs. So the new "new"
| syntax will be very helpful in a lot of cases.
| [deleted]
| wvenable wrote:
| C# (as of 7.0) has pretty nice tuple syntax that supports
| all things you expect (deconstruction, etc):
|
| https://docs.microsoft.com/en-us/dotnet/csharp/language-
| refe...
|
| But the situation here is that the type KeyValuePair is
| older than that and isn't a tuple.
| goto11 wrote:
| The article states that the benefit of target-typed new-
| expressions is that "the type declarations are nicely aligned"
| compared the use of "var".
|
| I think a better justification is that fields and properties does
| not support type inference, so this can avoid some redundant type
| expressions for initializes, just like "var" can avoid redundant
| type expressions for local variables.
|
| Of course it would be more elegant if fields/properties supported
| type inference like "var", but that is a can of worms since you
| can have recursive dependencies.
| belinder wrote:
| Unfortunately the new tricks can't be used when the codebase is
| still stuck on .net framework :(
| shireboy wrote:
| There are ways, but definitely can be hard to get unstuck from
| framework. This came across my newsfeed this am:
| https://www.telerik.com/blogs/jump-starting-migration-dotnet...
| and also, the other day, dotnet rocks podcast had a guy on
| talking about an upgrade tool. I think it was this one:
| https://visualrecode.com/ He was also discussing the "Strangler
| Pattern": https://akfpartners.com/growth-blog/strangler-
| pattern-dos-an...
| bob1029 wrote:
| There are many paths out of hell. Check out the windows
| compatibility pack for all things active directory, WCF &
| System.Drawing:
|
| https://docs.microsoft.com/en-us/dotnet/core/porting/windows...
|
| Winforms is probably a no-go on migration, but you should
| definitely check out Blazor if you want to develop any new
| business apps. We have constructed some incredibly complex
| business dashboards using this framework and cant imagine how
| some of this would even be possible if we had to move back to a
| front-end client framework and invent a bunch of JSON APIs.
|
| Also, the new Blazor Desktop stuff is _extremely_ exciting:
|
| https://medium.com/young-coder/blazor-desktop-the-electron-f...
|
| > The first difference is that the WebWindow container doesn't
| use WebAssembly at all. Yes, you can run more or less the same
| Blazor application in WebWindow as you would in a web page. But
| when you use a web page, it's executed by a lightweight .NET
| runtime that's powered by WebAssembly. When you use it in
| WebWindow, it will use the cross-platform .NET runtime
| directly.
|
| There is a lot of really amazing stuff coming down the roadmap,
| so I can easily advocate for enduring some degree of pain to
| get on this wagon.
| thrower123 wrote:
| I'm pretty sure WinForms is being migrated. I've built dotnet
| 5 WinForms apps, anyway. At least on Windows - I wouldn't bet
| on a Linux Gtk/Qt port any time soon.
|
| WPF is probably dead though.
| my123 wrote:
| WPF is not dead, it got open-sourced and was ported to .NET
| Core 3.1 onwards.
| nycdotnet wrote:
| We use C# 9 in our WebForms monolith and it works fine. Just
| add `<LangVersion>latest</LangVersion>` to your .csproj file.
| (This assumes you're using recent Visual Studio version and use
| a recent version of MSBuild as well)
| lwansbrough wrote:
| Allegedly there's an upgrade path from .NET 4.8 to .NET 5.
| keithnz wrote:
| 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.
| belinder wrote:
| In our case not web forms but WCF
| WorldMaker wrote:
| You may want to keep an eye on CoreWCF:
| https://github.com/CoreWCF/CoreWCF
|
| Though as a heavy WCF user in the past, I'd suggest your
| best bet is simply to throw out all your binding configs,
| and build your own REST API or similar backend (gRPC
| support in .NET 5+ is something often also recommended if
| you want something more RPC-like and need/want a more
| binary-serializer like approach, though in 2021 I'd just
| use JSON and something REST-ish myself). The nice thing
| about the Interface-driven "contract" approach should be
| that implementing your own is just a matter of
| implementing all your contract interfaces and injecting
| the physical implementations yourself.
|
| I realize that can be easier said than done as things
| accidentally got coupled to very specific styles of
| bindings over the years and not everyone followed best
| practices and used the Async contracts so you have to
| tear out a bunch of synchronous faking code and wire back
| in Task<T>/ValueTask<T>. But generally, overall, the
| process was implement the interfaces and remove the
| "magic" in the process and I often found you end up with
| something better anyway because it is simpler and prone
| to less "magic" failures.
| UweSchmidt wrote:
| 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?
| Analemma_ wrote:
| I second the other commenter suggesting you should try to
| rip off the WCF bandaid and go to a RESTful API as soon
| as you can. It sounds scary but after the one-time pain
| of migration we've had way fewer "magic, black box"
| errors that require insane investigations and hacks.
| goto11 wrote:
| 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 tools.
| nikanj wrote:
| Your programming language either dies young, or it lives
| long enough to become the very legacy crud it sought to
| replace.
| wvenable wrote:
| > MS really made a grave mistake by coupling the evolution
| of the C# language to the .NET version.
|
| For the most part that isn't true. You can use later C#
| compilers with older frameworks. Some features do,
| unavoidably, require framework support.
|
| But that being said, the changes in C# aren't often that
| radical that I feel particularly constrained by older
| versions.
| nycdotnet wrote:
| At work we've been slowly pulling code out of our WebForms
| monolith. That's still on .NET Framework, and will be
| forever until we're done killing it, but we can use recent
| VS and MSBuild with it and we use C# 9 as well. Business
| code generally works copy and paste in .NET Core, so
| there's a really good path to migrate to newer stuff,
| especially with .Net Standard 2.0 being a thing.
|
| gRPC is really fast and we have the WebForms monolith call
| into .NET Core services now so we can improve the back-end
| without dealing with so much ASPX crap.
| aliswe wrote:
| Not really
| WorldMaker wrote:
| Not by default, no. These two specific tricks should work on
| .NET Framework (some of the other tricks in C# after 7 or 8
| require functionality that .NET Framework doesn't have,
| though). You can ask VS to use the more recent C# compiler with
| the LangVersion tag in the .csproj:
| https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
|
| Obviously, it's not suggested doing that nor is entirely well
| supported, but it is at least allowed.
|
| Though if you are looking to use top-level programs you
| probably are working in greenfields anyway that should just be
| .NET 5+. It's not really a feature that makes a lot of sense
| for existing codebases as it is more a teaching tool/"quick and
| dirty command line app/script" tool.
| ryandrake wrote:
| Wow, a full-screen cookie pop-up with a "X" dismiss button in the
| upper right corner that just causes the full-screen pop-up to re-
| display. Can it get more obnoxious?
|
| This is the second one on the HN front page today [1]. HN tries
| to avoid paywalled articles, maybe we should also discourage
| articles that start out by deliberately hiding the content.
|
| 1: https://news.ycombinator.com/item?id=26639722
| binarynate wrote:
| I think that C# is underrated. Although TypeScript is my default
| language choice for most programming, C# / .NET is my choice for
| cases where:
|
| - high performance is important - or interop with native
| libraries is required (because C#'s DllImport attribute makes
| that super simple)
|
| Another benefit is that C# is syntactically similar to TypeScript
| (they were both designed by Anders Hejlsberg after all), so
| switching between the two languages feels easy. Java and Go are
| both similar to C# in terms of performance, but interfacing with
| native code isn't as simple with those languages, and they're
| also not as similar to TypeScript as C# is (especially Go, which
| is quite different).
| dataflow wrote:
| 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.
| DownGoat wrote:
| It is super easy with dotnet core. The new CLI is pretty
| simple, you use it as a package manager and compiler. Visual
| Studio also uses the CLI to run and debug dotnet core
| projects. https://docs.microsoft.com/en-us/dotnet/core/tools/
| MikeTheGreat wrote:
| Is it possible to create a single, stand-alone, self-
| contained .exe? (I'm fine with only building for a single
| platform - Mac/Win/Linux)
|
| Needing to run my programs (which show up as .dll's) using
| dotnet just feels weird (and it doesn't match my intuition
| for 'how programs are run' in Windows cmd/etc).
|
| I'd be fine with an .exe that's not self contained but at
| least I run it like a 'normal' exe. :)
| pjc50 wrote:
| You have to set up "dotnet publish" for the project that
| makes the executable.
|
| It then makes a stub loader "your program.exe" which
| looks and behaves normally. You can then make it "self
| contained", which bundles the assemblies for you and
| transparently unpacks them.
|
| You can have different publish profiles for the different
| targets.
| smcl wrote:
| Yes that is possible, you can produce an .exe which
| contains your application's assemblies but relies on the
| appropriate .NET runtime being present on the user's
| computer. You can _also_ build a .exe which has the .NET
| runtime bundled, but it can be quite big. I made a simple
| program that wrote "Hello World" to the console [1] and
| it was between 46-78MB: https://blog.mclemon.org/no-this-
| is-what-peak-hello-world-lo...
| pjc50 wrote:
| Yeah, it's not really a "real" native binary.
|
| You can get it down to 8kb by jettisoning all comforts:
| https://medium.com/@MStrehovsky/building-a-self-
| contained-ga... but that's not exactly practical.
| oblio wrote:
| > Is it possible to create a single, stand-alone, self-
| contained .exe?
|
| Yes.
| bob33212 wrote:
| They were created by the same
| person.https://en.m.wikipedia.org/wiki/Anders_Hejlsberg All the
| hate C# gets is because of balmer and gates, not for technical
| reasons
| zwieback wrote:
| C# is my goto for Windows, for sure. Is the native interop good
| in Linux as well? I've never even considered anything like
| that, would probably gravitate to C++ since that's what I'm
| familiar with but would seriously consider Go or Java in non-
| Windows situations.
| josteink wrote:
| How do you think they built the Linux-version of the .NET
| standard library? ;)
| meibo wrote:
| C# on Linux, as of the past 2 or 3 years, has been
| consistently improving with great tooling, good interop, is
| open source(MIT) and has the ability to package "native"
| versions of your app that contain the runtime at negligible
| space costs for distribution or deployment.
|
| Give .NET 5 on Linux a try, you'll be surprised!
|
| For me, the work this team has been doing is the example of
| the positive "change" Microsoft has brought to the open
| source space. A stellar language with great infrastructure.
| pjc50 wrote:
| The native interop is the same. That is, if your DLL and .so
| have the same function signatures, you can use the same
| interop code unmodified between Linux and Windows. This is
| really convenient.
|
| (But watch out for bitness)
| scott00 wrote:
| Interop on Linux works well.
| emodendroket wrote:
| I'm not working with C# anymore but I'm really liking the
| features they keep adding.
___________________________________________________________________
(page generated 2021-03-30 23:00 UTC)