.NET 6 Preview 5(devblogs.microsoft.com)
devblogs.microsoft.com
.NET 6 Preview 5
https://devblogs.microsoft.com/dotnet/announcing-net-6-preview-5/
239 comments
True as long as you're not on an M1 Mac; right now it's a little bit of a mess since .NET 5.0 isn't fully supported and .NET 6.0 isn't quite ready for primetime (this release gets us a ton closer though). It's still doable, but with limitations; that said I still love my m1 air and .NET 6 will make it that much better/easier to do dev on it when it drops this Fall.
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.
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.
I run and develop on the x64 versions of dotnet core 3.1 and dotnet 5 on my M1 Macbook Air every day and don't have problems. It runs via Rosetta 2 translation, and probably isn't as fast or memory efficient as it could be, but I don't have major issues and it runs a lot faster and keeps my mac cooler than if I try to run in Windows on ARM in Parallels.
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.
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.
JetBrains has released a preview version of Rider that works reasonably well on M1. It is still buggy, but editor & IDE experience is good enough.
https://rider-support.jetbrains.com/hc/en-us/articles/440192...
https://rider-support.jetbrains.com/hc/en-us/articles/440192...
It's not an IDE issue; .Net 5.0 doesn't fully run on M1, aka you can't connect to the debugger and step into the code, among other things. VS Code is native on M1, and Visual Studio for Mac also runs via Rosetta2 (but I don't run it).
Did not know that about Rider, thx I'll def check it out.
Did not know that about Rider, thx I'll def check it out.
I can run and debug .NET 5 apps (on Rosetta) using both VS Code & JetBrains Rider.
You might have to update .NET 5 SDK to a more recent version.
You might have to update .NET 5 SDK to a more recent version.
If it has been a few years since you looked at C# or F#, it may be worth a look again now. Lots and lots of optimizations have been added in the last 5 years, and you can even use SIMD intrinsics directly now. By some measures C# is now the best overall performing garbage collected language (Such as The Benchmark Game)
One of the biggest things was the addition of Span<T> and Memory<T>, and their usage in underlying types within the .Net framework. While C# always had the ability to use raw pointers, these two types allow you similar performance characteristics without unsafe blocks (and frankly are near idiot-proof instead of being a giant foot-gun with pointers to managed types).
https://docs.microsoft.com/en-us/dotnet/standard/memory-and-...
https://docs.microsoft.com/en-us/dotnet/standard/memory-and-...
"By some measures"
By some other measure it's not, out the three fastest: Java/C#/Go they're all pretty much as fast.
By some other measure it's not, out the three fastest: Java/C#/Go they're all pretty much as fast.
Add in the massive standard library, project types, and overall productivity and it's the best platform available now.
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.
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.
C# is not even close to Java in term of libraries.
Which are missing? :)
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.
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.
Eh, I've been a .net developer for almost 15 years.
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.
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.
Can you give an example what is missing in e.g. Serilog?
The ability to change logging levels of either a category or all categories at runtime is one.
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.
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.
> The ability to change logging levels of either a category or all categories at runtime is one.
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.
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.
Nlog
Elmah ( .net framework)
All the sinks for whatever you want.
All the sinks for whatever you want.
Quantity of libraries is a poor metric. Like I said, the standard library in .NET covers a lot, and lets you make everything from CLIs to enterprise web apps. And when you do need 3rd-party code, there are plenty of commercial and OSS options to solve your problem.
It's not just quantity. Java benefits from all the major players that are using it. Quality of libraries is head and shoulders above anything you can find in .NET world.
I don't think so anymore. It used to be that way but .NET has massively changed in the last few years. Also many of the Java libraries are unnecessary in the .NET because of its strong standard library and core frameworks. There's no need for 20 different JSON serializers or webservers. In contrast, there's nothing even close to Blazor for Java.
Many of the .net libraries are poor afterthoughts of an existing Java library.
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.
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.
your average .net dev gets paid less than your average COBOL dev too, but I wouldn't say that informs us of much other than scarcity of expertise.
We used to say, "you can through a rock into a crowd and find somebody who can at least be productive on .net". Finding a stone cold expert on .Net is far more difficult, but for the average enterprise doing internal development weighing whether to adopt one platform or another, resource availability/scarcity matters.
The confusion here is perhaps that I jumped from B to F. The number of successful Opensource projects in Javaworld are astounding, and the OSS/Library work in .net is there but in comparison is miniscule. That feeds into the stereotype of .net developers being cookie-cutter VB-eseque Enterprise developers, which even feeds into their pay.
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.
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.
> your average .net dev gets paid less than your average COBOL dev too
I don't see how this is a valid comparison. Java being paid better has nothing to do with scarcity of expertise.
I don't see how this is a valid comparison. Java being paid better has nothing to do with scarcity of expertise.
The comparison was to illustrate that scarcity of expertise absolutely affects pay rate, notwithstanding other explanations.
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.
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.
I programmed professionally in .NET around 2003 with the initial versions. I liked it a lot and over the next years I tried to keep up to date about it on my spare time (I remember reading about LINQ development, the amazing CLR improvements, etc), all while I developed in Java, ruby and nowadays TypeScript.
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).
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).
Modern .NET is legally owned by the .NET Foundation. It is MIT/Apache licensed with the exception of some debuggers in VS Code (which propably conflict with VS itself).
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.
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.
Plus now we have Jetbrains Rider. So there's an excellent non-Microsoft IDE alternative.
Rider is no joke. If you haven't used it or gave up on it a few years back, give it a shot. There are a few things it can't do like attach to managed modules hosted in unmanaged processes but it's a joy to code in.
Still no any sane official library to support GUI in .NET CORE...
MAUI (.NET Multi-platform App UI) is the new thing in cross platform UIs.
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?
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?
I've never heard of it but I'll keep it on my radar. I love the idea of having a universal GUI using C#. I haven't done much android development, but I only know that it would be a tad less tedious if I didn't have to deal with android studio.
Maui is Xamarin.Forms. It is undergoing renovation to compete with React Native, Flutter and the self rendered stacks.
They are working on MAUI
https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
Not official, but I have had good experiences with AvaloniaUI, which sticks very close to WPF and is part of the .NET foundation umbrella. It inherits quite a lot of what made WPF mature and robust
What's wrong with WPF or WinForms? It's not cross-platform, of course. Or is that not sane enough? :-D
This was my question - anything like even windows Forms (which was a super easy way to get little apps together). Microsoft went crazy with their GUI approaches for a while - just straight insanity for little purpose that I could see.
.NET 5 supports WinForms and WPF, just Windows only.
Fantastic - I could never get the designer working right but after all the whiplash of microsofts UI approaches I've moved away so have no current experience. Good to hear its supported.
I find "whiplash" comments interesting. Microsoft has been relatively consistent since Vista, everything post-Vista XAML based. Some of the runtimes (which .NET versions are supported, what if any other languages are supported) and brands have shifted every five years or so, but there are lines of consistency from start to finish, and upgrade paths at nearly every stage, and XAML is generally XAML throughout. Things have generally been well supported for good maintenance lifetimes at each stage. (With the shortest probably being Silverlight, and its extended security support hasn't even expired yet, even if no one should have built new apps against it in at least five or six years now and no modern browser has supported running them.)
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.
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.
Have a look at this: https://docs.microsoft.com/en-us/dotnet/maui/
Example: https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
Example: https://devblogs.microsoft.com/dotnet/introducing-net-multi-...
Did you try uno?
As a java developer for years it is amazing to see .net basically become the best cross platform framework.
I moved from C# to Java project. I preferred C# Syntax but amazed by the number of Java libraries. However I've found Java world full of neck-beard developers that make everything complicated. Spring is toxic - the learning curve is steep and half the devs dont understand it well enough which leaves a huge mess.
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.
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.
Toxic? Isn't this word too strong maybe? Spring provides consistent patterns and solutions for many things and their solutions is usually good (vary between mediocre to great). Learning curve is steep-ish when you start but quite a smooth ride later. It's maintained, reliable, not buggy.
Spring is an acquired taste, and many people don't like it because they don't know the right patterns, so I agree with you and think the parent is exaggerating.
You're both right. I agree Spring Boot is great if you know it well and are knocking out micro-services. If you have a ball of mud like my current project with mixes of XML config, Attribute config and people rolling their own stuff it really isn't adding any value.
I don't code very much Java or C#. I've tried to get into Spring because I wanted to save time but it was too complicated for my patience. I also evaluated ASP.NET and it seemed significantly more convoluted.
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.
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.
>evaluated ASP.NET and it seemed significantly more convoluted
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.
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.
You may also be interested in taking a look at [quarkus](quarkus.io) in that case. It's a relatively new platform developed by RedHat that focuses on cloud usability, performance and developer joy, while using well-established APIs like JAX-RS, JPA or microprofile
Oh yes I've found a number of good microservices for both languages. I'm just astounded by how complex Spring and ASP. Net are. Though to be fair I also find Rails too complex.
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.
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.
Rails and Spring Boot both scratch a similar itch. Out of the gate, a brand new project spins up and can return output (JSON or HTML) with almost zero config. The developer is responsible for augmenting that project with controllers/services/models/etc. What this leads to are dark corners. This is fine as not every developer needs to understand all of those dark corners. But it also leads to blind dependence on the framework and its libraries. And when something goes wrong, they can go REALLY wrong. That said, Spring implements some great patterns out of the box. And spinning up a highly performant microservice with JWT auth, security, an okay ORM (I don't hate Hibernate like a lot of folks do) is cake!
If someone is escaping Spring for it's verbosity and complexity JAX-RS and the Java EE standards aren't that much better IMO.
Asp.net is very well documented. I agree that authentication is a mess and the framework slightly over-engineered, but it's still very doable to use as a hobbyist.
Java GC bad? It is the state of the art (though it has multiple ones, but G1 and ZGC are the best for different workloads), no other runtime has a better one, with V8 coming somewhat close.
> neck-beard
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.
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.
Hair on your neck makes you look unkempt. I think it's the main issue.
It is also signals a package of personality traits:
* 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.
* 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.
So the problem is that unkempt looking people have created code that this person has to deal with??
Oh, and every single person who has hair on their neck looks unkempt, without exception, am I hearing that right?
Sure, OK.
Oh, and every single person who has hair on their neck looks unkempt, without exception, am I hearing that right?
Sure, OK.
For what it is worth, it isn't a neologism to this thread it's a (insulting) slang term for certain types of pedantic nerds in relatively common usage on the internet going back to early internet history (some of the earliest recorded usages were in the early 2000s).
https://en.wiktionary.org/wiki/neckbeard
https://en.wiktionary.org/wiki/neckbeard
> Oh, and every single person who has hair on their neck looks unkempt, without exception, am I hearing that right?
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).
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).
It's both hilarious and jarring for me to have found myself reading a comment about ear hair grooming and the next snaps back to a comment about swift, c#, and Rider. :D
> Hair in other places is considered equally distasteful...
...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.
...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.
> 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.
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.
Yeah and the same goes the other way too. Don't be surprised if the heavily bearded middle eastern guy won't invest with men who they think look like women or who have made known their opinions about grooming. Don't be surprised if you don't get invited to parties or if the guy working on your car or skippering your boat screws you for being a stiff.
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.
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.
[deleted]
Any particular reason for using ParallelOldGC with Java 16 ? There are other options that should fare much better.
I've used .net almost exclusively backend over the last decade and recently had to take over a spring project.
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.
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.
Try ZGC, sub 1ms pauses
https://malloc.se/blog/zgc-jdk16
https://malloc.se/blog/zgc-jdk16
The main issue with C# is that it's getting very bloated, they're adding major features every release, good luck keeping up with that.
As opposed to all the other languages that also add features with every release?
You don't need to use any of the new C# features. You can still build and run C# 1.0 code today.
You don't need to use any of the new C# features. You can still build and run C# 1.0 code today.
Take a look at F#. It's a superior language and doesn't add new features like C# does (which is mainly stealing from F# anyway). Also, Elixir is a language that is very stable from release to release.
I keep hoping they'll finally steal type providers for c#, though you could argue source generators are at least a first step.
Yes and no. Some of the features are really welcome, some are ghetto (like the ref performance ones) and some indeed change the visual look of the language a lot (pattern matching). It's ok to keep up for someone already knowing the language but for a newcomer it's indeed super scary.
On the other side, it is never easier to learn C# than now. The amount of ceremony removed in C#, the university educated functional programming patterns, the universal availability on operating systems and the quick setup (including eg. notebooks) are just some things.
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).
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).
Can it really be called “bloat” if the features are basically invisible unless you explicitly compile an app with them?
That’s like saying the English language has accumulated too many new words, and that impacts your speech.
That’s like saying the English language has accumulated too many new words, and that impacts your speech.
Yes because then people have 3 different way of doing the same thing.
You have that new guy that comes in and whant to rewrite everything with the new immutable feature.
You have that new guy that comes in and whant to rewrite everything with the new immutable feature.
I’m seeing this at work right now. New devs asking which way to initialize an object, the difference between record, class, and struct, how to use nullable types, etc. I can’t help but feel C# is getting too complicated for its own good.
If you have 3 teams members speaking 3 different languages then it certainly impacts their communication.
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 ;)
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 ;)
We need the esperanto of programming languages!
The goal is to know more and more about less and less...
I am a C# and ASP.NET Core developer.
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.
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.
I'm a C# and ASP.NET developer.
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.
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.
I’m going to be the voice of balance and say .Net and associated tooling is fine, but Azure should be avoided: never a more frustrating experience have I had.
I must admit I'm a little confused at this (but not downvoting), I think the speed of development is probably equivalent but with the benefit that as the codebase grows you at least have types to make scaling easier but having not tried Django I can't really give a fact-based view.
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?
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?
I've used .NET stack in my last 4 startups, and it's let me (alone or in a small team) compete with much bigger companies by building faster and more thorough projects.
A single django/influxdb project doesn't say much, and I bet you can find .NET devs who'll build that in a day.
A single django/influxdb project doesn't say much, and I bet you can find .NET devs who'll build that in a day.
The DI obsession in ASP.NET is a little weird, and I'm not a great fan of how magic it makes everything. You don't have to do things that way, but if you don't, you'll be fighting against the grain the whole time, because everything comes packaged as middlewares and components and services that you're supposed to just plug into that framework.
DI frustrates me every time I have to do it, or touch code that uses it. It’s all magic layers and unnecessary abstractions over the apparently heinous crime of “passing arguments down into functions” and setting it up feels like the programming equivalent of performing a sacred incantation.
I completely disagree. In fact, my friend and I used .NET our last Startup Weekend event and were the only team to build a complete product against teams using Python/Ruby/NodeJs. You can in fact write C#/ASP.NET in a rapid hacked together way similar to Python if you want.
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.
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.
Have you tried F# and one of the libraries that sit atop ASP.NET Core primitives?
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.
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.
I used this stack to replace a Django/Python app that was built over 2 years by another dev in 2 weeks. We regularly have 1 hour turn arounds between when an issue/feature is filed on Github and when a new build is live with that code. The self-contained deployments have made it simple to deploy this app, and now its supporting apps, to our linux-based cloud instances.
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.
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.
Totally different experience here, been a dev for 20 years tried multiple things and .net is so so so much productive and straightforward it's the obvious first choice. Sold my last project (1 man) to a company now worth 500M+, running strong on .net+EF in pgsql without issues.
How about using alternative web frameworks? e.g. Nancy, coupled with similar alternative ORM, etc...
Carter is probably a better choice than Nancy nowadays, but in any case the new minimal api features coming in 6 look to provide a really excellent way to build elegant web APIs without large framework overhead.
We kinda stopped developing Nancy when .NET core came out because MVC became more opt in rather than opt out, and was more performant. (Prior to .NET Core, Nancy could handle more RPS over .NET Framework mvc)
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.
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.
The only problem with .NET is that the best tooling is quite expensive. Visual Studio with ReSharper or JetBrains Rider are both up there in price and MonoDevelop didn't work with .net core last I tried (2 years ago). That kind of leaves you with VSCode or a plain old editor (vim/emacs), but you really don't want to write C# code in a basic editor.
Visual Studio Community has been free for years and lets you build anything. VS Pro and Enterprise are for bigger teams/projects with some advanced features but nothing you absolutely need.
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.
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.
> Visual Studio Community has been free for years and lets you build anything.
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.
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.
At a quick googling, the basic VS Pro subscription costs $45/mo. That doesn't seem unreasonable to ask, even from a small company with $1M annual revenue.
So? The claim I was addressing was about what VS Code Community allows for free, not about the reasonability of the price of the more functionally limited, but less restrictively licensed, VS Code Pro.
There is no such thing as VS Code Pro. And Visual Studio pro/enterprise include even more functionality, not less.
You can get very far with the free VS Community and can even use it commercially.
ReSharper isn't really needed although nice to have and actually not expensive. It costs less than a decent toolbox for a handyman.
ReSharper isn't really needed although nice to have and actually not expensive. It costs less than a decent toolbox for a handyman.
Visual Studio Community or even VSCode with Omnisharp is a very solid choice. You can easily write C# code of any complexity without any extra bells and whistles of Rider because the language itself is that good.
$500/yr is expensive for a professional developer?
Sure, in many parts of the world that's quite a bit of money. For example, it's more than 50% of what I spend on food per year.
You spend about for food 1$ a day? Where do you live? That looks cheap.
Yes, after looking up average salaries and doing a quick currency conversion, USD 500 is around 60% of a whole month's salary for an average software developer.
The median salary of a software developer in Mexico for 2020 was of $1750 USD gross, so after Taxes is around $1400. $500 USD a year is crazy expensive.
It's not outrageous but it's not a trivial expensive, either.
It really depends on your 'license' with them. For me as an individual it is basically 'free'. As the community edition is basically pro in all but name. But for a corp env it is like you say it is not 'trivial expensive'. They mowed down everyone else because it was that choice for a long time. You were talking 20-30k per year per dev in the 90s for some stacks. 150-500 per year was a bargain by that metric. But now there are 5 other IDEs you can pick from that are either cheaper or free. In some cases for some langs the cheaper ones are better in all respects. In some cases they are charging anywhere from 500-9k per year depending on how you buy it. Why would I start a greenfield project with VS in that sort of env, unless I was already a 'MS shop'?
VS is nice, and one of the better IDEs but by comparison it is wildly overpriced.
VS is nice, and one of the better IDEs but by comparison it is wildly overpriced.
VS Pro Edition is $45 a month. Hardly would call that overpriced.
It's also free if your organization makes less than $1M.
https://visualstudio.microsoft.com/vs/community/ is free and is pretty complete for a developer.
Free for some in some cases, depending on the number of users in your organization, the number of computers and some other things. They got rid of the actually free but less complete version (Express).
You can use community for a commercial project as a developer.
I would be hesitant to join a company that isn't even willing to pay for vs professional.
I would be hesitant to join a company that isn't even willing to pay for vs professional.
Yeah, >250 developers or >1mill revenue and _not_ being willing to pay for developer tools would be an enormous red flag :)
> Yeah, >250 developers or >1mill revenue and _not_ being willing to pay for developer tools would be an enormous red flag :)
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.)
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.)
What about 1 developer and >250 computers in a different part of the organization? The VS Community license doesn't permit this case. The discontinued VS Express did.
Interesting. I've been in and out of the .NET world over the last 15 years, and I've used Visual Studio. If my employer sprang for MSDN, I'd use Professional, but for most projects, Community worked great. I did have access to ReSharper at one point, but I didn't end up using most of the features. I've found in my own workflow, you don't need any of those things, though I'm sure some people rely on them for some personal efficiencies.
At any rate, I've never found even the free Visual Studio Community to feel like a "basic editor."
At any rate, I've never found even the free Visual Studio Community to feel like a "basic editor."
I don't have any .NET background or anything even particularly MS specific. However, I spent most of 2020 just playing tourist between different development / devops communities to get a feel for what are the main ideas, challenges, core truths etc in each.
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.
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.
Given their history of abandoning front-end frameworks, I wouldn't put too much faith into Blazor.
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.
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.
I'm going to ignore the "Shit HN says" vibes on this one for the most part, but I suspect that Microsoft and the Azure team specifically might have some relevant thoughts about building distributed systems regardless of if you like their dashboards or not.
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.
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.
I'd agree with them that the portal is terrible. Multiple times a day I get blank page errors, where the page is completely blank except for a single non-sensical error message in black text.
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.
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.
Hi, I work on the portal team. Would you mind sharing what the issue is you're seeing?
Hi, can you guys look at the portal security? In some corporate accounts most people have limited access to do stuff, but it is all enabled; you spend a few minutes to create a new resource just to get an access error after you submit, when it should be disabled (displayed, but disabled) if you cannot do it, do the access check before not after. There are so many options we never know which one is enabled and which one is not.
Hi, thanks for replying. I'll send you a message on Monday when I get back to work to recreate it.
I think I might agree that the Azure portal is slow, has bad UX and is somewhat inconsistent but I very much suspect that with the pace of change in cloud systems, it is very likely to be driven by some database so that it is easy to create new config pages for each new product without having to write an entire new web app.
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
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
What specifically do you find slow? I work on the portal team and would love to hear specifics that we can go chase down.
Here are some random things I clicked on:
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
What did they abandon? Silverlight? That went the same way as Flash because plugins were killed by browsers and mobile. Blazor is much different and a core part of the web stack. Considering you can still run WebForms apps written in C# 2.0 today, support and backwards compatibility is actually a strength of this ecosystem.
But yes the Azure dashboard isn't great, however that's not relevant to .NET.
But yes the Azure dashboard isn't great, however that's not relevant to .NET.
FWIW Silverlight is _still_ being supported. EOL is October 12, 2021.
https://docs.microsoft.com/en-us/lifecycle/announcements/sil...
As context, AngularJS EOL's December 31st 2021. Silverlight debuted 2007, AngularJS 2010.
https://docs.microsoft.com/en-us/lifecycle/announcements/sil...
As context, AngularJS EOL's December 31st 2021. Silverlight debuted 2007, AngularJS 2010.
Everything. There isn't a single first-party desktop GUI framework left that is actively supported and developed. UWP is of course still available but modern apps have failed.
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.
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/dotnet/wpf
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/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...
Well, yes and no. We can certainly agree that neither WPF nor WinForms are dead. How could they be? There’s simply no alternative. However, they sure aren’t alive either. Development has been stalled for many years and both are very 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.
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.
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.
> How could they be?
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.
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.
What is the alternative then? How would you have created a new Windows desktop application in 2015? 2018?
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.
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.
> How would you have created a new Windows desktop application in 2015? 2018?
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.
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.
Also both in very active development:
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").
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").
Link to Dapr: https://dapr.io/
I'm a long time dotnet guy, but I've been working with Swift/XCode recently.
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.
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.
What library and what function? Chances are, the developer will pop up on hacker news and help you out!
I wonder when whey will make the debugger work with non-proprietary versions of VS Code.
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.
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.
Don't know how JetBrains did it but Rider's (their C# IDE) debugger works excellently. Haven't used VisualStudio for years actually.
As far as I know they have (somewhat, they do use MSBuild) completely developed their own .NET tooling ecosystem (ReSharper being the most prominent example).
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.
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.
just out of curiosity, what's your use case for using a version of VS Code compiled from source?
Using a program which is advertised as non-proprietary as such. Not trusting Microsoft to be nice.
Pretty important in case they fall back into old Microsoft‘s Embrace, Extend, Extinguish hab... oh, look ...
Pretty important in case they fall back into old Microsoft‘s Embrace, Extend, Extinguish hab... oh, look ...
Not gp, but think about it that way: what makes necessary for VSCode to have a proprietary version and key plugins?
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.
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.
Here's hoping .NET can some day shake off its Windows exclusivity stigma, as I've been writing pretty interoperable C# code for the past 3-4 years or so, and it's been a joy. Night and day compared to Java, at least.
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.
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.
It's not really about the exclusivity, more so its about being driven by MS and their internal needs and their internal timelines, and nothing will change this. This is not a criticism of MS, .NET is their platform to support their products, it's just a reality. It's the same problem with Swift trying to escape the Apple ecosystem while ultimately being driven by Apple's needs.
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.
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 think this is perceived much worse than it is. I work in a polyglot company. .NET had never limited us compared to the Java, Python, C++ or JavaScript languages we have also in use.
.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.
.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.
I might be in a minority because I write a lot of .NET which in production is almost exclusively deployed on Linux. It's absolutely viable, performance is great, and tool support is fantastic. We agree so far.
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).
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).
Up until very, very recently .NET was absolutely useless on non-Windows platforms, only supporting the bare minimum APIs you need for web apps. It's still not very useful on non-Windows platforms.
Out of curiosity, what is missing in .NET that isn’t being prioritized by Microsoft and that other languages provide?
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.
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.
Proper AOT compilation and better handling of low level COM APIs.
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.
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.
>Out of curiosity, what is missing in .NET that isn’t being prioritized by Microsoft and that other languages provide?
First class support for native code. I'm not too sure where their IL stuff is going anyway.
First class support for native code. I'm not too sure where their IL stuff is going anyway.
The team quite systematically ignores messaging (as in RabbitMQ and friends). HTTP is covered in all aspects but messaging really lacks behind.
What's lacking? I'm sorry, I last fooled around with message queues like over ten years ago (and it was MSMQ and IBM MQ), but was recently working on a hobby Rpi project where I came close to dinking around with RabbitMQ via Python. It looks like RabbitMQ has a library for .Net. Or are you talking about how the native library System.Messaging is not generic enough to go outside the bounds of MSMQ still?
Truly not challenging anything you're saying, just curious to know what you'd prefer to see.
HTTP has a huge infrastructure for translating http request into endpoints. With all the bells and whistles. Nothing is there for messaging. You can get a library for everything but there is no focused stack for processing messages.
SignalR can be used for some applications, but “messaging” is a pretty broad category of different solutions, and I’m not sure what you’d want baked into ASP.NET to accommodate that. HTTP is standardized enough that basically everybody is doing it in very similar ways, but many pieces of a web application are better left for libraries to support.
Is there another mainstream platform with better messaging support without needing libraries that you can name as an example?
Is there another mainstream platform with better messaging support without needing libraries that you can name as an example?
Agree with what you said. It is a complicated problem.
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.
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.
I mean, HTTP is a protocol with huge footprint/mindshare/utility to put it mildly. Messaging has.. who can name it? AMQP. I think it would be brilliant if System.Messaging was reoriented to AMQP, especially since MSMQ is not coming back. It's a bit lame that the namespace is locked into to a proprietary and EOL product, for sure.
I’m not sure I follow; why would/should Microsoft make libraries for projects they don’t own?
Because there are two kinds of microservices... HTTP ones and messaging ones. There is a gap.
Could you explain the difference between the two, for nonweb devs?
It is mainly about non functional needs. A message queue you would use when you have no need in synchronous results, peeks in traffic or want a higher reliability.
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.
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.
MassTransit, NServiceBus, ReBus - you have plenty of options.
2nd that, couldn't quite put my finger on it, but this says it nicely.
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.
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 it comes to what it is tailored: there are two VM models: CoreCLR optimized for speed and throughout and MonoVM optimized for aot and small size workloads (aka apps and webassembly).
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.
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.
.NET is not tailered to
XBox. UWP (which runs Xbox apps) is lacking now 2 versions behind .NET itself.
When you wanted to address unity, that is far more than Xbox.
And gaming is a maybe 20% share of .NET.
When you wanted to address unity, that is far more than Xbox.
And gaming is a maybe 20% share of .NET.
This is almost entirely wrong.
.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.
.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.
That is mostly caused by the internal politics that .NET belongs to DevDiv while C++ has always been part of WinDev.
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.
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.
I've been playing with the AoT compiler and it is decent, especially if you strip the binaries to get 10-20MB files.
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)
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)
Java is miles ahead in terms of cross-platform support. .NET applications may be running fine on other operating systems (I write them at $DAYJOB and they mostly do), but the development tooling is absolutely incomparable across OSes. As long as .NET is being developed and pushed by Microsoft, the situation won't change, because it doesn't align with their incentives.
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.
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.
I use jetbrains rider. Tooling on linux is just as good as Windows. Developing .net is far more enjoyable than Java.
Yea Jetbrains Rider is fantastic. I'm assuming the parent never tried it. Seeing as it is essentially IntelliJ the comparison to Java tooling seems ironic.
I second this. .NET core works flawlessly on Linux and JetBrains Rider (and on Mac, which is what I develop on). The standard libraries and ASP.Net core are really well designed and a joy to work with.
Seconding Rider. I use Windows and still prefer it to VS.
On an IDE written in Java....
Rider is a solid mix of C#, F#, Kotlin, and Java (and likely more). The R# engine is a very large .NET codebase, and the F# plugin to that is written largely in F#. So it's a little more complicated than whatever the shell is written in.
.net is catching up very quickly in cross-platform support.
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.
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.
Where is this FreeBSD quote coming from? Link please, I tried to google it without success.
VS Code is available everywhere and can even connect to remote environments. Visual Studio is on Windows, and there's a Mac version that's slowly getting better.
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.
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.
It's been a while since I looked at .Net, but last time I checked it was inferior in terms of multi-platform tooling to many languages.
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.
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.
Take a look at Rider, it’s relatively recent, it’s possible you missed it. Basically, it’s Resharper embedded in an IntelliJ IDE, and it’s superb.
Well, perfview, for one. I have to keep a Windows VM nearby just for that thing. It doesn't come in handy every day, but is absolutely indispensable when it does. They have a shitty Linux port which basically doesn't work and receives almost no development.
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.
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.
Use perfcollect for Linux: https://github.com/dotnet/coreclr/blob/master/Documentation/...
Since that is adapted to use Linux specifics :)
Since that is adapted to use Linux specifics :)
If you're writing Java, you're going to use IntelliJ (unless you're a masochist). Conversely, if you're writing C#, you'll want to use Rider.
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.
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.
When I write Java I actually don't ever touch InteliJ because I am not a masochistic.
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,....
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,....
> Conversely, if you're writing C#, you'll want to use Rider.
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.)
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.)
And that is the thing right! When you stop understanding the tools, you are screwed. I (as a .NET fanboy) prefer CLI tools anytime over some VS Azure toolbox no one understands).
Azure CLI just works fine without VS.
Azure CLI just works fine without VS.
[deleted]
You can't please everyone all the time.
Rider is my daily driver - no matter what OS I use (primarily Windows/Mac and occasionally Ubuntu.)
Rider is my daily driver - no matter what OS I use (primarily Windows/Mac and occasionally Ubuntu.)
the miles you mention are one thing, but performance was always more important to me.
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.
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.
I wouldn’t call it performance, but control. The Java and .NET world focus on different things - the JVM has a very very advanced JIT compiler and due to the programmer not being able to specify all that much about certain aspects of code it has a better chance of optimizing it (similarly to how SQL queries can be made very fast precisely because they are at a high level of abstraction). The CLR provides more control at the expense of less optimization opportunity. This escape hatch is really useful for some programs, but not all of them would benefit from it.
[deleted]
I know. The first time I deployed a .NET application to a box running Linux it was like a great disturbance in the Force :-)
> interoperable C# code for the past 3-4 years or so, and it's been a joy. Night and day compared to Java, at least.
Can you give an example of this interoperability, please? Also -- what was the difference compared to Java that you noticed?
Can you give an example of this interoperability, please? Also -- what was the difference compared to Java that you noticed?
I've mostly been writing backend code which pretty much works just the same whether deployed on Windows and Linux, that's interoperability by default.
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.
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.
It's interoperable by default, unless you add a Windows-specific library like WinForms.
eh, Windows Forms is the default GUI library, this means relying on third party libraries if you want to write cross-platform desktop apps.
There isn't really a "default" GUI library at this point. WinForms and WPF are both rather equal in support. (Arguably WPF gets far more updates than WinForms, most months.)
MAUI (in .NET 6+) will be a first party library for some types of cross-platform desktop apps.
MAUI (in .NET 6+) will be a first party library for some types of cross-platform desktop apps.
The default "GUI" library for .NET Core has always been web.
What's the cross platform GUI situation like on .NET? I know MAUI won't work on Linux, and no Linux support is a deal breaker for me.
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.
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.
Perhaps developers should still consider .net as windows-only. Given how the large the runtime is and it's creator's reputation for pushing malware, I would not dare run .net core directly in any of my machines, and many non-windows users would probably feel the same. I don't think I even have the option in openbsd. Targeting Linux though I guess makes sense because of containers.
They played games for so long with keeping it closed source and then only opening parts of it to ECMA and then advocating Mono before finally opening more parts of it. I wanted to play with LINQ back then and couldn't. So non-MS people said screw it and moved on.
There is ongoing work[1] on porting it also on BSD systems. I hope it will help to make it even more portable in the long run. See also other FreeBSD issues[2] that need to be solved for complete support. Or the same for NetBSD[3].
[1] https://github.com/dotnet/runtime/issues/14537
[2] https://github.com/dotnet/runtime/labels/os-freebsd
[3] https://github.com/dotnet/runtime/labels/os-netbsd
[1] https://github.com/dotnet/runtime/issues/14537
[2] https://github.com/dotnet/runtime/labels/os-freebsd
[3] https://github.com/dotnet/runtime/labels/os-netbsd
A perspective from a non-CS engineer.
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.
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.
Why not use .Net core... 3.1 I think? You can build a standalone exe that doesn't require the runtime on the end user machine.
https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
https://docs.microsoft.com/en-us/dotnet/core/deploying/singl...
You might not need to do this. You can roll a fully self-contained distribution that will work for this OS with options to dotnet publish.
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.
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.
If using the self-contained deployment isn't an option then this is the correct solution. I don't see what the problem is. You can't always use the latest and greatest. I often had to use .NET 4.0 because it had to run on some way outdated systems where client IT was refusing to install updates.
Bet they got hacked by now, as they should be. ;-)
Bet they got hacked by now, as they should be. ;-)
Have you considered Blockpad (http://blockpad.net) as a platform for your applications?
This is a great time to start testing the new features of .NET. Anyways, I can't get enough creating new desktop apps on win forms.
The difficulty for me as a FT .Net Dev is the pace of development is hurting quality. There are many edge cases and bugs that get introduced as things change from nuget to dotnet pack, from netstandard to netcore, from net core 3.1 to net 5.
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.
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.
This exactly! The branding and versioning of .NET is a complete disaster. There's .NET Framework (where even simply getting the current runtime version requires several convoluted hoops, since System.Environment.Version has gone the way of browser user agents and frozen itself at "4.0.30319").
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.
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.
Yes .NET 5 is supported on all platforms. It is the future of .NET Core. They dropped core because they wanted to make it clear it is the one true dotnet going forward. It actually will greatly simplify things going forward. .NET standard will no longer be necessary because there is only .NET 5 onward.
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 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.
> 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).
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".
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".
The newtonsoft json dlls (and other) distribution contains different dlls in different folders called "net45", "netstandard2.0", "portable-net40+sl5" etc.
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.
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.
Higher netstandard versions have more APIs. For performance or compatibility reasons, you can also target specific frameworks.
I agree, though I wouldn't say it's the pace of development so much as the change in approach.
.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.
.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.
> 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.
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).
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).
> Net 5 isn't even finished and they are already previewing 6
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.
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.
Even worse, this week I ran into an issue which was answered with "just use .net 6" which isn't even out of beta yet.
So what do people generally use .NET and adjacent languages for? Is it pretty much the same use cases as Java?
Yes. But better .. okay kidding.
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.
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.
When I first started development work (my background was in engineering math), couple of my colleague mocked me for liking c# and .net. They responded by saying, “I don’t want to reply to that because I don’t want to say anything insulting”. This was in regard to good backend language for crud web server with somewhat complex business logic. Responder worked in my team, and I was their manager.
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.
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.
That was very unprofessional and disrespectful from them.
Technologies should be debated by weighting their pros and cons, not with insults.
Technologies should be debated by weighting their pros and cons, not with insults.
the problem i always had with dotnet was
- 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
- 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
Go is ridiculously verbose and it is funny when Go advocates call Java that. The “C with GC” is sort of true about it in terms of no abstraction power resulting in one having to write many times more code with real redundancy.
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.
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.
verbosity is the least of my problems
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
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
Does anyone have experience using .NET for serverless? How do start up times compare to something like Go or Node?
Go AoT compiles into machine code so it should have very little startup time, anecdotally I’d expect .net to be in between go and Node.
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....