.NET 6 Released(devblogs.microsoft.com) |
.NET 6 Released(devblogs.microsoft.com) |
Yesterday, while randomly googling for "hot reload" I got aware of the drama which went down around two weeks ago, when Microsoft decided to remove this feature from the release, even after including it in the previews.
Here is a good summary https://www.youtube.com/watch?v=L9_pzDjw9HQ
Looks like they have walked this back, and Hot Reload for CLI (and thus, tools outside full the Visual Studio IDE) is here to stay. For now.
https://devblogs.microsoft.com/dotnet/net-hot-reload-support...
From what I read, it doesn't yet support stuff like async/await, LINQ, lambdas (and few other things). And those are used a lot in modern .NET apps.
Still a great improvement in the right direction.
This is a great! Now I can publish statically linked executables and run it everywhere. I don't have to tolerate Golang and its quirks just to have cross-compilation and static binaries, even though they will be larger in size.
$ dotnet new console -n HelloWorld
$ dotnet publish --project HelloWorld -r osx-arm64 --self-contained -o out -p:PublishTrimmed=true
$ du -sh out
10Mhttps://www.joelonsoftware.com/2004/01/28/please-sir-may-i-h...
.NET 7 will work on NativeAOT for instantaneous startup of especially smaller apps, but I think they’ve already optimized JIT warmups or something — I was pleasantly surprised when I just wrote a .NET 6 console app that read JSON from a server.
One thing though, is that native .dlls are still outside (DetoursServices.dll for example in BuildXL). But still pretty impressive what it can done. That, and the new embedded .pdb (for .NET only, e.g. not native).
I wish "publish" was used more by the place I work for (most of the folks would simply Release (F5) and store what's there in p4). I've only recently discovered about "publish" and that is after haven't worked with .NET for so long...
I might be ignorant here but if you're not specifically pointing out what version DLL's you want, aren't you in fact publishing a dynamically linked executable instead of a statically linked one?
Doesn't these single-file apps rely on the GAC?
I'm a novice at Golang, and I dislike much of the language, except that it's fast and can produce small binaries.
But it's funny how the infographic in the post mentions MAUI for desktop development, but the "desktop" keyword in the text is referring to the WinForms github repository. I can't think of a more concise statement about the state of GUI development on .NET. I would really wish for less fragmentation and churn in that space.
This is the first thing I look for in these announcements. .NET 6 is the successor to .NET Core 3.1.
Which is not far from say Ubuntu LTS at five years. (Python and Ruby have more confusing security fix policies than LTS/stable designations, but both are relatively close to the 3-5 year mark for security fixes.)
Definitely not "long" from the perspective of classic Enterprise development (or Windows "LTS" lengths), but from modern viewpoints it is "long". Interesting how such things shift culturally.
I'm excited by having these built in. I always found it awkward to need to do: `.GroupBy(item => item.Property).Select(group => group.First())`.
https://devblogs.microsoft.com/dotnet/announcing-net-6/#syst...
So without already being in an existing Windows-based Microsoft shop, is there any reason I should be interested in .NET today?
I've been on .net since 1.1 and .net Core since 1.0 and this statement makes me so confused.
Core lives _inside_ of .net 6? Is there a non-core ASP.NET that also lives inside that framework?
I thought .net 5 was where the legacy 4.x branch and core 3.1 was married in holy matrimony, minus the worst of the legacy garbage.
Perhaps this is indicative of the larger Microsoft ecosystem, but it feels like my peers at university and in the industry tend to stay far away from .NET for personal projects, etc.
Why is this?
In any case, the performance results were really outstanding (particularly vs Mono) especially given we use C++ for many performance sensitive areas already. Looking forward to upgrading to .NET 6 in the coming months.
Great work! Congrats to the .NET team!
Interesting. Do you have measurement results? According to my measurements the difference is not that big, see https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor..., especially the section Update September 15th.
I am wondering about jumping from relatively large codebase in .NET Core 3.1 to 6.
Even those of us who are actively migrating applications are stuck with web forms, netfx and dotnet core 2/3 and will be for years, so it would be nice that we felt some love rather than being left behind.
MS are starting to feel like Apple where you only have value if you can keep up.
Edit: Though I saw something this morning when I tried to load an f# project I made in VS refused to load even though the new ones generated with Rider are fine...
Rider feels so much faster than VS, and is rock solid - these were my 2 main reasons for switching from VS.
Rider is not perfect, but in many ways miles above Visual Studio.
As Rider doesn't have any Forms editor build-in (AFAIK), I am slowly switching most of my views to fully code, so I don't need to rely on Visual Studio's visual layout editors anymore.
https://www.jetbrains.com/help/rider/Working_with_Windows_Fo...
I noticed for a time that some projects created in rider had a different project type than those created in VS which caused some issues at my company. Was a simple change to the proj file though.
Do you mean Visual Studio? They don't share anything AFAIK
I just wished more startup are using it more as their tech stack to improve the ecosystem to be on par with Java. Almost every big tech companies are always using java now it's just hard to use .net when you won't get a job that doesn't suck
There's also a 40 page e-book ".NET for Java developers" here: https://aka.ms/dotnet-forjavadevs
I can, however, recommend you use Rider as your IDE. It includes JetBrains' excellent ReSharper code analysis tool, which actually corrects a lot of your generic OO code and will automatically rewrite it for you to be more idiomatic (avoiding memory and performance issues, for example). Rider knows the sharp edges so you can mostly forget about them.
Otherwise it should be very easy for you to pick up. .NET has some annoying code organization conventions (lots of subprojects, too many folders, etc.) but you can just structure your project however makes sense for you and avoid all of that.
If you feel like you really need a book, this one is good: https://www.packtpub.com/product/c-10-and-net-6-modern-cross...
https://docs.microsoft.com/en-us/aspnet/core/?view=aspnetcor...
I like JS as a language and the enormous progress thats been made in the JS ecosystem from the wild west days back then. But I have to say my most productive and enjoyable dev experience was with VS, C#, ReSharper etc.
Magical intellisense and real refactoring across millions of LOCs and multiple assemblies, all kinds of tools, visual designers, powerful 3rd party toolkits (anyone remember Infragistics), amazing docs. And of course now it'd be much better I'm sure.
Finally! :)
I was a bit disappointed that MS didn’t want to support macOS arm64 natively with .NET 5.
At the same time Microsoft invested a lot of effort in porting Java to arm64. Almost a year ago I could download Java builds for macOS arm64 from Azul (java 8-latest).
I wonder when, that could mean 2022
https://devblogs.microsoft.com/dotnet/update-on-dotnet-maui/
for instance, the F# example from https://fsharpforfunandprofit.com/posts/designing-for-correc...
can be done in C# like https://gist.github.com/keithn/ceeeed5f7eb567e1b2333747065d1...
almost similar amount of code, however, no exhaustive checking. Not that I find that to be much of a problem, but it would be nice
But honestly, with file scoped namespaces and global usings ... there is enough to see.
(We have a lot of .NET Framework libraries, shared between different applications, and a complex dependency graph between them. So I'm wondering if it is possible to migrate away from .NET Framework by starting with the executables and working our way down the dependency graph.)
[0]: https://docs.microsoft.com/en-us/dotnet/core/porting/third-p... [1]: https://docs.microsoft.com/en-us/dotnet/core/porting/#net-fr...
You have to be careful though because you could get runtime crashes if they try to access stuff that is not supported in .NET 6 (mostly Windows-specific libraries).
I'd recommend running this guy on the code base, it'll give you a good idea of how much a pain it will be: https://docs.microsoft.com/en-us/dotnet/standard/analyzers/p...
Those use a common API subset, and are a stopgap to make migration easier.
The only thing we miss is system programming due to not being able to opt out of using the garbage colector.
I built a couple of side-projects and startups - all on .net.
First one was on Xamarin even before it was bought by MS - the progress from that times is amazing, the last one - built fully on Blazor.
I believe more startups should try to adopt .net stack - it's fast, fun and efficient and becomes better every day.
Congrats .net teams on launch
For instance, in WPF applications: https://docs.microsoft.com/en-us/microsoft-edge/webview2/get...
https://devblogs.microsoft.com/dotnet/announcing-net-maui-pr...
Unless it gets rebranded again before it's usable.
https://github.com/chromelyapps/Chromely https://github.com/webview2/EdgeSharp
Good to finally have an official version!
AS a longtime original VB/Winforms developer - MS lost their mind on desktop development and didn't look back.
They chased EVERY fad that could be chased. Silverlight, UPF, XAML, WPF, Islands, MAUI. This is one of those things - imagine if they'd focused on building an amazing and cross platform (ultimately) toolkit with just a basic drag and drop designer? Who cares about "styling" your app and all the rest of the garbage.
How many lost years and peoplehours?
I've got to the point where I don't trust them on any of this stuff. I target WinForms and if they ever decide to kill that then I'll abandon the platform completely.
>Who cares about "styling" your app and all the rest of the garbage.
One of the problems with WPF is the lack of styling of the standard controls. It takes a lot of work to ensure your app doesn't look like a turd.
Kinda joking, kinda serious, but all the Microsoft UI changes in the last 10-15 years have definitely helped enterprise IT adopt internal web applications. :)
Get rid of it.
Being a wise man I spared myself from this madness long time ago;) When I need Windows Desktop App I use Delphi or lately Lazarus that can do both Windows and Linux GUI from a single source and produce native standalone executables.
I will never bet on any new MS desktop development framework anymore . It’s either WPF or preferably web (even Electron) for me.
There's Uno, Avalonia, Xamarin Forms, and MAUI, all cross-platform. I think it's a mess no matter what.
Even if you want to use the latest and greatest UI, your customers need to keep up too. Completely unworkable.
There are very few applications that simply cannot work in a web browser in 2021. Even accounting for all the inconsistent bullshit between browser vendors, you can still arrive at something that works as far back as IE6 if you are conservative with your footprint.
Do you really need flexbox, webgl2 and GPS navigation for that warehouse inventory management application? Does everything have to live the various app stores? Will your users revolt if there isn't some ceremonial download & install phase of using your product?
I would go so far as to argue for deployment of a self-contained webservice to the end users that could be accessed via any arbitrary localhost browser before succumbing to the Microsoft Desktop GUI framework du jour.
Might as well use Unity game engine and write your app inside one.
It looks mature enough now, and has a better chance of being still useful in 5 years from now than WinUI or MAUI or whatever is the latest GUI tech MS wants us to use.
I am basically stuck on .net 4.8 because of that.
* Great performance - https://www.techempower.com/benchmarks/#section=data-r20&hw=...
* Open source - Microsoft has made a lot of missteps but they have came a very long way. The bright side is both how far they've came & the outcomes of the recent missteps.
* Very productive toolset imo. I focus mostly on web based tech though. I really like the syntax & type system.
* Swiss Army Knife in that you can use .NET to do just about any type of project - Web (front & back end), mobile, games, IoT, desktop, machine learning, etc.
* You can use C# & F# syntax, both very popular (though let's all be honest, F# is a 2nd class citizen in .NET but it's got a great fan base)
It seems to be keeping up with the broader .NET ecosystem pretty well I think - (https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/). In some ways it is ahead of C# as well so I wouldn't say it is behind at all.
For internal admin tools I can throw together a windows form app in C# much quicker than any other system I've worked with. I'm pretty new to the eco system so to it's amazing how fast you can get up to speed.
Microsoft has done an amazing amount of work writing and rewriting code to make cross platform open source .NET a real thing. All open licensed and developed in the open.
It's fitting you mention all the work Microsoft has done rewriting code. You're talking about .NET itself but I'm talking about the ecosystem, where Microsoft often does take others' projects and release their own version (the Windows package manager comes to mind), training the community to only trust things that come from them. Of course there was the recent famous example of Microsoft deleting public code so they could feature it in Visual Studio, but this tweet is typical of the attitude I've seen from the community: https://twitter.com/GeoffreyHuntley/status/14540569884432179...
Toplevel programs should make it easier to experiment with C# if you're interested. We also have first-class support for C# commands in https://ab.bot if you just want to play around with the language and make a fun Slack bot or something, although it might take us a week or so to get move up to .NET 6.
Shudders at memories of coworkers writing giant, ridiculously inefficient LINQ queries without understanding how it's actually using the database and what it's doing server-side
> Toplevel programs should make it easier to experiment with C# if you're interested.
Definitely interested in that small feature :) If I had extra time I'd like to see what it takes to brew install dotnet and write a simple CLI program. Can .NET deploy a static binary nowadays?
There is no killer feature for .NET I think. That's why it's a hard sell. I think its sales pitch is more or less parallel to Java (though I prefer C# to Java and VS to IntelliJ).
Do you want a statically typed, extremely fast, cross-platform language with a comprehensive standard library and huge ecosystem of 3rd party packages with almost unrivalled devX (Rider on non-Windows OSes) and streamlined packaging and deployment that allows you to scale from single person PoC to large team development within the same codebase with no additional overhead?
I'd note that it's a bit of a jack-of-all-trades when it comes to desktop and ML. The ML.NET package keeps getting better but for those areas where there's an obvious standard, e.g. Python for ML, you may as well use the standard for that thing. The desktop story continues to disappoint and I'd advise people to steer clear of desktop unless they want a nasty surprise. But for web applications I'd not want to use anything else.
And that's why developers and companies like it. It is a good, easy to use, well supported, well documented, sane jack-of-all-trades.
The .NET Core ecosystem was a lot sparser back then but picking up the language was actually the most pleasant "learn a new language and be productive in it" experience I've ever had, and I don't think I'd ever turn away from it now. YMMV, of course, depending on how much you like whatever you're writing in now.
I can tell you why the company I work for uses C# to develop microservice based products:
-cross platform
-tons of libraries
-integration with most of the things we need
-great speed
-good productivity
-great tools
We can iterate fast, have performance. Also, C#/.NET is good for other purposes such as mobile apps, frontend, writing glue code, and even desktop if the need arises.
Could you expand a bit on that?
I used .Net 1.1 and 2.0 for awhile, and coming back to it now while deciding the future path for our application.
I've heard the more recent releases of .NET have been pretty good, but I don't see any real reason to be interested in it. There are already plenty of good options out there.
Outside of a few areas related to DDD, event sourcing, and some distributed-system frameworks (NServiceBus and MassTransit) there's really no killer app for .NET, in my opinion.
The big selling point for .NET now is that it runs on Linux...which is not really a selling point in the grand scheme of things.
Blazor is an excellent C# on the browser stack.
And MAUI will target React Native (native controls) and Cordova (Blazor on Maui) at the same time ... which is extremely powerful. But that is half a year out.
.NET has a lot to offer if you take individual app models of it. If you want to stick in one language, it is even a top contender.
Linux selling point is already gone. That is standard already for 5 years now.
Yep!
> I thought .net 5 was where the legacy 4.x branch and core 3.1 was married in holy matrimony, minus the worst of the legacy garbage.
.NET 5 was the next evolution of .NET Core. There was no great merging of legacy .NET Framework into the .NET Core branch or something like that. It saw a bunch of foundational stuff land in so that .NET could support modern client apps from Xamarin and further support the modern versions of WinForms and WPF.
If that sounds confusing, it kind of is. But it's a clear branding effort - .NET is not a choice between the "slim .NET Core" and the "big .NET Framework. It is either .NET or the legacy stuff (still called The .NET Framework).
There was a brief period of time after I recognized that .NET really works on all platforms without proprietary stuff and before the `dotnet watch` desaster in which I was at least curious about .NET. But even then I never fully figured out how .NET, .NET Core, ASP.NET, .NET Framework, .NET MAUI and the kitchen sink relate to each other.
If the purpose of branding is to make something recognizable, Microsoft consistently fails across the board with me.
No, the "non-Core" ASP.Net framework is not ported to the .Net Core platform (i.e. .net 5+). Only ASP.Net Core runs on .Net Core.
This is unfortunate, because it means older web sites based on the classic ASP.Net does not have clear migration path to .net 5+.
Only remaining confusing part left in ecosystem is "ASP.NET Core", because even though .NET got rid of Core, latest version ASP.NET didn't
Perfectly clear and reasonable.
There is .Net Core, which was a rewrite of the .Net runtime to make it platform independent.
Then there is ASP.Net Core is which is a rewrite of the ASP.Net web stack. Despite the name, this was not initially dependent on .Net Core platform, it could run on both .Net Framework and .Net Core.
ASP.Net Core is the only web framework running on .Net Core though, the old ASP.Net framework is not ported to .Net Core. So to answer your question, no, there is not a non-core asp.net running on the .Net Core platform.
Then there is EF Core which was a rewrite of Entity Framework. Again, this was not initially dependent on .Net Core, although later versions is.
Basically "Core" just means "new backwards-incompatible rewrite".
The open source multi platform rewrite, originally named core, now named "", is going to be the active platform going forward. There are several core rewrites of the popular modules that will be the ones that are actively developed going forward.
We can either stay on 4.8 forever, or migrate to the "" which is where all the new and exciting things are being developed. MS has promised they will support 4.8 for the foreseeable future, for what it's worth.
Here's a video explainer: https://youtu.be/4olO9UjRiww
At this point I've given up hope at grokking the various names within/peripheral to dotnet.
It requires a PhD to understand versioning at this point.
Both .NET/C# and Java are the core of Dark Matter Development [0]. They're what a huge chunk of developers and enterprise actually use but they're not cool and they don't get blogged about.
Obviously the history of EEE and Windows only legacy means there's a lot of hostility to anything .NET specifically amongst a subpopulation of developers. However I don't think it sufficiently explains the lack of noise about both Java and C#.
It's a bit of a shame because it would be nice to have more startup opportunities in .NET (or Java/Kotlin - rather than slow, dynamically typed, error-prone scripting language du-jour), there are some but they're a tiny minority.
It's hard not to get caught up in worrying about the future of one's favorite language/ecosystem but then I think over time the obvious benefits of the ecosystem will win people over, I hope.
[0]: https://www.hanselman.com/blog/dark-matter-developers-the-un...
Sometimes you see articles on the Internet where someone basically says something along the lines of "All developers use the Linux bash command-line workflow", and I just look at statements like that and wonder what on earth are they talking about!?
I have never seen a developer familiar with the command line. I have never seen a developer willingly use a Linux desktop. I have never seen anyone do anything but boring, "dark matter" .NET and Java development using IDEs on Windows.
I'm not talking about a couple of guys here. I mean that I have met or interacted with hundreds of developers across dozens of organisations!
Literally not one has ever said: "I wish I had bash", or any similar statement.
I tell a lie. I just remember that the one startup that I worked for had: Linux, bash scripting, allergies to Microsoft, hip-new-technologies, etc, etc...
In .NET there is usually one way to do things, the MS way. You don't have options. Whatever MS prescribes is practiced by most enterprise shops. I remember arguing for something closer to MVC (several open source solutions) when ASP.NET forms was the way to do things. It wasn't until ASP.NET MVC came out that enterprise shops came on board.
I still see a lot of documentation that shows Visual Studio screenshots. How am I supposed to do that on Linux? .NET still feels like a Windows first solution. You will not find official docs for Python, Node or Go using OS-specific IDE or editor screenshots.
Even if you ignore the history of companies like MS and Oracle what it comes down to is vendor lockin. If there's a chance a vendor will pop up in 3 years time with a huge bill, why take the risk when there are plenty of free alternatives.
From your linked article: "Where are the dark matter developers? Probably getting work done. Maybe using ASP.NET 1.1 at a local municipality or small office. Maybe working at a bottling plant in Mexico in VB6. Perhaps they are writing PHP calendar applications at a large chip manufacturer"
i.e. in Cost Centers not Revenue Centers, which is to say in jobs that do not pay well, and their management is trying to figure out how to spend less money, not make more money.
It's leftover industry bias because of Microsoft's long history of a proprietary tech stack that costs money to use. Today's Microsoft of promoting open source VSCode doesn't really undo the mindshare they lost in the 1990s and 2000s when the internet got big. I wrote previous comment about this: https://news.ycombinator.com/item?id=20256825
C#/.NET (including WinForms and ASP.NET) was instantly popular with corporate enterprises but Microsoft never captured emerging startups with their tech stack. E.g. 1990s startups like Ebay, Amazon, Google, etc all used Java+MySQL+Linux instead of C#+MSSQLServer+MSWinNT. And new high-profile open-source projects like Hadoop, Cassandra, Elasticsearch, etc chose Java instead of C#. I currently can't think of a famous project where the canonical source is C#. I use iText C# library but that was ported from Java. That's how it usually evolves. A lot of C# libraries were actually Java projects at first.
In Microsoft Land, the SQL Server team considers this an Enterprise feature, which basically translates to: "We added a couple of zeros to the price".
THIS, I feel, more than anything, meant that the Microsoft stack was just a dead end for many startups. The licensing cost for the database alone exceeded their revenue.
This was already crazy back then, but since then Microsoft has doubled down and increased SQL Server licensing. It is eyewateringly expensive now, and even their Enterprise customers are slowly starting to switch away from it.
They're slowly but surely turning SQL Server into Oracle.
But if your personal projects are a stepping stone to a programming job, then .NET has a monstrous legacy problem. In 2002-2007 a lot of code was written using .NET in enterprises: it was the best way to write a rich desktop application for Windows and ASP.NET WebForms, while terrible, were an okay stack for intranet websites, certainly not worse than PHP5 without Yii or Laravel. And if you were a Microsoft shop, you got the best integration with MS SQL Server and (oh Lord) BizTalk if you used .Net.
But then Rails and Google Chrome came out and completely upended the webapp industry. Microsoft has been playing catch-up ever since.
A modern startup could certainly use .NET 6 instead of the framework of the month to write their world-shattering program, but they won't, because .NET isn't cool. A lot of .NET jobs are in stuffy enterprises where you likely won't be paid to write a backend to a Svelte SPA in .NET 6, you will be paid to maintain an ASP.NET WebForms 2.0 monster that uses WCF to talk to some SOAP/XML webservices.
Of course, the same applies to JavaEE, but Java has a second leg to stand on: people wrote FOSS in Java back when it was a dirty word at Microsoft, so not everything in Java shops is a terrible Spring/JavaEE mutant that has to be configured using vendor-specific XML.
Microsoft does not play catchup in the web space. It is in the pack for some years already. The stuff they do with Blazor is at the upper end of the pack.
.NET, like Java, is not cool. It does not need to. It gets the job done without any experiments in a very modern platform. Doing a startup with boring tech is a thing.
So in summary: .NET is a very good choice for a beginner or converts. It is fresh, you can do solid stuff, do the full stack in one platform (web, desktop, apps, games, iot, ML, ...) and there are plenty of jobs (greenfield or brownfield).
Every enterprise targeting technology has the same issue.
In fact, that legacy is an opportunity to move into modern stacks.
And where is Rails now? .NET is still thriving.
>A modern startup could certainly use .NET 6 instead of the framework of the month to write their world-shattering program, but they won't, because .NET isn't cool. A lot of .NET jobs are in stuffy enterprises where you likely won't be paid to write a backend to a Svelte SPA in .NET 6, you will be paid to maintain an ASP.NET WebForms 2.0 monster that uses WCF to talk to some SOAP/XML webservices.
I get paid to write a modern microservice based application using .NET, Kubernetes, Docker, Consul, Redis, Postgres. I can't say it's boring. But it is true, the app is for an enterprise, not a startup. The payment is relatively good and the app is making money for the company, so we aren't a cost center.
I'm working on migrating an ASP.NET 4.0 application right now, and it's basically stuck in the past.
Physically, yes, it could be updated by the developers to work on .NET 6.0, but no manager will ever fund this. They don't understand the benefits, and no amount of explanation will justify this effort in their minds.
So Microsoft basically stranded their customers on an iceberg floating away from the shore that is very slowly, almost imperceptibly melting...
TLDR: Microsoft wanted .NET developers to only use tech from Microsoft, used various tactics to achieve that, and people got the message. If you wanted to use modern tech or develop innovative stuff, .NET was not a comfortable place to be.
Microsoft have tried to move past that, but never really have. .NET has never had a healthy Open Source eco-system.
Another aspect is that M$ tools are used by millions, it's just that there's a selection bias for tried-and-true tool users to just quietly make things work. "Blue collar programmer" comes to mind. All the leading-edge churn, noise, and fatigue is the corner of the industry that generates tons of blog posts and HN links.
Most/all of their offerings seemed like legacy software/tools once IntelliJ, big JS projects, and SPAs became such a popular solution for software development on macOS and Ubuntu.
Now with VS Code, TypeScript, heavy dev in GitHub platform, cross-plat .NET, vcpkg, etc... and generally very powerful dev tooling, they actually have excellent offerings.
All that said, M$ clearly has a long road ahead of earning back good will in "high" tech corner of the industry and Academia.
So, I'm a *nix guy. You know, running Sway WM, using Doom Emacs as my daily driver, that sort of a thing. Learned vim to write my thesis at night on an armchair where using the mouse was not comfortable.
Not long ago I accidentally got involved with a kind of a .NET consulting gig. Rather, I got involved as a domain expert to help out some SaaS startup dealing with that domain, and it just so happened that they were writing their thing in C#. Before that I hadn't used C# at all, mainly dealing with Python and C++. I liked the language, I thought the tooling on Linux was pretty decent. The ecosystem was a bit lacking for the domain in question, but it had other nice things going for it.
But there was definitely a bit of a culture clash with the .NET guys. As an example, I did my domain thing in a pretty much self-contained library. While writing it I needed something that would be 'just data' without any additional 'functionality' attached to it, so I naturally reached for `struct`, given that it exists in the language. The .NET guys asked why it was not a `class` instead. See, somewhere deep inside they felt that not wrapping everything in a `class` is wrong on some fundamental level. Later, I had to touch the rest of the codebase a bit. At one point there was something I felt was a 'one-line change', that took 12 files to edit. Mostly routing calls through different auxiliary classes because 'architecture'. And you know, I'm really not trying to diss those guys. They were nice, capable, smart, productive, good people. It's just that I was very evidently from a different 'tribe'.
So, I personally like the direction that .NET is taking. I think that this release has very nice things in it. Such as the statically linked binaries, and compilation to webassembly. I also believe that modern .NET has a nice value proposition in being able to use your code across the board in many contexts and settings. On top of that, both C# and F# are nice languages.
But I won't be looking for .NET jobs, or putting that .NET stint on my resume, lest some recruiter gets the wrong ideas!
And there can certainly be a culture clash, there is a bit of a tendency towards more complex patterns in the .NET world. But you don't have to do that, and MS is quite explicitly adding versions with less boilerplate in this release, if you prefer that.
The difference between a class and a struct in C# is not the same as between a class and a struct in C++. In C#, structs can definitely be useful, but also have some gotchas, so they're mostly used only in performance-critical parts of the code.
If you visit a foreign tribe, I think you should listen to the locals, unless you are really certain your way of doing things is better in the local context.
Have heard this sentiment in more than one comment in places like HN. "The {tech} is great, but the culture was ... so I'm not putting {tech} on my resume". And So it becomes a self-fulfilling prophecy :). Yet some tech seem immune to this. They don't say "X is great but the culture was crap, so I'm abandoning X", they say "X is great but the culture was crap so I'm changing jobs".
It really drives home that culture is critical, and even the worst tech can be tolerable if it is thought of as cool. Though of course the thought of abandoning ship to learn the latest and greatest solely to avoid legacy C++98/Spring/WebForms/whatever is naturally appealing.
I won't blame .NET for this. Needlessly complicated architectures are because OOP everywhere minded guys, Uncle Bob and GoF patterns. If you worked with a Java shop you cold have been hit by the same scenario.
1) Region (for example, my data point is from Boston)
2) Framework language choice (https://insights.stackoverflow.com/survey/2021)
3) Ecosystem (i.e. Microsoft vs. Unix)
4) Experience level (probably)
If anyone has any SF data points I am extremely curious.
And it's an especially hard sell given that it doesn't have a good GUI situation. Support for Windows GUIs is back since .NET 5, but the cross platform options are weak. It's very possible when the MAUI library finally releases that we'll see more people deciding to use .NET.
Avalonia is great and recommended by most people that used it. Or do we now only count Microsoft-made solutions and then whine that .NET is not open to OSS?
Rider is the perfect replacement, though. Comes with all the features of ReSharper (this is a big deal for many .NET workflows, VS may have integrated many of its features, but not all of them) and extensions and themes you can actually use (IME with VS of the 50% that promise to do what I want 90% are broken).
JetBrains just know what they’re doing. They’re clearly prioritizing quality (something the VS team seems to be actively working against).
Oh, and it’s damn near 100% compatible with VS projects (one thing I missed about 2 years ago were live updates of WPF XAML, everything else just worked).
.NET/C#/F#/VB are old. 20 years for C# and VB. And they weren't friendly on non-Windows platforms until recently (last five years or so).
Microsoft procured the open source version of .NET (Mono) and decided to push the platform to a unified, cross-platform deployment. That started with .NET Core and has evolved to .NET 6.
So you're coming to .NET awareness exactly when it's at its most effective cross-platform capabilities.
And AWS and Azure both let you build C# functions/lambdas for serverless API's, so it has market appeal.
I'm building my startup, Mach9Poker, in C# and the debugging/unit testing are top notch. The language C# is easy enough. It's the libraries you have to really learn and there is a "way" to Microsoft things that's different. But there are also massive helpers in IO, list management (Linq is one of the greatest technologies ever created), generics, lambdas, and more.
I started with C# with 1.0, back when structs inside structs didn't serialize properly. I've written iOS apps with Xamarin. I am a C# fan. I haven't used it professionally in a decade and my last personal project was years ago.
When is C# the right idea? The only time is when the project is entirely captured by the Microsoft ecosystem. There are plenty of places where this is the case. Windows desktop applications. Small business contract work who are still using Windows. Big business IT who still use Windows. Opportunities to migrate to Azure.
Where is C# the wrong idea? Everywhere else.
Writing for the best monetized mobile market? Swift.
Writing for cross-platform mobile market? Javascript.
Writing for cross-platform desktop market? Javascript. Maybe Java if you have a history of it.
Writing for the cloud? Something linux first. Javascript, Python. If you want a big GC language, why would you pick C# over Java?
AAA games? C++
Not AAA games? Maybe C# with Unity?
In every category where C# is used (outside Microsoft captured environments), there is a dominant solution which is not C#.
And that sucks. Because C# is awesome.
From a management perspective, this is not bad. You get movable team members. In my company we have moved people from WinForms app, to cloud deployed micro-portals and then to a Apple/Android App (all different solutions .. not a migration). C# play a big role in that.
I think this is again a dark-matter-developer / line-of-business situation.
>Why is this?
It's a reminiscence from the times .NET was Windows only and MS was considered evil by the Linux guys.
Some older people haven't learned that times have changed.
And for young people is missing the coolness factor, it isn't promoted and made fashionable like the shiny new framework X for Javascript.
Well, the job market is pretty hot right now so I hear.
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! [...] the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up
Maybe Microsoft got out-fire-and-motioned by Node.js for a while but they're working extra hard cranking out new stuff.
There are many reasons why one might be unable to upgrade to the latest version of any given thing. For an example close to my heart of why one might be unable to upgrade to .NET 6 (or indeed to later versions of the .NET 5 SDK), there's the showstopping https://github.com/NuGet/Home/issues/10389.
That's incredibly weird take in my opinion.
Whenever I use VS Code, then I feel huge gap between this and real VS with Roslynator extension.
I think the user interest was startup times of lambdas and containers. Therefore Linux was a priority.
Lightweight web apps mostly in python (Flask).
Slack apps / bots with a bunch of commands (backend does lookups, generates PDFs)
People don't fully realize what we gave up dumping desktop development, you used to be able to build our nice biz specific crud apps (customers, projects, scheduling etc) using a bunch of tools. These things were usually darn fast if you were careful and you could make them very keyboard driven (ie, put the keyboard shortcuts on button labels etc).
[0]: https://docs.microsoft.com/en-us/dotnet/core/compatibility/6... [1]: https://docs.microsoft.com/en-us/dotnet/core/porting/upgrade...
That's why I like it. Not only being able to do tons of stuff with one language, but using the same frameworks and libraries.
In this case though, the struct usage was completely in line with C# documentation regarding what structs are for. I wasn't trying to write C++ in C#. But hey, I do agree that code should be idiomatic to the particular community such that it doesn't feel out of place! In that case the struct did become a class.
Edit: Just re-read C# documentation on structs. Yes, it absolutely made sense to have a value type there. As in, the documentation mentions the use case almost verbatim.
I know there have been some quality issues on the EF Core side, but on the Framework side everything has been pretty rock solid for me, with easy upgrades between versions.
What makes you say that? All versions of .NET - including non-LTS versions - have had an extremely high bar for quality before releasing.
Looks like the way to convince them is to tell them we will be moving to a <gasp> microservices <gasp> based stack and slowly start building the services on modern stacks (and gRPC)
We did just this at the company I work for. We are replacing an old monolith with modern architecture.
When the .Net Foundation was announcing that they were going to drop the hotreload support from dotnet watch in favour of supporting it in the Visual Studio editor I was again reminded of how (some parts of) MSFT think that dotnet should still be a fully integrated development platform for Windows, rather than a multi platform, open community and open source project. I guess there might be some internal power struggle there between various business interests.
There are already more Linux VMs on Azure than there are Windows VMs. And if they still insist on making the dotnet experience on Linux and MacOS subpar compared to Windows they will very quickly find that people who develop for these OSs will move towards Java or other languages and frameworks with better support for these operating systems.
There are infinite ways to do things. But the most easier way to do things is one. And that is good because anyone can understand anyone's code.
Anyway, my point is there are very legitimate reasons why most startups don't use .NET. And it rarely has anything to do with being cool.
I loved the 3278.
Basically, I consciously researched the differences between class and struct in C# beforehand. And decided to use struct as the 'thing' was a kind of a coordinate that would be instantiated a lot for simple coordinate-space transformations, so it made sense for it to actually be a value type.
I should've been more assertive about it. Well, worst case some periodic imports are taking somewhat longer than they should.
The fist that comes to mind is that with a class invariants of the type can be ensured in the constructor or by making the constructor private and exposing static factory methods. A struct, on the other hand, is always simply declared, so don't afford these protection measures. For some reason C# still supports constructors in structs though, and even uses the `new` keyword to invoke them. This creates a kind of trap where structs almost, but not quite, behaves like classes.
Another gotcha is the defensive copy semantics. When a method is invoked on a struct, and that struct is a readonly field, a copy of the struct is created for the method to avoid mutating the field. This is not at all how classes referenced by a readonly field behaves.
I guess the same can be said for the simpler case of just passing a struct as parameter to a method mutating its now local copy. Again different outcome for structs and classes.
Since the code look so similar (its just a different keyword at declaration site) it creates an uncanny valley tripping people up. Not least when refactoring between the two. After all, being a language with a GC means memory layout is seldom a primary concern for people.
However you can now declare structs readonly to avoid the defensive copy thing, or as a ref-struct to retain mutability, almost like a class. And as long as the default value is perfectly valid, like say (0,0) there shouldn't be much surprises anymore.
Don't confuse inexperience with culture.
I'm from a mostly-.NET background I argue with typical .NET developers all the time.
I also argue with Java developers, and C++ developers, and...
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
I don't mean because it's written in C++ instead of C#. The render pipeline of WinUI is more efficient. It's really interesting, but unfortunately I can't find the technical blog I was thinking on.
And as efficient as it is, it still can’t resize windows without flickering. It’s worse than WPF or Win32. And there still aren’t proper APIs for configuring the titlebar area.
I wish they focused on getting their vendor partners to make efficient processors, rather than try to get all windows developers to rebuild software to run on hobbled ARM hardware.
https://arstechnica.com/features/2012/10/windows-8-and-winrt...
90% of the articles on the web, are 100% certain that I have a use VIM / Emacs, on a Linux machine.
Where are the articles that focus on the rest of us?
Similarly, Microsoft broke how clear screen works in both Windows Terminal and VS Code to match the UNIX terminal standard.
Hint: Neither of these are standards by any definition, and UNIX people were arguing over both of these things at length themselves.
Before we forget: VS Code is made by Microsoft employees and is primarily deployed by people using Microsoft Windows.
But it has to adhere to the "standards" that Microsoft developers are used to and expect.
There are a lot of CLI devs out there, even in enterprises! I highly recommend gaining proficiency with the command line, as it will make you a more productive developer in the long run. While most everyday tasks may have a GUI, if you end up working near the cutting edge, you will likely encounter problems that do not have any GUI alternative. And if you end up working on a rare problem, no GUI may ever emerge. Your CLI skills may be the difference between a 10-minute solve and not being able to accomplish the task at all.
I spent > 10 years building on Windows, and this advice definitely applies to the .NET ecosystem as much as others. On Windows, Powershell mastery will set you apart.
On a technical side there were no gains and numerous limitations.
But, yes, if you looked at it in 1.x days, it really looked a lot like Delphi libraries with Java-like syntax. So if you were already using Delphi, there wasn't much point.
In my opinion, while other ecosystems have exploded in complexity in recent years, the increasing simplicity and batteries-included nature of .NET is an appealing contrast.
That's my answer to your question about why you should be interested in .NET if you're not already in the ecosystem.
Because they are killing community made solutions by reimplementing the same solution and utilizing community's habit of favoring only MS software that they themselves engraved into that community throughout the years, even if original solution was better, thus closing the circle. They essentially kill the community around .NET themselves because instead of supporting projects like Avalonia, they reinvent the wheel(often ineptly) to ride on that 'Microsoft ecosystem' wave. The only exception to that that I know so far has been Polly that they pulled into .NET Core.
I don't think the Avalonia example is a good one either. Nobody talks about why Ruby on Rails doesn't support Sintara. In other ecosystems, every project is in competition. Why should .NET be singled out.
I think the argument that open source software can't compete with Microsoft is total bunk. If the alternative is competitive, it can succeed. Dapper has been around for over 10 years. Avalonia is "used by >170,000 companies, including 431 on the Fortune 500 list" according to their own website. Xamarin joining Microsoft is pretty much why we're talking about .NET 6 right now. Microsoft's first party solutions are really very good (in house or acquired). This is again why you might choose .NET over a more chaotic ecosystem.
I have a friend-of-a-friend who has a successful 30 person contracting business. They do C#. He, the co-owner benefits from this.
I was responding to a question from a FAANG developer. FAANG developers don't get moved. FAANG developers move when they want to move: to projects that they find interesting; to other FAANGs; or to start-ups.
And FAANGs don't pick one language because "hey, it's possible to do what you want in it".
If a developer knows C# he can tackle more than one domain. Suppose you got bored and want to switch. Or there are new interesting opportunities. If you know C#, you just switch without having to learn a new language and libraries.
This. You see this as a positive. I see this as a negative. And we're both right, right? You are right in your domain, and I am right in mine.
Well, at least you can if Blazor gets finished.
Examples:
Getting blogged on a site that is dedicated to that tech is not noteworthy.
You can find such blogs or forums for every obscure language that has more than a 1000 users.
So if you want to use F#, I think you still need to be able to read C# code.
I see Microsoft attempting to make C#/ASP.NET more lean and faster to get started with (eg. minimal APIs) but I doubt they can overcome the stigma.
That doesn't change the fact that .NET roots are in old enterprise and Java - which was dumbed down by design to make it easy to onboard unskilled developers (look at their arguments against local type inference and lambdas before they were added).
Things like ASP.NET core slam you with heavy duty abstractions from ground up and justify it by project scaling and reducing maintenance cost at the expense of iteration speed - again tradeoffs made for large enterprise const center style projects.
With recent iterations (minimal APIs, top level functions, namespace declaration, etc.) they are trying to reduce those tradeoffs and cater to the startup crowd but the MS + corporate budget development stigma is going to be there.
MS recently made one tiny decision that was unfriendly to open source, it caused a huge outcry and a reversal within 48 hours on a weekend. I can't even imagine what the reaction would be in your scenario.
Besides, basically everything is open source now and you can't put that genie back into the bottle.
Microsoft's handling of .NET 's OSS community has been haphazard at best. Just a week or two prior to the 'dotnet watch' debacle, there were issues and concerns with the .NET Foundation that led to the Executive Director stepping down [0].
I bring this up, because in many cases the perception is that there is -still- lock in, just in a different fashion.
By that, I mean, if you Ask a typical .NET developer what they use, they'll probably say ASPNETCORE, EF Core, maybe you'll hear Hangfire, MediatR, RestSharp, or Dapper.
So, you've got a bunch of .NET devs that -only- know Microsoft technologies for the most part. Yeah there's some other stuff like MongoDb, Kafka, Redis, stuff like that, but It's not very frequent you hear about teams reaching out to other technologies.
It's very rare I hear people bring up Linq2Db, a beautiful* Micro-ORM that is best described as a type-safe, extensible SQL DSL. Or Websharper, a really-freaking-cool library that basically lets you transpile your C#/F# code into Javascript and/or Reactive HTML, complete with seamless server calls if you'd like.
You might run into some interesting things at different places. One shop I was at used MassTransit, which was kinda cool. I've wound up using Akka.NET a few times in the past, which has always been super fun.
The end result of this though, is the -perception- of what .NET Developers are like. And sometimes those perceptions are real. I remember the dev that felt Dapper was some sort of 'black magic' and would stick to writing DataReaders and or datatables by hand, and another that was so against the idea including Non-MS tech in a project that it wound up costing him his job; he insisted there was a way to get EF to do things in a performant way (answer: not sanely, and not easily the way the app was built on an arch level,) and refused to accept a PR that solved the problem with Dapper.
He wound up doing the thing I've seen a -lot- of .NET developers do; fight the Framework.
To be clear here, I'm not referring to the BCL. It's not always perfect (I'd love for an analogue to SSLEngine, please?), but it's -fine-. I'm referring to bits like ASPNETCORE, EFCore, SignalR, and Microsoft.Extensions.(DependencyInjection/Logging) where developers wind up getting in awkward tarpits around some weird edge case because of a business requirement or some other decision that, unfortunately, can't be undone.
Or are just plain 'well, that sounds sensible in theory' like "I would like to update N rows in an new status that are older than 1 month and set to overdue, and not have it be N update statements." Maybe EF does that now, but last I knew the answer was not really.
At my first 'Real' Dev job, we were a .NET shop, that often had to 'fight the framework' (it didn't help that we were on an Oracle Backend, which made -everything- more of a PITA before we discovered Dapper.) When the .NET guys hit one of these roadblocks, it would often take sprint after sprint of fighting to either have no solution, or have a solution that would render the app hard to maintain. The newer teams using Java? They didn't have those problems. We later heard they had 5 different ORM-ish libraries in use over there. At the time, a lot of the .NET devs kinda treated it as a sort of derision. 'hows somebody gonna understand it?'... But the Java teams delivered. It is also worth considering, maybe those were the best libraries to solve the problems that the app in question needed to deal with.
And that's kinda the 'mindset' that is a set of .NET developers that fit the stereotype; if it's not an app that fits their cookie-cutter world, they break down and can't understand it. In other words, they're afraid to step outside the box, which means they're less likely to think outside the box.
The typical 'litmus-test' of this type for me is a sliding scale based on their past/current experience with other languages and willingness to work with them.
* - I do some contribution work to Linq2Db, so my opinion may be a little biased.
[0] - https://github.com/dotnet-foundation/Home/discussions/39#
But then, do you really believe one would be a smart person if they were to look for .NET jobs where at the same time Windows is not the dominant environment that people use at work?
Are you sure about that? Maybe Windows is not dominant when you look at startups.
Anyway, what .NET has to do with Windows now? You can happily use it on Linux or macOS.
I would say that has only just become the case and still isn't for desktop development.
React, Vue, Svelte as well as Flutter & SwiftUI all implement different but vastly more productive reactive dev models.
MAUI will not be resurrecting .NET Desktop Apps which have been on decline since WPF. Blazor Desktop Apps might, anything XAML won’t.
For example, my experience with CSS has been the opposite of that. F5 a million times before the layout works the way I want it to. Sometimes even googling how to do create some type of layout because I can't think of it on my own.
You can, as sbelskie mentioned below. In .Net 6, it's available as a Preview [1]. But it's going to ship with the main framework in 7.0 [2].
The preview works quite well. You can build self-contained, smaller executables, and shared libraries callable from say, C code.
[1]: https://github.com/dotnet/runtimelab/blob/feature/NativeAOT/...
(I also suspect that the vast majority of LINQ code in the wild is of that variety, rather than Entity Framework etc.)
I disagree in a respect. I think with an ORM it's clear when you're hitting the database, though it makes it easy to write loops over (related) rows ("n+1 problem"). I think with LINQ using the same syntax/expressions across local and remote operations it can be more blurred what's happening.
You can bundle everything in a single file but that file contains the runtime, so even small Hello World apps are 50MB+ last I checked, though there have been some improvements recently with trimming and AOT is hopefully coming next year with .NET 7.
"Nobody can name things like we can't!" (followed by cry-sobbing)
The more serious response to this is:
For better or for worse, The .NET Framework (which is now squarely legacy tech) has stuck around and been reliable. People have had their trust in it validated. For two decades now, if you're a CTO at some big enterprise, you know that .NET Framework will get the job done for much of your development needs. From a Microsoft branding perspective, this is amazing. But it's got all kinds of problems can't be fixed unless you break everyone. Uh-oh!
This is the biggest reason why branding and naming has been so complicated pver the years. And it's even come with little sub-problems, like the fact that the version number for one "flavor" of .NET would match up with the version number for another "flavor" of .NET and so now you're screwed no matter which decision you pick.
A cleaner approach would be to throw it all away and do a complete rebrand (we had a little proposal to call it "Concert" where C# and F# could be played in harmony with each other, how cute) but with that you throw away the brand of one of the most successful pieces of technology ever produced by the company. Not exactly a winning proposal.
The other factor here is that with .NET there is so much software involved. It's three entire programming languages, a runtime, a huge standard library, a web framework, a database access and management framework, a machine learning framework, several Windows app frameworks, a mobile framework, IDE tooling, command-line tooling, and a bunch of other stuff too. .NET is far larger than many other competing stacks in terms of what a single vendor produces. Since Microsoft produces so much software for .NET and aligns their releases, they also message each one, and with that there's a big sea of stuff to keep track of.
I don't know if I have an answer for how to handle the complexity of it all. A lot of folks I know in the F# community only keep track the F# language and IDE tooling updates, then dive into specific stuff only when they care about it (e.g., doing web programming? check out the ASP.NET release notes). But that may not be an option if you're a decision-maker at a company.
Agreed.
> I never fully figured out how .NET, .NET Core, ASP.NET, .NET Framework, .NET MAUI and the kitchen sink relate to each other.
You're not the only one who is massively confused about everything that is labelled .NET or Core.
If anyone else is struggling, I recommend this (I wrote it):
ASP.NET Is the web framework that comes with .NET
.NET MAUI is the application user interface framework that now comes with .NET (Since .NET 6)
.NET is the overarching term for everything .NET.
.NET Framework refers to every version of .NET 4.8 and before. .NET Framework only ran on Windows (unless you used Xamarin to run it on other frameworks. Xamarin was a third party implementation of the .NET framework, it is now owned by Microsoft as well).
.NET Core is the new version of .NET. In the first 4 (I think) versions it had it's own branding, .NET core 1, 2, 2.1, and 3. .NET Core runs cross platform across the desktop OS's natively. Xamarin was still used for mobile development.
What would have been .NET Core 4 has been rebranded as .NET 5. Xamarin at this time was brought into the fold, allowing full functionality of .NET Core API's across desktop and mobile. I believe this rebranding was done because .NET Core was being considered full feature enough to take over the legacy of .NET.
One thing you didn't mention but I'll touch on as well, is .NET Standard. Lot's of people get confused about .NET Standard. .NET Standard is just the definition of what different frameworks that implement .NET Standard can use. So if you write your code to target .NET Standard you can't use .NET Core specific API's but what you can do is have the same code compiled against .NET Standard referenced in your .NET 4.5 - 4.8 Code, or your Unity Code, or your Xamarin code. It was primarily designed with libraries in mind.
Not quite. ASP.NET is the web framework that comes with .NET Framework. ASP.NET Core is the web framework that comes with .NET Core and .NET.
> .NET Framework refers to every version of .NET 4.8 and before.
It was fine to call .NET Framework 4.8 just ".NET 4.8" in the past, but I would avoid it now, to clearly separate .NET Framework 4.8 from .NET 5.0.
Not quite, MAUI has been delayed until next year.
I believe people would not jump as easily onto that wagon if it would be called "Silverlight Core".
Exactly why I prefer Go to Java and C#.
It seems to me that F# could get a bit more love from HN-style nerds. Obviously, it's more similar to C# than Golang, but specifically error handling can be done in much nicer way using the Result type.
vlang[0] also seems like a nice golang "fork" that I'd be willing to spend time on.
For the creators of Mahapps I have eternal gratitude.
In any case, surely, adding yet another different style only makes the problem worse.
Also Java is OO which is... terrible to say the least.
In 2021, the AOT free beer exists, as do JIT caches.
As for OO model, I rather be able to understand which interfaces a type implements by looking at it, instead of producing compiler errors, or have a type by accident supporting a single method interface with complete different semantics.
Not sure what the OO rant is about, it's awesome. It's not like golang isn't (poorly implemented) OO as well (minus explicit inheritance, which embedding is somewhat similar as well).
I do agree - source generators have a better API as an implementer and can generate more than classes. I guess as soon as I need to jump into a proj file and I'm working with MsBuild anyway what stops me creating my own generation framework that runs before PreBuild that generates code for my compile step? I've done it before source generators were a thing.
I also did a quick Google search - Myriad (F# library) might be something that does something similar.
I hope they succeed because it has/promises a really attractive set of features.
Unless I'm misremembering, until recently Avalonia was still being touted as primarily a replacement for Desktop WPF. I was shocked to see they're talking about mobile now too. I guess it's somewhat expected.
Uno basically does what MAUI does. The main difference being, Uno has been around for a while longer and something you've been able to use for some time. I'm pretty sure they had usable versions for well over a year before MAUI was even announced.
In any case...
Microsoft's UI story is a non-starter until they get back to the point that a user can:
- Click new project - Fill out the form - Get a Design window, - Drag a 'Textbox' into the design window, - Drag a 'Button' into the design window, - Double click on the button, get taken into a generated event handler, and the user can intuitively put in the right code (i.e. updating the viewmodel with 'hello world'.) - Click 'run'
That's the Story that got an untold number of new developers -enamored- with VB6, a language that got so entrenched Microsoft had a hard time killing it. It brought a number of developers into the world of C#, making it easy for to write applications used at work that a whole team could use. That's actually how I 'eased' into programming at my first workplace; I wrote an app with a big ugly panel and a bunch of big buttons with labels that would automate tasks. Need a variation on a theme? Drag a new button over, maybe do some light refactoring, test, publish, tell the guys to restart the app. 10-15 minutes tops.
Sure, Eventually I had to go through a spaghetti mess of callbacks and crappy generated code, but it was good refactoring practice ;). And when I left the company, someone else took over the code and now they are a software developer too.
Why do you care about this stuff? I don't understand. Surely most developers can build a simple app with a few buttons easily in whichever framework they're using. This stuff doesn't really matter for I'd dare to say 90% of developers. What matters is how hard it is to build and maintain complicated stuff. And there WPF blew WinForms (and VB6) out of the water.
Not sure why you think how difficult it is to put a couple buttons on a page and make them do something would have any effect on the success of a UI framework. That's literally not even a consideration when we make decisions on what to use for a project.
If WPF ran on other platforms, we would use it for everything. We use Avalonia instead, and it's pretty great.
But there are 2 basic types of multiplatform UI frameworks - the ones that wrap native controls and look like most other apps on the platform, and the ones that do their own rendering and look the same on every platform. Avalonia is in the second group, so if the former is a hard requirement then it is not a good choice.
What matters is how hard it is to deliver a product to the end users. As I gave in my personal user story, yeah, I had to eventually pay the piper and refactor significantly to make sure things were maintainable. But it was a good lesson learned, and I've met many other developers over the years who got hooked on C# in a similar way.
> And there WPF blew WinForms (and VB6) out of the water.
WPF would be fine for this scenario. If we could do things like this at a WPF level of designer I'd be happy. It's got a little more of a cognitive load to get started but long term is easier to reason about long term and from a conceptual standpoint is more transferable to other contexts (i.e. Web MVVM Frameworks.)
I haven't looked at Avalonia in it's current state (last time I gave it a peek, it was still in a 'almost-ready' status) but if they really are able to do multiplatform as I see they say now then perhaps that's what I'm saying is needed. (Which may be more of a statement on the state of Real OSS Awareness in the .NET community.)
Definitely will give it a go, since I know it's supposed to be a replacement for WPF so I'm hoping(?) that the existing tooling out there is usable
Non-starter these days. Building a form graphically doesn't take into account multiple screen sizes and screens that can change dimensions on the fly, which are now far more prevalent than the heady desktop UI days that you're talking about here. Unless you have some novel idea for how to design graphically for all sorts of screen sizes.
It's about the species; Remember that I mentioned that in the context of 'someone getting started'. I say what I say because it would be the best thing to help new users get 'hooked,' not necessarily because it's the best way to make a maintainable app. (IDK though, some of my one-team winforms stuff was actively maintained for years after I left)
> Building a form graphically doesn't take into account multiple screen sizes and screens that can change dimensions on the fly, which are now far more prevalent than the heady desktop UI days that you're talking about here.
There's no reason you couldn't handle such a thing in WPF. Sure, it may be more -work- to check representation in both formats, and some form of helper (that would handle certain scaling factors of buttons/etc) would be a boon to developers. That's not the way I look at it though, see below;
> Unless you have some novel idea for how to design graphically for all sorts of screen sizes.
It's not necessarily about making a 'single' UI that works on both mobile and Desktop. If you can even get to the point where a user can make separate Mobile -and- Desktop 'form-style' built screens for their app, all in one happy framework/language... Frankly that would be the best thing overall, since you can provide optimized Desktop -and- Mobile UIs, and not have to have a bunch of disparate technologies used to build each.
Its been a while since I looked at these and I was having a look for a designer like WPF for Win UI/Uno etc - does this not exist?
Also, to keep the size at least somewhat in check, unused parts of the base library are not included in the single-file mode.
(DLL hell stopped being a problem a lot sooner than you probably think, too...)
Abort, Retry, Fail?
FFFFFFFUUUUUUUUCCCCCCKKKKK!!!!!!
You of course have to choose your target platform for this as it makes .exes for Windows, ELFs for Linux, etc.
If you want you can still choose to distribute IL DLLs and users then use their already installed dotnet on their machine to run them.
https://github.com/jart/cosmopolitan
(but, yeah, you probably want one version per target, even if hacks are cool)
1) I use leak detection tool so no productivity gain in that area. Besides it is burned into my brain to always write deallocation code first before doing any allocations. That is when my classes are not using interfaces that are reference counted. In reality I could hardly remember any instances when memory / resource leak tool showed any. Also I did not have to dance around IDisposable, Weak and object caches shenanigans.
2) Generics - this is great feature but in my opinion it is mostly geared towards libraries writers. Being more of a product / application oriented bar few exceptions I personally do not use it much neither in C++ nor in Delphi (Delphi has generics since 2009).
https://www.forbes.com/sites/gordonkelly/2021/11/16/google-c...
Does not match my experience at work unfortunately.
Sometimes the issue is that people have tended to conflate "dll hell" and "dependency hell." That's an old pet peeve of mine and I realize it doesn't matter...
Really the only one that’s done it correctly is Apple.
I don't know why, but there's this weird temptation for every app to try to present itself as some kind of unique work of art, when it comes to UX. But I don't want art, and I don't want branding. I just want ergonomic tools - and part of ergonomics is not to have to re-learn everything every time you pick up a new thing.