Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET 8

devblogs.microsoft.com

Post reply on HN
Print view View original

331–340 of 374 posts

Re: .NET 8

#331

Post by SideburnsOfDoom »

willsmith72 wrote: post #69
SideburnsOfDoom wrote: post #34

Earlier quoted context omitted.

As a long-term happy .NET user; you should use what makes you happy.

fair enough, I'm happy with what I've used through my career, but I've never been in a situation using .NET and only tried a hello world. I think you can always learn something from trying totally different tech, so i'm game to try it for a personal project, but want to hear what people love about it so I can dig in the right direction.

IDK, you can find many basic online articles about "what is C#" and "why C#".

What are you comparing C# and .NET to?

If you prefer loosely typed languages such as Perl, Python, JavaScript then you will find C# too picky about types. Personally, I prefer to have the discipline.

If you are doing low-level stuff where a GC is out of the question then you would prefer C++ or Rust.

But in the in-between space; for most web or business apps, it's very good.

Re: .NET 8

#332

Post by croes »

WorldMaker wrote: post #295
croes wrote: post #137

Earlier quoted context omitted.

No problem with LTS but why the confusing name scheme. Just like their Xboxes.

The name scheme was confusing only during the "overlap" period. At this point again you can strictly pay attention to version numbers: 8 > 7 > ... > 4 > 3 > ... Any version current LTS. The rest of the "naming scheme" is dead weight.

Why don't I want to use .Net Framework 4.8?

It will presumably have longer support than .Net 8.

Re: .NET 8

#333

Post by GordonS »

Const-me wrote: post #294
GordonS wrote: post #171

Earlier quoted context omitted.

> I had high hopes for it become the best story for crossplatform development, it still feels like the crossplatform is held by ductape. Sorry to be pedantic, but it's cross-platform GUI that still doesn't have a good, officially supported story. For non-GUI apps, cross-platform works very well! I've deployed a range of apps to production across Windows, Linux (both x64 and ARM), and Docker on Linux too (also both x6…

> cross-platform GUI that still doesn't have a good, officially supported story Yeah, but in the meantime there’re decent unofficial options. Once I compiled NanoVG into a DLL, consumed with C#, and implemented rich GUI on top of that. Worked pretty good overall. Eventually I’ve patched NanoVG for optimal font quality on low resolution touch screen of my target Linux device: https://github.com/Const-me/nanovg

Interesting, I haven't come across NanoVG before!

Re: .NET 8

#334

Post by lewispollard »

pdntspa wrote: post #11

I just wish its cross-platform UIs weren't such a mess. Particularly with its MVCish implementation, it was like it couldn't decide what it wanted to be. I really really wish there was a good, straightforward desktop GUI for .Net that simply worked crossplatform and wasn't a complete pain in the ass to program.

Not a conventional option, but I've built a few (non-game) GUI applications using Godot game engine + C#. Works great, intuitive once you get the hang of the UI system, fully cross platform (for 3.x anyway - Godot 4 still has a few unsupported platforms - android, web, ios - android support is ready for next release, ios has a PR that I haven't checked up on but I believe it was also nearly ready. Just web that is lagging last I checked.)

Re: .NET 8

#335

Post by Const-me »

GordonS wrote: post #333
Const-me wrote: post #294

Earlier quoted context omitted.

> cross-platform GUI that still doesn't have a good, officially supported story Yeah, but in the meantime there’re decent unofficial options. Once I compiled NanoVG into a DLL, consumed with C#, and implemented rich GUI on top of that. Worked pretty good overall. Eventually I’ve patched NanoVG for optimal font quality on low resolution touch screen of my target Linux device: https://github.com/Const-me/nanovg

Interesting, I haven't come across NanoVG before!

NanoVG is a 2D rendering library built directly on top of OpenGL or GLES.

Modern rich GUI needs much more than a renderer, but amount and development cost of that “much more” varies depending on GUI complexity. The device I developed is rather simple: low resolution screen, touch is the only input, English localization only, that’s how I was able to deliver in reasonable time.

For more complicated GUI I’d look for different technologies. Maybe QT, despite the high price.

Re: .NET 8

#336

Post by bad_user »

JAlexoid wrote: post #228
squeaky-clean wrote: post #184

Earlier quoted context omitted.

If you spend 20 hours fixing something that wouldn't occur with the paid toolchain, at what price does it become worth it to skip those 20 hours when they're not directly applicable to what you're trying to accomplish?

When you literally don't have $20 in your account. Then you can spend 100 hours and it's still worth it.

Also, in big corporations, getting approval for spending $20 is as hard as getting approval for $200 or $2000.

Which is why FOSS software took off in big companies, because it's easier for developers to sample things out and then ask for forgiveness instead of asking for permission.

Also, hobbies. It doesn't even matter if you have $20 to spend, or not. Hobbies depending on paid tools are risky.

People underestimate the importance of free tools because they judge from the perspective of their overinflated consultancy rates.

Re: .NET 8

#337

Post by PH95VuimJjqBqy »

Salgat wrote: post #278
xeromal wrote: post #4

Tangentially related but I was impressed with .NET recently. I was recently tasked with tackling an extremely old and proprietary video format that embedded GPS, video, audio, and several other components. The files were huge and just a mess to understand and I eventually found an old player application that was also proprietary. I decompiled it into C# and stripped the player aspect out of it leaving the code the pe…

The compatibility shims that come implicit with .NET are incredible. In my experience many of the .NET Framework libraries work right out of the box on .NET (Core), even on Linux.

.net core has been able to run .net framework assemblies since around the 3.x days.

not everything is supported so not all assemblies will work, but large parts of the standard library are supported so it's most seemless.

Re: .NET 8

#338

Post by WorldMaker »

croes wrote: post #332
WorldMaker wrote: post #295

Earlier quoted context omitted.

The name scheme was confusing only during the "overlap" period. At this point again you can strictly pay attention to version numbers: 8 > 7 > ... > 4 > 3 > ... Any version current LTS. The rest of the "naming scheme" is dead weight.

Why don't I want to use .Net Framework 4.8? It will presumably have longer support than .Net 8.

- Lack of features

- Lack of cross-platform support (Windows only)

- Lack of Ahead-of-Time compilation options

- Worse performance

- Disappearing community support (many common/favorite libraries have already dropped 4.8 support and/or maintenance and are only looking at the .NET 5+ present; more do that every day and generally greenfield fresh/new libraries won't even consider 4.8 support or testing at all; this includes major first party libraries such as ASP.NET and Entity Framework, you cannot use the latest on 4.8 full stop)

- Worse and more expensive tooling (8 can be entirely command line driven including locally and cheaper and easier CI/CD installs and scripts, has great support not just in expensive IDEs like Visual Studio or Rider but also [cheap as free] VS Code and through LSP tools even options like vim/neovim/emacs in ways that 4.8 has mostly never supported)

Yes, there's definitely a shift in LTS strategies with .NET 5+. It isn't tied to Windows support lifetimes anymore, which has benefits too (much easier to deploy new versions; I will never miss the days of "we can't use that feature because management keeps putting off the Windows upgrade migration"). It is using a very similar strategy to NodeJS of twice a year releases with "even releases" being LTS supported for two years. That certainly can sound like a more complicated maintenance burden, but faster release cycles and shorter support windows generally mean fewer backward compatibility breaks and an easier upgrade from version to version.

The way I see 4.8 "long term support": the VB6 runtime is still technically "supported" in Windows 11 for long-tail backward compatibility but such long "support" doesn't mean VB6 is a good option for writing code today for Windows (or has been for a decade or more), and the VB6 IDE and compiler have not been supported since Windows XP. Fortunately, 4.8 isn't the VB6 of .NET because there are clear and easy upgrade paths, plenty of good migration tools, plenty of good reasons to migrate (performance! cross-platform!), many developers have happily migrated with no intention of going back, many new developers to .NET have enviably never experienced .NET better). This isn't a hard fork at this point, this is much more clearly "present and most useful" versus "outdated and legacy". But the sentiment of "don't use VB6" is still there for 4.8: if you are still working on 4.8 this year you probably better have the excuse of a large "brownfield" application with a huge legacy footprint. You are probably going to have a bad time doing it, you are going to have an increasingly uphill battle to get new developers to go back to 4.8, and the IDE and tools for supporting 4.8 are going to lose support soon (the ones that haven't already) and will only get more expensive and rube goldberg-like, to be trapped in VMs of older Windows versions and increasingly network isolated because of that.

Re: .NET 8

#339

Post by WorldMaker »

custard42 wrote: post #315
WorldMaker wrote: post #287

Earlier quoted context omitted.

I worry that Blazor is that dumpster fire sometimes.

I'm curious, why do you say that?

The mixture of client-side and server-side code that Blazor can allow in the same files gives me a very gut instinct feeling that "those who have forgotten the WebForms history, or worse the ASP Classic history, are doomed to repeat it". It's obviously different from both WebForms and ASP Classic and its use of Wasm is certainly a brand new idea that WebForms only wishes it had access to. It seems like a brand new mistake to me, because I still remember debugging ASP Classic and WebForms and Silverlight and "now even the client side JS of ~~WebForms~~ Blazor is no longer JS but a mini-.NET runtime in a Wasm box" doesn't sound like a good time in the long term maintenance future to me when Blazor apps become legacy apps. But some of that gut instinct may just be cynicism at this point.

Re: .NET 8

#340

Post by sebazzz »

bob1029 wrote: post #132
RajT88 wrote: post #59

Earlier quoted context omitted.

The .Net ecosystem has a lot of great tooling, for sure. The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. There are quite good free tools, but you have to figure out what works best for you if you're used to the non-free ones. I assume instead of Reflector for the decompilation, you used DotPeek?

> The main issue I have had is if you are trying to get into the .Net Ecosystem without spending money. I suggest not trying to do this. You can certainly make most of .NET8 work with a pure OSS toolchain, but your overall development experience is going to be destitute compared to that of the official tool chain. To be clear - I think paid alternatives, such as Rider are fantastic too, but even so I've had some trou…

> At the end of the day, you have to ask yourself about what your hourly rate is. If you are going to spend a 20 hour premium per week bandaging up a "free" .NET toolchain, whereas the official, $100/m stack costs you 1-2 hours, which one actually costs you more?

Also the official stack is supposedly supported, which means you can contact Microsoft if you have an issue.

In practice, you get some underpaid outsourced employee in the chat, who is just going to follow their script - so it is more effective to go to Visual Studio feedback or Github, depending on the issue.

Post reply on HN