Run .NET Core Apps Directly from a GitHub Gist | Hacker News Reader

Run .NET Core Apps Directly from a GitHub Gist

hanselman.com

73 pointsshanselman89 comments

Discussion of SharpScript 2 days ago, including some attempts at explaining its licensing:

https://news.ycombinator.com/item?id=20738557

TAForObvReasons: The actual Project repo https://github.com/ServiceStack/ServiceStack appears to be AGPL3 with some exceptions

mythz: The Exceptions are for OSS projects, where it can be used as the OSS license for that project. Regardless it's completely free to use for both commercial/non-commercial usage.

https://news.ycombinator.com/item?id=20738557#20739419

Yeah I'm surprised there's so much focus on the license of a free library that's also OSS. The AGPL/OSS license only applies if you're creating a custom build from source in OSS projects, if you're just using #Script from the official NuGet package you're using the commercial license which is free to use without restrictions for both commercial/non-commercial usage.

#Script started out as an alternative to Razor Pages [1] (where it was initially called ServiceStack Templates [2]) to give ServiceStack Apps a productive alternative to Razor for developing server-driven Web Apps, but as it's highly extensible without external deps or reliance in external tooling it was easy to re-purpose as a dynamic emeddable language to be able to basically script any .NET App, hence the rebrand to a stand-alone #Script language, all the whilst its implementation remained in the core ServiceStack.Common assembly. If it becomes an issue we can look at pulling it out of the main ServiceStack repo in a stand-alone repo with a weaker copyleft OSS license, but it would require a bit of work and would need to ensure it's not disruptive to existing ServiceStack Customers, I just didn't expect there to be any issue for a gratis library that's also OSS.

Incidentally the ServiceStack.Glue library that the Desktop Apps use to embed .NET Core Apps in a Chromium Desktop Shell is MIT [3].

[1] https://sharpscript.net/docs/sharp-pages

[2] https://github.com/NetCoreApps/TemplatePages

[3] https://github.com/ServiceStack/ServiceStack.CefGlue

In case you haven't worked at a larger company before:

- nonstandard license = legal will have to review license

- AGPLv3 is a non-starter at many places

AGPLv3 software is used in some places, but projects normally license the pre-compiled binaries under more permissive terms. Example: mattermost is AGPLv3 but the binaries are MIT-licensed https://github.com/mattermost/mattermost-server/blob/master/... so it'll be easier to get approval to use the binaries.

I'm sure SharpScript is a cool technology, but some of your licensing choices really hamper adoption.

As I've said above, only OSS projects that create custom builds from source use the AGPL/FLOSS license, the license was added to allow OSS projects to use all of ServiceStack without needing to pay for a developers license.

All other usages of ServiceStack from its official NuGet packages are only available under its commercial license which only requires a paid developers license for its commercial products that contains free-quota usage restrictions [1]. The rest of ServiceStack, inc. all core and client libraries like ServiceStack.Text, ServiceStack.Common (containing #Script), ServiceStack.Client, etc are all unrestricted libraries that are available to use graits/for free.

[1] https://servicestack.net/download#free-quotas

So you are saying the lawyers have to approve the "ServiceStack License Agreement". The probability of this may be within an order of magnitude of likeliness as getting approval for the AGPLv3.

https://www.nuget.org/packages/ServiceStack.Common/ -> "License Info" -> https://servicestack.net/terms

Right they'd approve the commercial license just as they would with every other commercial product they're using.

> which is probably in the same order of magnitude of likeliness as the AGPLv3

It's disingenuous to claim the commercial license is the same as the AGPL, the commercial license allows usage in closed-source programs, AGPL does not.

Sorry if my wording was confusing... my claim is that the likelihood of a sign-off from the lawyers was similar, not that the licenses were similar.

In both cases the license serves as a bump in the road that doesn't need to be there. ScriptSharp seems like an awesome piece of kit.

Why do you find it surprising people are confused when:

On the one hand you state "All other ServiceStack Software inc. all client libraries, inc. Serialization and ServiceStack.Common (containing #Script) are unrestricted libraries which can be used for free without a commercial Developers license in both commercial/non-commercial projects"

On the other hand your terms state "Subject to the terms of this Agreement, Licensee is granted a right to use the Software for small projects and evaluation purposes without charge provided that use of the Software is within the "Free Usage Quota" published on Licensor's website at servicestack.net."

"small projects and evaluation" is not free to use without restriction.

You're referring to different things where you've quoted me out of context [1], and have omitted where I've specifically said that only the commercial products have free usage quotas [2].

All the packages I've listed do not have any free-quota restrictions so they don't require a paid Developers license to enable unrestricted usage, since they already don't have any restrictions.

[1] https://news.ycombinator.com/item?id=20756148

[2] https://servicestack.net/download#free-quotas

OK, but that's not what the license linked to from the package page says. It doesn't say "Some products are unlimited use, and others are restricted as stated here". It says all products are restricted as stated there. It does not discriminate between commercial and non commercial products.

> All the packages I've listed do not have any free-quota restrictions so they don't require a paid Developers license to enable unrestricted usage, since they already don't have any restrictions.

How does that line up with your license that states "small projects and evaluation" only?

I'm not doubting that your intentions are for the licensing to be as you state, but that's not what your license says :)

> It says all products are restricted as stated there.

It does not say this, it says:

> Licensee is granted a right to use the Software for small projects and evaluation purposes without charge provided that use of the Software is within the "Free Usage Quota"

The free usage quotas only exist on the commercial products which I've already linked to https://servicestack.net/download#free-quotas

On the free products pages, like ServiceStack.Text product page [1] and GitHub project page [2] and #Script home page [3] all specifically mention they're free to use. Whilst all of ServiceStack's non .NET libraries like the JS/Typescript clients [5], Swift [6], Java/Kotlin [7], Dart/Flutter [8], CefGlue Support, etc are all published with liberal BSD/MIT OSS licenses.

[1] https://servicestack.net/text

[2] https://github.com/ServiceStack/ServiceStack.Text

[3] https://sharpscript.net/#free

[5] https://github.com/ServiceStack/servicestack-client

[6] https://github.com/ServiceStack/ServiceStack.Swift

[7] https://github.com/ServiceStack/ServiceStack.Java

[8] https://github.com/ServiceStack/servicestack-dart

[9] https://github.com/ServiceStack/ServiceStack.CefGlue

Surprised? Let me give you my perspective on this whole thing.

I was almost sold on sharpscript for handling our email templating needs until I realized how obfuscated the licensing and overall project structure is. I've been reading through threads about it on HN for 2 days now, and still don't have a clear understanding of what the real intentions are here.

If I just follow the rabbit hole from the #script nuget.org page:

https://www.nuget.org/packages/ServiceStack.Common

I wind up at the following license URL:

https://servicestack.net/terms

Which has the following:

"Use of the Software and Documentation is subject to the restrictions contained in this Agreement. ServiceStack, Inc. grants you a non-exclusive, limited, non-transferable, freely revocable license to use the Software. ServiceStack, Inc. reserves all rights not expressly granted herein in the Software and the Content and may terminate this license at any time for any reason or no reason."

I will not be using this software. If anyone wants to change my mind, pull sharpscript into its own repository, give it its own nuget, and post crystal clear license terms alongside each which do not contain any sort of legal backdoors where you get to rip the rug out from under me at some arbitrary point in the future. If you want money for this, just ask for it up front and be honest with your intentions. I may actually consider purchasing a license if the terms aren't trashy like in the current license above.

I was about to post that exact quote.

"may terminate this license at any time for any reason or no reason"

How could anyone build a business on this?

Sure, you shouldn't use anything you don't feel comfortable with. That clause is common in other commercial Software license agreements, e.g. Xamarin originally had the same clause before they were acquired. IMO it's a good deterrent to protect against bad actors from suing us, and why it was included. Fortunately we've never had a bad actor sue us to ever need to test it in courts.

As mentioned in my parent comment you've replied to, I'll consider pulling it into its own repo with a liberal OSS license, but it would be a lot of work since it's included in a core library and any changes can't disrupt existing Customers already using it. But wont be anytime soon as I'm already overloaded with other higher priority features I have to work on.

> I may actually consider purchasing a license if the terms aren't trashy like in the current license above.

I've no intentions to ever sell any licenses to use #Script, it will always be free.

ServiceStack is one of the best pieces of software I have ever used and saved me from WCF/WSDL hell back many years ago. Just the breadth of detail in the release notes shows that Mythz puts a lot of thought and effort into designing features. I just wish instead of Aspnet core MVC they would have just made SS the web framework.

This is the first time in a while I've seen something that really gets me excited about software.

The promise of "run anywhere" has more or less been fulfilled by the web, but it leaves a lot to be desired: shared code is duplicated on every site, the only language available has... quirks to say the least, and performance is always an issue. This seems to solve a lot of these problems, while usable webAssembly is still a long way off (and doesn't resolve all the issues above).

I have seen lots of cool stuff from MS wither on the vine. Hopefully this does a little better.

> the only language available has... quirks to say the least, and performance is always an issue.

I see this a lot, can you point out which quirks still remain in modern JS? Performance is quite fast with today's modern JIT VMs.

Why is .net core not taking the world by storm ? Because most 'real .net devs' still work on .NET 4.x legacy windows apps.

I don't know, this is only my personal experience but every time I check .NET related stuff some Windows or Visual Studio related thing pops out and I think "nah, it's not worth it". Not to sound negative but I can't really understand why they can't make their documentation platform agnostic like every other project on the planet.

Coming from a Java background, I'm currently a big fan of .NET Core. The C# language has a bunch of nice features, the ASP.NET Core stack is nice to work with and I have JetBrains Rider so I don't ever need to touch Visual Studio.

The recent Visual Studios are actually pretty great, so far ahead of Rider.

I completely understand this perspective. It is, however, completely possible to use .Net without Visual Studio once you understand a bit about and solutions.

Especially .Net Core's dotnet command is a wonderful tool that allows you to do basically everything with it - it can run, compile, even run tests - completely on the command line.

.Net documentation is however VERY crusty in my experience - all the fragmentation and outdatedness can very well lead to you accidentally reading and trying documentation that is 3 major changes behind, for a library version that has long been replaced. Nowhere will you find any warnings. That is hugely frustrating.

Visual Studio itself also makes a very broken impression to me, although admittedly it appears to improve.

Not sure whether that's going to be enough to keep Windows or .Net alive in the long term, since even Microsoft is moving to embedded Web apps now, abandoning their own 3 different UI solutions they have been pushing in the last 20 years (completely ignoring the 3rd party efforts like platform.uno, which they could probably acquire quite easily - seriously: Xamarin, but not this?!).

It will be interesting to see what happens next year when .NET 4.x becomes a dead end and Core (renamed Net 5) becomes the only version.

It would hardly be any different from those servers running Red-Hat Enterprise 5 in production.

Yep I know of a few places doing it.

.Net 4 is a Windows component and is supported as long as the operating system is.

https://support.microsoft.com/en-gb/help/17455/lifecycle-faq...

That would be weird. My company migrated to .NET Core 2 years ago.

My personal opinion is that Microsoft's absolutely terrible naming scheme fails to sell anyone on why it's different or important.

Edit: can anyone give me the one-paragraph rational for why Net Core should take the world by storm? C# is a nice language and I'm a mostly happy VS user (except when I have to fiddle with MSBuild), but why should I go in and change the dropdown from ".Net Framework 4.5.2" to ".Net Core"? Let alone why any user of, say, Python or Node should drop everything and come over to C#.

As someone that has been on and off .NET since the pre-release days (thanks to working at a MSFT partner back in the day), the constant reboots from the last couple of years, and breaking changes across .NET Framework and .NET Core (e.g. WCF, EF 6 tooling), inspire a wait-and-see attitude among a large majority of us.

Absolutely this. They changed names, project format, build tooling, etc faster than the ecosystem could keep up. You couldn’t even be sure there existed a set of compatible ASP.NET Core, EF, and standard library packages in nuget without endless trial, error, and binding redirects.

I tried 2-3 times up to and including .NET Standard 2.0 to switch and got burned by busted tooling and package conflicts every time. I’m starting a new project now and am still wary.

Nuget conflicts is still a big issue IMO.

One of the major pains of my life as a .NET dev who does .NET core right now is Nuget and binding redirects!

If you stick to the LTS releases, especially v2.0 and above, everything is very solid. It always best to wait for version 2 anyway with MS projects.

That doesn't solve the problem of porting code that has dependencies on libraries that only work with .NET Framework, and will die the day .NET Framework 4.8 reaches EOL.

Oh yea, absolutely. I've become weary of trying new Microsoft stuff. One example I had recently is with their Bot framework. They came out with a shiny new template earlier this year, they called it the Enterprise Bot Template. Since we were gonna build a bot, we decided to use this, because it was a nice template with all the best practices and lots of features included. Now that we are finished with the bot, I tried to look up the documentation that explains how to deploy it. Guess what? Documentation is _deleted_. Completely gone. Turns out they have already discontinued the template and have yet _another_ template in place, that's only been around for a few months. Of course many things are/work differently, so migrating is a pain. And there is no good migration guide. They basically just say "create a new project with the new template and make all your code changes there". It's infuriating... At least keep the old documentation only, don't just delete it.

Tip: A good part of microsoft documentation is now hosted on github... you may want to have a look at the revision history there and try to find the deleted docs this way (for example this is the repository for azure bot: https://github.com/MicrosoftDocs/bot-docs/tree/live/articles ).

I'm a .NET developer with 5 years of experience, mostly in the enterprise space. I've worked on large projects with .NET 3.5 - 4.7, and recently I've been building things in .NET core.

Honestly, .NET core makes a lot of sense for new projects that need to be highly scalable. If you have an API service that's hosted in a cloud provider, or a tool that generates PDFs of items, or a tool that scrapes API data and chucks it in a database, then this is great. These are simple applications that do not need an awful lot of authentication, crazy UI frameworks, or other windows-only features.

The code itself runs faster [1]. It might not matter for business / CRUD applications, but that's a nice to have thing.

The biggest selling point is cross platform support. Now, I don't care if the company switches from Windows 2016 VM's to some variation of RHEL. My code will work on that too. This gives your organization improved flexibility and reduced technical debt.

If you have a big legacy application using .NET Framework, it's probably not worth rewriting it for .NET Core. You will run into package conflicts. I have had to rewrite ".NET Framework only" pacakges to support .NET Core. That will throw your estimates off and probably delay the project. And that becomes really difficult to justify to project stakeholders.

[1]: https://www.ageofascent.com/2019/02/04/asp-net-core-saturati...

.Net Core is the future: It is clearly the .Net runtime environment Microsoft are putting their weight behind to eventually make it the standard.

Besides this future perspective, the real benefit from it you have today is that your project will (unless it uses Windows APIs, which is unfortunately way too common) instantly run on Linux.

> My personal opinion is that Microsoft's absolutely terrible naming scheme fails to sell anyone on why it's different or important.

This is why it is very interesting that the next "Core" release is to be called ".NET 5". No more "Framework", no more "Core". Simple version math applies: .NET 5 > .NET Framework v4.6.8 && .NET 5 > .NET Core 3.0. Maybe it will be less confusion all around, hopefully, soon.

In all fairness, .net core 3 is the first version of .net core that is really useful and will feel other than some sort of public beta. It will be interesting to see how .net core 3 succeeds.

That's been my opinion for a while too.

Some of the .NET core stuff is pretty neat for basic demos to show off the tech. But for actual enterprise stuff I've so far found it really frustrating to work with.

Douglas Coupland's mid 1990s novel Microserfs makes mention of a popular belief at the time that one should always wait until the 3.0 release of any Microsoft product before making serious use of it. Guess somethings don't change.

I haven't given net core 3 a trial yet but will use serial ports as my initial tests. In the 1.x and 2.x versions the serial port support was not up to the same level as the net framework.

Having worked as a .NET dev for the better part of a decade, it's a mixture of things:

1. The cost of moving a standard .NET application to .NET Core. If the benefit is there, it'll happen, but for established code bases I don't see why they'd bother when standard .NET works fine.

2. On the web side of things, many of the big content management systems aren't on .NET Core yet. Umbraco is the king of CMS's on .NET, and once they pull their finger out and focus on .NET Core I think we'll see a wave of developers moving to Core.

3. For general web stuff, there isn't a solid reason for people to move from the likes of Ruby, PHP, and Python to C#/.NET Core.

4. There's still a perception that .NET Core is a WIP. That's understandable, considering .NET has been battle-tested for decades, and .NET Core is still (relatively) new to the party. There was also the csproj issues from a while back, and that set off a few people from fully switching.

5. The naming has confused everyone, so the safe option is to wait for everything to sort itself out. .NET isn't going anywhere just yet, and the switch to .NET Core won't be a huge one for those that have had to adapt to new C# and .NET libraries over the years anyway.

6. Having to be the one to explain to the boss that .NET Core exists in the first place

In all fairness, it's no different to any other major iteration of a framework. I imagine that a lot of Ruby developers will be telling their bosses about Rails 6, and trying to push towards it for multi-db support for large applications.

The big difference for me is that many .NET shops rely heavily on certain libraries and tools, and many of them are very slow to adapt. Umbraco, as a prime example, recently upgraded to Angular 2 for its admin section, and is probably a year or two away from an initial move to .NET Core.

Because we don't trust it. They keep changing the framework, the naming, the tooling, and whatnot. I have no time for this shit. .NET as we know it is rock solid and I have no intention of moving on in the foreseeable future.

I work for a large company that uses .net. we are slowly moving .net core in little bits. These things take time.

    > Because most 'real .net devs' still work on .NET 4.x legacy

That may be true, but .net core is definitely aiming to increase adoption and it makes a compelling case. The new stuff is a pleasure to use.

I almost wish Microsoft would stop putting much effort into dead ends, however. It's going to be possible to use WPF and even Windows Forms after .net 5 transition (they'll be windows-only libraries). VB .NET is still kicking (just let it die already). I wish they would have folded all those person-hours into .net core stuff instead.

What's the not-dead end way of making GUIs in .net core supposed to be?

For Windows, .Net Core 3 lets you create Windows GUI apps using the standard Windows frameworks (UWP/WPF/WinForms)

https://devblogs.microsoft.com/dotnet/net-core-3-and-support...

For cross platform there isn't an official solution, the closest would be deploying as an Electron app.

The official cross platform solution for GUI apps is Xamarin / Xamarin.Forms, though they are mostly focused on mobile. There are desktop renderers for those, but they are currently in some weird Schrodinger's Cat state between "officially supported" and "community supported".

There are other entirely community-supported/third-party efforts like Avalonia and Uno around as well.

And Qml.Net

https://github.com/qmlnet/qmlnet

All Microsoft GUI frameworks are dead ends, whatever is the current recommendation will be replaced within a couple of years and the old stuff will be left to rot.

It may change with the shift to open source but I'm not holding my breath.

UWP XAML has lasted more than a few years already and is quite actively developed, with some pretty big updates on the horizon. While there are many roads to UWP XAML (including UWP XAML Islands now), and those have shifted over time, the core has remained quite steady. (Which is to say that it hasn't been immune to tech debt churn of small little backward compatibility breaks that need migration every minor version or so, as all frameworks in the modern era seem to.)

The last GUI framework they entirely "left to rot" was Silverlight, and that was a) almost a decade ago now, and b) a fellow traveler in the XAML space where migrations were quite possible, if maybe not always easy/convenient, back to WPF or forward to UWP.

With the weeding of some of WinForms and WPF in recent .NET Core work, and the addition of XAML Islands, even what were the dead ends don't necessarily look so dead today, or at least not so rotten.

Four years. But Microsoft have already acknowledged it's a dead end and are encouraging win32 apps into their store. Even the Wikipedia page refers to it in the past tense. Also wasn't there talk of a new UI kit at the last Build event?

WinRT released in 2012, so UWP is 7 years old. Yes, the UWP name/brand is younger than that, but the tech stack has been continuous, with strong backward compatibility.

Microsoft may be encouraging Win32 apps in the store, but is clearly saying that Win32 is undead and they'll continue to support the zombie and stop trying to kill it. They hope people will move on and they are providing more tools than ever to help migrate from Win32 to UWP. It's now a much more nuanced migration rather than a forced all-or-nothing conversion.

Wikipedia pages refer to everything in the past tense. That's the encyclopedia tone they require.

The closest thing to a "new UI kit" announced at the last BUILD was the ground up rewrite of the Windows version of React Native to make it "extra-Native". That change is from UWP/C#/XAML to UWP/C++/XAML. It's still JS controlling UWP controls, it's just using C++ to glue together the controls rather than C#/.NET.

The next closest announcement to a "new UI kit" was that way more of the UWP UI stack (almost all of it) is being "lifted and shifted" out of being directly inside the Windows codebase and deeply coupled to Windows releases and being moved in the WinUI library. WinUI has always been the parts of the UWP UI shipped outside of Windows Releases. UWP is moving to a model where they want to have as much as possible inside WinUI rather than inside Windows to make it easier to ship UI controls updates to application developers without so much of the rigmarole of "this control will only be in Windows 10 19H2 and later" making it easier for developers to use the controls "now" rather than waiting for a future Windows feature update and less headaches between what is in a current LTS feature update versus most current feature update.

(The next closest announcement after that, was that the Fluent Design team was merging the design efforts of what they've been doing for UWP/WinUI and what the Office team has been doing for the Web in the Fabric libraries, moving Fabric to being much more "Fluent Web". It should not be a surprise that the web is important to Microsoft's UIs.)

The "new" UI kit (WinUI) is the one from UWP, it's just being decoupled from Windows releases

https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...

VB.NET is pretty much alive in many life science enterprise shops.

It is their escape route when they outgrow Excel/VBA.

WPF and Windows Forms work today (Windows only) in .NET Core 3.x.

In my case, I'm waiting for EntityFramework to catch up before switching most legacy applications over.

I've been using standard 2.0 for new projects since it became available and building for dual deployment, either with Heroku or as a Windows service.

There's definitely a crowd of .net devs that doesn't care. They're probably not the ones on HN though. I've been holding my breathe waiting for all the libraries to catch up. We're so close!

I actually moved to .NET by choice for the Nemerle language a long time ago (C# mostly caught up, so I switched over). I might not be representative of everyone, but there's at least a subset of developers eagerly waiting on some small thing which will let them make the jump.

EF Core has caught up a lot in 3.x. It's LINQ support is now possibly better than EF ever was, especially with the move to the new "throw an error if the query provider can't do it" model where "downgrades" from SQL to in memory operations must be explicit now (such AsEnumerable() calls).

EF (not-Core) 6.3 has also been finally ported to .NET Core (though I think it is still considered "Preview" quality) which should be directly plug and play for some types of legacy applications (Microsoft seems hopeful it will mean more WinForms and WPF apps will just run on .NET Core now).

I'm waiting for EF6 on .NET Core, just as you said. Once that's successfully working, and I've got all the web stuff updated to latest, then I'll look at moving EF to its latest version as well. That part scares me a bit more however, as we have hundreds of databases being managed via EF6 migrations, all at different versions (based on customer maintenance payments). We'll need to keep EF6 as a dependency as long as we want to keep updates simple and have older versions in the wild.

Currently it is just another language - for me one of the real compelling cases of working with .NET was the absolutely god-tier integration of tooling for creation UI kits (that is aside from the very good case that C# is a language that is superior to anything else I've professionally worked with, that's not an argument that will sway anyone). Such an argument doesn't exist for .NET core, because it suffers from the same problem as every other contender: Creating a cross-platform GUI is an absolute cancer and is by far the biggest problem you'll have writing code. That being the case, why switch?

Actually, they are not making a cross platform GUI. They're simply supporting in NET Core what they have done so far in NET Framework - but only if you build for Windows.

.NET has already taken the world by storm if you consider actual usage. It powers software for the Fortune 500 and millions of small businesses. It lets you build desktop apps, websites, frontend SPAs (Blazor), mobile apps (Xamarin), backend services, and games (Unity).

There's no need to rewrite working .NET Framework apps, but .NET Core has seen massive uptake with cross-platform development and runtime, incredible performance, and interoperability with just about every other common open source languages and projects.

'the world' is not people already using another flavour of c#.

Why isn't .NET taking over from python/node-with-typescript projects?

Probably because the crowd that mostly was on. Net is the one in enterprises and they're not going to migrate legacy apps anytime soon. Seriously, other than stack overflow and maybe Ms owned properties, does anyone remember any other large scale site that was on. Net?

IMO, that means that. Net was never targeting the early adopter market. Ergo, their new platform, which is just different enough, isn't probably having many adopters. Secondly, having to wait for libraries to catch up is probably a real reason initially (till.net standard 2.0?) But that just meant when slower adoption.

Add to this, to maintain cross platform tooling, they're now have cli first tooling and flux around fileformats. That imo, made a lot of the traditional .net shops uncomfortable.

I've jumped b/w .net and Java and very comfy with Linux. Last few years have been. Net and .net core in prod. after 2.0+, it's been absolutely wonderful. Great language ergonomics and I can finally ditch vs for vs code. 3.0 is only going to make it better

But then, I'm probably far from the representative .net dev here.

Reply on news.ycombinator.com