.NET 6 Preview 5
devblogs.microsoft.com
devblogs.microsoft.com
I'll admit it takes some time to get started, but it's smooth sailing once you get past the initial hurdles of setting up your project, understanding some idiosyncrasies when it comes to ASP.NET/Web API/Entity Framework if you're going that route for your backend and such. And now with Blazor, I can even work on the frontend and touch Javascript as little as possible.
Can you give an example of this interoperability, please? Also -- what was the difference compared to Java that you noticed?
MAUI (in .NET 6+) will be a first party library for some types of cross-platform desktop apps.
With Java the issues came from elsewhere- it was less so the interoperability and more just how messy the whole ecosystem is and how there are some aspects of the language itself (such as the excessive verbosity and the way the standard library is structured) that kept mounting up as little annoyances over time. Kotlin wasn't really an option at the time, either.
So if you're an MS dev whose looking for some additional reach into other platforms, the increased interoperability is great. However for those of us not working on MS platforms, .NET has a huge uphill battle competing with every other platform available to us.
I want to like what I'm seeing in .net, but there just doesnt seem anything compelling when compared to say Graalvm or even nodejs.
The VM market is very very crowded with fantastic offerings these days, many of which share many commonalities easing dev while each is tailored for a slightly different market.
in the case of .net - xbox.
When you wanted to address unity, that is far more than Xbox.
And gaming is a maybe 20% share of .NET.
Nodejs is beat by CoreCLR dramatically on its own domain.
GraalVM i have to little insights but CoreCLR beats/equals performance of it java equivalent. I guess you can tweak GraalVM a lot more than CoreCLR because that is an actual weak point of the CoreCLR.
C# has been pretty groundbreaking, adding features like async await and generators before other mainstream languages.
They are also pushing forward ASP.NET pretty aggressively, even having first class support for gRPC and other popular technologies.
Is there another mainstream platform with better messaging support without needing libraries that you can name as an example?
I do not look into other platforms. I look into my solutions: http i can write my business logic and that is mostly it. On messaging i have to think about threading, acknowledging, dead / poison letters, decoding, trace contexts, etc. And these is all non trivial code especially when done right.
If you are ab embedded dev, imagine you want to hand of sensor value to a central service without required immediate response.
If you are a game dev, imagine a play turn result hand off to a central leadership board.
Queues and related Message processing are a tool everywhere not just web development.
NGEN never was anything more than a good enough start-up accelerator, and while .NET supports COM, is cannot directly use COM like APIs like DirectX without some extra help in wrapping.
Every time .NET teams try to improve these scenarios, usually Windows Dev team comes around and steals the show, apparently too much .NET isn't welcomed in some units.
This is how you end up with Longhorn and Midori being sabotaged, or .NET Native being dropped.
First class support for native code. I'm not too sure where their IL stuff is going anyway.
.NET is not tailored to something specific Microsofty. However, the .NET community is still challenged when taking 3rd party dependencies (which is the actual limitation) and then complaints when Microsoft is not delivering the perfect kitchen sink.
However, I have to point out that .NET does have a Windows-only heritage, and as a result, a lot of lower-level APIs (files, processes, signals, pipes, terminals) still have some painful Windows-isms. Fortunately, the situation improves every year, and for a typical server application that exclusively communicates over the network, you're completely fine (and have been for several years now).
.Net is not even close to being driven by Microsoft’s internal needs, for the simple reason that their biggest internal products don’t use .Net.
.Net is far closer to Sun with Java or Kotlin with Jetbrains than Apple with Swift.
Back in the early Windows days it was C and C++, then VB came along and it was VB for business while real developers used C++/MFC.
With .NET management tried to create an homogenous runtime, hence why it even supported Managed C++ (replaced with C++/CLI on .NET 2.0).
But they made an huge mistake that persists to this day, splitting the languages across these divisions, thus fuelling their feudal politics.
Biggest hurdle for me (as a UNIX greybeard, Java survivor and occasional LISPer) is ramping up on idiosyncratic C# syntax and various generations of .NET libraries
But what little I've done in the past couple of months (with .NET 5) works OK in Linux, and the tooling (VS Code + Remote to have .NET on a remote VM at a safe distance from my Mac) suitably lightweight and hassle-free.
(full disclosure: I actually work at Microsoft these days but never developed for Windows alone - did mostly C++ and Java when I targeted it - and never did .NET before, as it only makes sense for me to use it now that I can target Linux)
Some people/companies also care about more than the big three operating systems that MS cares to acknowledge. .NET has no official FreeBSD port, for example.
What other languages stacks provide a much better tooling experience? If you use IntelliJ then you get the same thing with Rider (which is just IntelliJ + Resharper), and the rest are all basically VSCode at this point.
I should also add that you /can/ dump a dotnet application running under Linux. It's just you can't do anything really useful with it, the best tooling is Windows-only. Clearly shows you their priorities.
Since that is adapted to use Linux specifics :)
So take VS Code for example, last I looked you could not build Xamarin apps in it, where as with Go, JS, Dart, etc you can use VS Code to create anything in those languages.
Rider is better than Visual Studio at the moment; we'll see what happens if they actually get VS 2022 cut over to be 64-bit, maybe the performance will be back to usable for medium-large solutions.
Sure, that's what I do, and what my friend did before he went to another company where they somehow managed to fuck up the project configuration so bad it was absolutely impossible to deploy from under anything other than Visual Studio. It's using some sort of integrated Azure wizardry, I don't work there and can't pry into their secrets. The thing is, you can't work with that project without a Windows license and a Visual Studio license. MS has zero interest in supporting this use case (can't blame them, I'm just stating the fact.)
Azure CLI just works fine without VS.
No support for JNI debugging, no incremental compiler, 10 finger key chords, requires explicit menu actions to display project errors, never stops indexing the world,....
Tooling for. Net is miles ahead of anything else I've witnessed.
As for FreeBSD there's a huge nuance:
> FreeBSD support still requires additional work to implement features that are missing in the runtime to reach parity with the other operating systems. The community will most likely need to do that work in .Net 3.0/3.1 but I would like to see official automated daily builds for FreeBSD restarted with the master (.Net 5) branches of the necessary repos.
As for your statement on Microsoft. I'd trust Microsoft with. Net more than Oracle with Java.
Rider is my daily driver - no matter what OS I use (primarily Windows/Mac and occasionally Ubuntu.)
java pendant c# was always much more performance focused than java, having structs, unmanaged c# and c++ interoperability. it took java 16 years or so to accept that structs have their justification.
i also find the c# language much nicer than java. f# versus clojure are both excellent additions and again, f# is the more static and performant while clojure has very nice and inspiring features and aspects. it depends on what one wants here.
finally i think even if java is the larger universe, the .net universe certainly is not small either. if .net would not have taken the cross platform road i would have switched to the java runtime, but happily the opposite happened.
F# is really nice, and I enjoy using it for web related things, but I have to reach for different languages if I'm looking to build a GUI right now.
You can even get a single static binary release that will work on platforms without .NET libraries.
Check out the Makefile and project file in this repo if you'd like an example: https://github.com/eatonphil/dbcore/blob/master/dbcore.fspro....
But yeah, it's a great time for sure, just good to keep that in mind since you also can't run any of MS's (or JetBrains) IDE's (or MS SQL) on a VM in Win10 ARM. Win10ARM VM does smoke though so hopefully they releases all that on ARM, that would another nice option.
https://rider-support.jetbrains.com/hc/en-us/articles/440192...
Did not know that about Rider, thx I'll def check it out.
You might have to update .NET 5 SDK to a more recent version.
I use VS for Mac 2019 (x64) and VS Code (arm64) for development work on a near daily basis.
That said, I tried installing the arm64 dotnet 6 preview and it broke the x64 versions I had installed and although I could debug/attach in VS Code, I could not get it to debug in VS for Mac 2019.
From what I understand, the issue is that the dotnet binary for x64 got replaced with the arm64 one. There is only one on the system at a time and the arm64 version doesn't know how to work with the x64 architecture sdks/runtime. There is some discussion and links to related issues in this GH issue: https://github.com/dotnet/sdk/issues/16896
Regarding SQL, I use the Docker Azure SQL Edge arm64 image and it works okay for most thing but doesn't support some of the more advanced features like full text search or spatial types.
For Database Projects (dacpac), Azure Data Studio with the Database Projects extension works okay for basic editing and deployment. However, it's not nearly as complete or refined as the database project edit/deploy experience in the Windows version of VS 2019. As far as I can tell it doesn't create new refactorlog entries for renamed objects and I can't figure out how to create a new deployment profile so I have to select the database connection every time I deploy.
I have been running the x64 build of dotnet 6 preview 4 and now preview 5 for a while and have not many issues. One thing that happened is that it broke the dacpac deploy in Azure Data Studio but there was a relatively simple workaround -- added a configuration setting in Azure Data Studio to override the dotnet SDK path to point to a folder where I had put dotnet 5.
Dotnet Developers seem much more pragmatic. I wish I could go back.
EDIT - I forgot about how bad Java GC is. Still with Java 16 a ParallelOldGC Full GC is taking 30 seconds on a big server.
There is a ton of documentation for both Spring and ASP.NET but both are so complicated and specific to investing in exact ways of modelling users/auth/whatnot that they are both super hard to get into as a hobbiest outsider.
I like both languages and they both have good microservice libraries and general ecosystem. I just don't think it's worth saying Spring is complex without talking about ASP.NET.
I guess the problem is that I've just never had to use on of these at work.
So when programming in my free time in both Java and .NET it's way easier/more fun to just use microservice libraries that are easier to pick up.
Which one? I would be very surprised if it were asp.net core, which is their current offering. It is one of the most straightforward and clean web frameworks I've ever had to work with. Spring seems to me to be a giant bowl of spaghetti in comparison to it.
What's wrong with hair growing on your neck if it grows there? It's completely natural.
I know that this is slang/shorthand, but I don't agree with it at all. I work with plenty of people who have unruly beards and none of them fit the "neck-beard" stereotype.
I don't think it's a very nice term to be perpetuating. Judging people purely based on one physical attribute and then mocking them for it is not a great look for anyone.
Oh, and every single person who has hair on their neck looks unkempt, without exception, am I hearing that right?
Sure, OK.
Yes, shave it. Especially if you have long neck hair and short or no facial hair.
There are some exceptions, if you have a long beard, maybe.
Hair in other places is considered equally distasteful (long nose hair, ear hair, whatever).
...by some. Clearly others disagree.
Personally, I like hairy men and women. It's a clear sign that I won't have to deal with some priggish prude who is more concerned with looks than personality.
Ok, but don't be shocked if some of those priggish people avoid you and unfortunately for you, they may be the ones deciding to give you a loan, to go on a date with you, to offer you a job, whatever.
Everything in life comes with trade offs.
And sometimes it's not worth winning the battle to lose the war.
Everything does come with trade-offs. That's correct.
Being well-traveled is a cure for bigotry though. Realizing that you're in a bubble is the first step.
* rejecting other personal hygiene customs
* being noticeably more pedantic
* picking every battle/argument
* lower than normal respect for other's boundaries
* lower than normal awareness of how their actions effect others
* making "being rational" a core part of their identity
* dismissing human behaviors they don't do as irrational. usually these are the ones where rational explanations do exist, they are just difficult to re-invent on the spot.
This package is common enough to have earned itself a name, which happens to be the easiest visual indicator.
I was surprised and found it super easy to architect, build and maintain with lots of nice patterns.
It's yaybe heavy, but I wouldn't say it's toxic.
Each time, something is breaking which is more often than not "won't fix, just use .net 5". Net 5 isn't even finished and they are already previewing 6?
It is usually something like under .net 3.1, the build was fine and then under .net 5, an error happens, "oh yeah, you can workaround that by modifying your project file". Or you try and build in a .net 5 nuget package which means you can also reference an older netstandard 2 package that the developer has decided doesn't need updating because it hasn't changed.
.NET Standard made sense as a transition plan, but then was effectively abandoned. I understand that the focus went to .NET 5/6, but the effort is incomplete! Using a .NET Standard 2.0 project in .NET Framework sometimes works, and sometimes results in obscure build errors -- where you then are diagnosing why you are getting the wrong versions or errors loading packages System.Net.Http.Formatting or System.Buffers. I think there's also a bunch of hacks underlying a bunch of this stuff -- for example there will be a nuget package with version 4.3.0 that contains a .NET assembly with version 4.1.1.3 in a .dll with file version 4.0.0.0 -- and it's absolutely frustrating and infuriating.
In theory you can also create a project that multi-targets .NET framework and .NET core, but in practice, while I've got this to work, it's an adventure every time and most often I just give up as it's not worth the time-sink.
It kind of seems like the official migration path is just "stop everything, port to .NET 5 and you'll be good". But that's not really practical.
Indeed, my experience on pure .NET Core (3.1) or .NET 5 has been very good thus far -- including easily building cross-platform native apps. It's just that the reality is there's still a lot of .NET Framework code.
The other big challenge for us is in delivering apps that run on customer systems. Doing the switch to .NET Core/5/6 means we have to decide on: increasing from shipping a 5MB to a 45MB app (runtime included); requiring .NET runtime is installed (and handling auto-update failures when it's not); modifying the installer to install if needed (again handling failures). This is all tons of work, and a tough sell when we have a multi-year backlog of bugs and feature requests it has to compete with.
I'm happy to hear I'm not the only one with this problem. For me, removing assemblies from csproj ended up being the solution to many of these problems (let them load implicitly).
Then there is .NET Standard, which was at version 1 and 2 (which are newer than .NET Framework 4.0 or 4.5? but have significantly fewer APIs available, and many classes are missing methods and properties that were present in .NET Framework).
Then there is .NET Core which reset the versioning scheme again?
Then there is .NET 5 which is newer than all of these, but is it actually fully supported on non-windows platforms?
Then you need Newtonsoft.JSON, and then you get to watch your entire project blow up because you have three different dependencies that use different versions of netstandard/netcore/netframework and the assemblies aren't compatible.
I really hope going forward there will be just one unified .NET 6 that works the same on all platforms and doesn't need a million different builds of the same nuget package.
Edit: And even after all this, deploying your app by just copying the .exe and .dlls to a pristine machine often fails, because the corresponding .NET framework runtime isn't installed. And then you need to be a lawyer to figure out if you can even ship the net framework installer to your customer or how to handle that. You would think Microsoft would have a better story to sell to developers as what should be "the way" to develop and distribute windows executables. It seems like the only way to really be portable is to use an ancient version of Visual C to write win32 directly, and link the corresponding msvcrt statically.
You don't "need" Newtonsoft.JSON. .NET now has a built in serializer which is much faster. But for compatability and some more advanced scenarios some people still need/prefer it.
Lastly .NET core apps (and .NET 5/6 going forward) have an option to produce a single file deployment. This includes the framework so you do not have to have it pre-installed on the target.
You seem to think that .NET Standard is a framework. It is a specification, like the C++ STL. Think of it as "the .NET Standard".
So it is obviously more than just a specification, since binary dlls can target different values of "netstandard" in addition to .net framework and .net core.
net5 was never an LTS release, so they are moving as fast as they can to net6. I do believe 6 will be much more stable.
I looked into Java, Ruby, C#, Dart, Kubernetes, Bazel, TypeScript, Flutter, Node, lots of CNCF stuff etc.
I have a bunch of interesting observations that I should probably write down somewhere at some point because I haven't seen people talk about them much yet.
However, one thing that kept coming up repeatedly is Microsoft is actually doing a much better job of thinking "beyond Windows" than I would have anticipated otherwise.
.NET is making its way into front end web apps now with Blazor, Microsoft has also just recently released something that they 100% do not market this way but I look at as almost a successor to .NET in some ways. The big difference is that it's language agnostic and it's entirely built around the concept of "distributed" applications. That came out of the Azure team I think and was based on everything they had learned about writing distributed / cloud native apps in the last 5-10 years. The project is called Dapr and was one of the cooler things I saw in 2020.
And the Azure team is, frankly, grossly incompetent. I've never used a worse application than the Azure dashboards. It is by far the absolute worst piece of software I have ever had to endure. Pathetically slow, shockingly bad UX and incredibly inconsistent.
But yes the Azure dashboard isn't great, however that's not relevant to .NET.
https://docs.microsoft.com/en-us/lifecycle/announcements/sil...
As context, AngularJS EOL's December 31st 2021. Silverlight debuted 2007, AngularJS 2010.
You can still use WPF and WinForms, but they have serious limitations and feel old. WPF for example makes G-SYNC switch to 60 Hz.
https://github.com/xamarin/Xamarin.Forms
https://github.com/dotnet/winforms
>There isn't a single first-party desktop GUI framework left that is actively supported and developed.
This is demonstrably false...
https://github.com/dotnet/maui
https://github.com/microsoft/microsoft-ui-xaml (WinUI 3)
WinUI 3 includes all of what used to the the UWP controls and Renderer but "lifted and shifted" out of OS updates and also made accessible to non-UWP (primarily Win32) applications in Project Reunion (and techniques such as "XAML Islands").
I’m pretty sure it’s no longer feasible to modernize even WPF. I just checked: It still has its G-SYNC issues, even on .NET 5.
Totally forgot about Xamarin too because it’s so irrelevant. But maybe MAUI will change that, who knows. I’ll believe it when I see it I guess.
They could be EoLed.
> There’s simply no alternative.
Are you seriously saying there are no alternatives to WPF or Winforms?
>However, they sure aren’t alive either. Development has been stalled for many years
https://www.youtube.com/watch?v=NDYcq1yKhiA
> and both are very old.
Linux is old.
> I’m pretty sure it’s no longer feasible to modernize even WPF. I just checked: It still has its G-SYNC issues, even on .NET 5.
Or because the issue only has 6 thumbs up on Github, so MS is spending its resources elsewhere.
> Totally forgot about Xamarin too because it’s so irrelevant.
Sorry, but you just read as so salty you're hard to take seriously.
And yes, since 2012 there were no major changes to WPF. And even these changes were small. The last truly major change came with .NET 4.0. So there was a decade of almost nothing, even while XAML evolved with UWP. It truly doesn't get any more dead than that.
Of course I'm salty. WPF promised a lot, delivered some then died. Xamarin wasn't even part of Microsoft back then. UWP is a joke. Microsoft neglected the "Win32" desktop for way too long. Now it lets the community do what it should've done ages ago.
Xamarin worked in 2016, as did UWP itself. Failing those Win32. Funny that you're arbitrarily throwing in a year, given that your OP didn't mention it, but whatever. If anything you can criticize MS for making too many UI frameworks lol.
You keep calling things that are literally still supported "dead". How about you use terms with real meaning, instead of just saying things that are literally untrue...
> It truly doesn't get any more dead than that.
> Of course I'm salty. WPF promised a lot, delivered some then died.
> We can certainly agree that neither WPF nor WinForms are dead.
Okay I'm done here. I wish you the best with your salt.
As for Blazor, I think you might be missing the larger point here that I am trying to make. But .NET is still this Windows thing in the minds of most people. That hasn't officially been true for a couple of years now but the .NET crowd are coming to things like Linux and Front End now for the first time.
There are about to be a lot more conversations between say the React crowd and the Enterprise app development crowd, I am actually excited to see what they can all learn from one another.
However their actual services are also pretty terrible. Pretty much everything takes significantly longer to deploy than the AWS couterpart. There are so many preview and deprecated features that it is often hard to judge exactly what feature set you are getting, this is often compounded by the fact that almost everything has multiple SKUs which also change available features. Azure AD RBAC is a bit of a mess, although its conceptually simpler than AWS IAM policies its just a pain to use in practice, and its often slow for changes in permissions to actually reflect. Azure VM disks are annoying to use too, you can't set the size of the OS drive at creation and extra data disks come unformatted. "Grossly incompetent" is probably an overstep though, Azure is very impressive, just not as impressive as its competitors right now.
Having said all that their are a couple places where Azure really shines in my opinion:
* Resource groups (GCP has a similar feature) allow you to more easily keep track of related resources across services. * Price transparency. Many (not all) services tell you up front hourly/monthly costs as you are deploying them through the portal. You don't have to track down a pricing page or calculator yourself. * Azure functions are amazing when using C#/.Net. A huge amount of the regular boilerplate is abstracted away into simple C# annotations so you can get a large % of business logic.
It is a web app though and I wouldn't see that AWS is necessarily ahead. The IAM setup is still very head scratching, although some things like SES setup with DNS are very easy.
Like someone else said, not really related to .Net
Dashboard takes 12s
An app service takes 40s
The deployment centre takes 22s
Opening a single deployment log takes 4.5s
Opening process explorer takes 30s
Opening kudu took 12s
There are definitely some things I like (completions in particular), but man do I miss the dotnet world.
I recently had an issue where I was using a third party closed source library in Swift. A particular function I was calling was sometimes bombing out, and because it wasn't marked as a throwable function, I couldn't put a do/catch around it. As a result, when it did, my app would just crash and there was nothing I could do about it.
I even asked on StackOverflow and was just told that this function can't be erroring out, even though it was lol
I've worked with other languages/frameworks as well over time and nothing is as nice to work with as dotnet.
https://docs.microsoft.com/en-us/dotnet/standard/memory-and-...
By some other measure it's not, out the three fastest: Java/C#/Go they're all pretty much as fast.
I'm working in production projects across all 3 languages now and Java and Go are way behind when it comes to producing a polished product as quickly as possible.
There are currently 244,641 libraries through nuget
https://www.nuget.org/packages
Ps. You can use libraries from f#, c# and VB.net. So as a .net developer, your statement doesn't make any sense.
You could have mentioned the different frameworks. But there is interop through the CLR between languages.
The parent post is correct that the third-party ecosystem (especially OSS) is sorely lacking in quality.
Like look at logging - logging in .net is SO anemic. Even with third-party libs, there are so many features missing that have been in java libs like slf and log4j2 for years, yet we have nothing close in .NET.
Hell, you could just pick a feature from spring and compare to what's available in .NET ecosystem, and you'll be sorely disappointed.
Being able to monitor levels via an administrative endpoint.
A decent rolling file implementation that can compress the archived files.
These are all things I've had to implement (on top of serilog, no less) in the past year.
log4j2 has these out of the box.
LoggingLevelSwitch?
> Being able to monitor levels via an administrative endpoint.
I wrote actuator endpoints for this one, was not hard but yeah.
> A decent rolling file implementation that can compress the archived files.
serilog-sinks-file has FileLifecycleHooks?. There's OOB serilog-sinks-file-gzip but you can also implement your own.
All the sinks for whatever you want.
Java simply has developer mindshare, the .Net developer stereotype is so rigid and engrossed that the pay difference between a .Net dev and their Java peer is usually around 20% if not more.
I don't see how this is a valid comparison. Java being paid better has nothing to do with scarcity of expertise.
Whether that explains part or most or all of Java dev pay premium is at least debatable. For instance, I would never make the same "throw a rock into a crowd" statement about finding a competent (but not expert) java developer. That alone means I would expect to pay some of a premium for finding them in that crowd.
What's the counter argument to scarcity? Alignment with better paying industries, weighted so heavily in that direction that it shows up as a premium for their developers? I mean, if you start getting into the conversations about the obscurity of domains, or supplemental education associated with Java developers either by coincidence or requirement, or general demand, I think you're still commenting about scarcity.
JavaWorld is bigger and Java developer count exceeds .net developer count, so the whole scarcity thing is a static explanation of a much complex dynamic environment. The intent here is not to complain about .net dev wages.
The problem I see with .NET now (I did some tinkering on it via Unity) is that even though some of it is "open source", Micorsoft's grip is still pretty tight on it. Or at least it feels like that.
Given Microsoft's history I find it very difficult to "commit" to using the .NET framework for something real, because I feel I will be bitten back with the 'proprietary' aspects of it as soon as I go to production. It's a sunk cost that I cannot afford.
And it is not personal 'hatred' or anything given that I use VSCode as an editor and TypeScript itself comes from Microsoft.
I wish Microsoft would donate .NET to some 3rd party open source foundation (like what happens with all Apache projects, or LibreOffice, the MariaDB foundation, etc).
Granted, the .NET Foundation is not the Apache, Eclipse, Linux or CNCF Foundation and it is dominantly financed by Microsoft, but there are relative important peers like AWS or RedHat involved.
[1] https://github.com/dotnet/runtime/issues/14537
I am not joking, I wish I was. The official C# debugger is not only proprietary, it’s also not licensed for VS Code versions compiled from source.
The rest looks cool, hopes are high for MAUI. But really man, forcing me to jump through a bunch of hoops just to get a (somewhat) working debugger ... That kind of a move is a remnant of the old Microsoft that absolutely needs to die for the new Microsoft to live on.
In addition, I'm not even sure if the telemetry on VS Code can be turned off. I think "yes", but never bothered checking while VS Codium was available.
Pretty important in case they fall back into old Microsoft‘s Embrace, Extend, Extinguish hab... oh, look ...
And it shows that they actually know what they’re doing. I don’t know what it is with Microsoft in particular, but they have really mastered the art of building user hostile applications. God, Visual Studio is a mess. I envy you.
You don't need to use any of the new C# features. You can still build and run C# 1.0 code today.
That’s like saying the English language has accumulated too many new words, and that impacts your speech.
You have that new guy that comes in and whant to rewrite everything with the new immutable feature.
If the language has 3-10 different ways of creating a class/object and every developer does it differently then it certainly impacts the productivity ;)
However, when I think back to my first line of code 30 years ago, i would also be scared of modern languages (however this applies to all actively maintained languages).
Don't intend to undermine the progress being made. Nevertheless here I am, migrating my dot net core 3.0 application back to Dot Net Framework 4.5.1 because I need my applications to run in all those Windows 8.1 (enterprise-internal) PCs without needing admin privileges to install dot net runtime. Since 4.5.1 runtime comes pre-installed with Win 8.1. So that is the version I target for all my new inhouse civil-engineering applications. There isn't much point bloating the application by 80+ MB just to make it self contained executable of dot net core version. After all, I need civil engineering to speedup, not fighting latest framework versions.
Bet they got hacked by now, as they should be. ;-)
https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
Unless you're sending your software to Mars, I say that saving 80mb of package bloat is not worth the engineering time especially for an OS that will be EOL in less than 2 years.
It really lowered my confidence, as I had comparatively less dev exp than him. It is good to see HN also sees c# as solid and good language.
Technologies should be debated by weighting their pros and cons, not with insults.
https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
Unfortunately I don't know much about it yet, it's not my area. Is it not sane?
Example: https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
Compared to Win32 not changing much since roughly 1995 or so, it's wild and constantly shifting, but compared to say JS frontend frameworks it's more stable than a lot of things people are doing in UI.
VS is nice, and one of the better IDEs but by comparison it is wildly overpriced.
At any rate, I've never found even the free Visual Studio Community to feel like a "basic editor."
I would be hesitant to join a company that isn't even willing to pay for vs professional.
The cutoff for Community is >5 VS Community users (not developers, either, as VS is also intended for testers, etc.), not 250, or >250 PCs in the org (not “developers” or “using VS Community”, just PCs existing in the org.)
Also what's the problem with VS Code? It's great for C#, and basically the mainstream choice for many other stacks like Go and Node already.
As long as you have a small number of total VSC users (not just on a team/project, but in an org; ≤5), and are in a small, luddite, or mostly-tablets org (≤250 PCs), and don’t have much money coming through (≤$1 million revenue.)
Otherwise, its only usable for open source work, academic research, and classroom training.
ReSharper isn't really needed although nice to have and actually not expensive. It costs less than a decent toolbox for a handyman.
It is the same use case. c# is slightly more modern and lib space is cleaned up. I do not know your age, but long time ago Microsoft messed with Java and got into huge legal troubles. As a consequence they developed .NET with the language designer who did before TurboPascal and afterwards Typescript. It is a bit more optimized for productivity but so are many other languages nowadays.
- why dotnet when java exists?
then GO came to the party and completely deprecated both java/dotnet, at least to me, i never looked back
- native AOT compiled executable
- 1 small file
- ultra fast compile time
- great ecosystem
for all my backend needs, it's GO
with dotnet everything feels heavy, ancient and bloated, msbuild and their xml for their projects, when you need to add some logic things becomes unreadable with XML logic, it's a mess, their json attempt wasn't great either, it was just JSON vs XML, they should have went with C#, build.cs, that's it
then you have deployment, it's MUCH MUCH easier than with java and with their jar/classpath bullshit, but it still is a bloat, it's a DLL mess
and let's not even talk about how everything is attached to microsoft
even their WASM effort isn't called WASM, you can't target a WASM module, it's BLAZOR, with MONO (why mono still exist when you have dotnet core? i have no clue, it adds to the bloat sentiment), wether you like it or not, it's BLAZOR, wich sucks because i wan't to handle hosting my way, from the beginning they vendor lock you
Also, its performance for low-level situations is not-bad due to not having to use gc due to structs, but it has place to improve on more complex use-cases with lots of garbage generated.
small single file publishing, native AOT executables, fast iteration time with quick build time, non existent cold start, simplicity of the whole stack
something both Java/Scala/C# fail to provide
for my low level needs i use C or D/Rust
for everything else it's GO
You should not pick up this stack for a startup or for any operation that involves less than three full-time backend developers. Iteration is so slow because all the bad OOPy practices and patterns from the 90s are still alive.
In just a month our intern made a web app using Django/Python and InfluxDb that would have taken us two months to implement.
It's sad because modern C# is an amazing multi-paradigm language. But the .Net ecosystem insists on partying like it's 1999.
Master Jonathan Channon (and contributors) have done an awesome job with carter! It’s definitely an awesome alternative. And I think with the stuff David Fowler has been working on to make hello world easier it will help make carter better too.
You should definitely use this stack for a startup or any operation with less than three full-time developers.
I've literally done this at three enterprise scale startups with just three devs (including myself). Working on the 3rd startup right now. The productivity of .NET, Visual Studio, and Azure is amazing.
Without knowing what exactly was being implemented it's hard to assess. However I think any halfway decent .NET developer can probably stand up a low-medium complexity MVC app in a couple of weeks. Granted you could go full OO-brain and use all sorts of patterns, service layers, onion architecture etc. to bloat the code. But you don't have to, if it's a quick throwaway you could simply do data access directly in the controllers (even using EF to abstract away any SQL writing).
Can you expand some more on what exactly the bloat is that you feel slows .NET development down?
A single django/influxdb project doesn't say much, and I bet you can find .NET devs who'll build that in a day.
Check this one out: https://www.falcoframework.com/
The coding patterns and practices are _very_ different in the F# space. I personally find them much cleaner.
As proof: https://github.com/AccelerateNetworks/NumberSearch
I've built on many stacks and although I agree that iteration speed is important; It has more to do with how you organize your project and the quality of your tooling than with the specific language/framework.
If you don't like the OOPy style, don't write in it. Pattern matching in C# is quite nice, and you can always mark you functions as static. As a bonus, simple functions are easier to test to.
In our startup products, we've built entire production sites with data stores, front-ends, payment systems, and the core product, in a few weeks.
I think it greatly depends on the skill level of the developer. In the end, "startup dev" is mostly tying together a dozen libraries, a datastore, and whatever your secret sauce product might be.