Earlier quoted context omitted.
It's all open source and free, on Github. I've used .NET for about 10 years now, and the only money it has cost me is a few third party libraries that I couldn't find good open source competitors for.
But you've never seen it with a market share of more than 90%, which could happen eventually. It's a matter of incentives and those play against you.
.NET 8
191–200 of 374 posts
Re: .NET 8
#192Earlier quoted context omitted.
Starting from .NET 6 I think, it's pretty consistent. It's just .NET 6, 7, 8, etc.
Still confusing if can't simply switch to the most recent version or have legacy software. .NET Framework 4.8 will be longer supported than .Net 5, 6, 7 and maybe 8.
It was many a moon ago I even thought about .NET Framework. Not everyone might be so lucky, of course.
Re: .NET 8
#193Earlier quoted context omitted.
Java and Python have a few. I still don't get how electron got so popular. It's always been pretty straightforward to ship an app with a self-contained Java runtime, much the same as electron ships with v8. Java GUIs have always been worse than c++ ones, but still.. much better than electron I'd say
pySide6 has been a dream for me, it 'just works' and QT is quite robust. I am currently fucking with Java via GraalVM, and packaging my app for distribution has been absolute hell: jlink throws errors. jpackage somehow gets stuck in an infinite loop that generates a directory tree of seemingly infinite depth (so deep that even Explorer can't delete it) GraalVM native-image can't complete and throws all sorts of weird…
Re: .NET 8
#194I haven't touched .NET in well over a decade. Last time I tried, I felt like a chimpanzee strapped into the cockpit of an F-15. Everything was "deploy!" and "endpoint for automatic upgrades" and " ENTERPRISE " and "web service." Does .NET have any "write a small program that is only a CLI?" options? Or GUI instead of web interface? Something modest.
If you do want to use an IDE, there are many choices available. First party options include Visual Studio itself (which has varying skus depending on what you're interested in). For just CLI development, the Community sku would work great. Then there is VSCode, which has both the open-source "C# Extension" (also built by us), and the closed-source add-on "DevKit" which enhances that further with more features".
Regardless of which environment you use, writing a CLI is extremely simple, and the language and environment cater to it. A simple 'Hello World' for C# literally is just:
Console.WriteLine("Hello World!");
And you can grow on that as you want to flesh out whatever your CLI needs to do. If you're interested in doing anything web/server related, then ASP.NET Core also fits into this very simply, allowing you to stand up a web server from your CLI app trivially.We def want .Net, including the language, runtime, and tooling to scale all the way from these sorts of experiences to the "enterprisey" space, in a clean and consistent fashion.
If you do run into issues with any of the above, def let us know. You can see all the work we do in .Net over at github.com/dotnet/... Including what's being worked on now, and what we're continuing to invest in for future releases.
Thanks!
Re: .NET 8
#195I'd love to hear from some .NET fanatics, how would you convince someone to use that ecosystem over another?
Re: .NET 8
#196I'm looking at a language to write simple executables with or without GUI and that are not too verbose or too complicated. A bit like a compiled python :) Would .NET 8 be a good challenger ? I previously didn't consider it because the compilation to binary was looking more like an experiment, and the example I've seen were quite verbose (in a java way).
Go seems like a good fit for that.
Re: .NET 8
#197Earlier quoted context omitted.
pySide6 has been a dream for me, it 'just works' and QT is quite robust. I am currently fucking with Java via GraalVM, and packaging my app for distribution has been absolute hell: jlink throws errors. jpackage somehow gets stuck in an infinite loop that generates a directory tree of seemingly infinite depth (so deep that even Explorer can't delete it) GraalVM native-image can't complete and throws all sorts of weird…
> I really like Java the language, but getting a desktop app running on it in 2023 is a nightmare. This is honestly because you are taking the hard path and trying to do AOT compilation. Just use Swing with HotSpot. Native Image isn't meant for GUI applications and Swing internally uses a TON of reflection. Using jlink and jpackage with HotSpot has been trivial in my experience.
Re: .NET 8
#198Adding spreading is neat, but curious why they chose to go the two dot route instead of three. It's been a while since I've worked in C#, so I can't remember if there are any reserved implications of three dots.
Hi there. I'm the language designer who created the 'Collection Expression' design/specification: https://github.com/dotnet/csharplang/issues/5354 You can see the entire history of the proposal there. To answer you specific question, we went with `..` because that's what the language already uses for the complimentary 'pattern matching deconstruction' form for collection patterns. In other words, you can already say…
Re: .NET 8
#199Blazor actually looks compelling now that it has server side streaming and rendering, as well as component level interactivity. Once .NET is integrated with the new WasmGC features, it will get even better! (I don't think they mentioned WasmGC on the roadmap but I can bet anything they're going to do it).
Re: .NET 8
#200Earlier quoted context omitted.
pySide6 has been a dream for me, it 'just works' and QT is quite robust. I am currently fucking with Java via GraalVM, and packaging my app for distribution has been absolute hell: jlink throws errors. jpackage somehow gets stuck in an infinite loop that generates a directory tree of seemingly infinite depth (so deep that even Explorer can't delete it) GraalVM native-image can't complete and throws all sorts of weird…
Try https://conveyor.hydraulic.dev/ , we replace or drive the whole deployment stack and have plenty of JVM using customers. It's a lot easier, try it out and see if it works for you. I should say though, that the support for native image is experimental.