.NET 6 is now in Ubuntu 22.04(devblogs.microsoft.com) |
.NET 6 is now in Ubuntu 22.04(devblogs.microsoft.com) |
Seems best avoided by any company which is not already a Microsoft shop.
We recently upgraded from 3.1 to 6, which was a total non-event. The code base that was around for Core 2.x is still the same one we have today. Some substantial changes made to the web interfaces and hosting, but nothing in the business logic or data models was impacted.
We currently use Self-Contained Deployments to Windows machines, but there are only 2 minor methods stopping us from using a Linux image as well. Looking for a really good reason to make the jump, but I can't justify it to the business yet.
Not having to pay for Windows Server licences?
Better start-up performance, likely better overall performance, less resource usage.
Assuming these are specific Windows calls, moving to something more cross-platform you could open development to colleagues with Mac or Linux machines (via VS Mac, JetBrains Rider or VS Code) if there are any.
Options to use Kubernetes or deploy to container services that run on Linux
A few reasons.
Chances are that those licenses are paid for already so this is a sunk cost.
> Options to use Kubernetes or deploy to container services that run on Linux
I think this would be a hard sell - "hey, let us migrate platforms so we can rewrite our entire production infrastructure "
The many different versions were quite confusing. I am happy that they are now unified.
If you continue to use .NET Framework 4.8, your software will receive security updates until the heat death of the universe, too much, including Windows itself, depends on it. (Same, hilariously, with Visual Basic 6.) Microsoft's lifecycle for new runtimes is so short you're better off using a dead one.
.NET Core has too many caveats and too few selling points to get any reasonably competent desktop developers to move over, IMHO, especially considering the fact that every executable you ship to customers has a Microsoft imposed support death date.
There are significant performance improvements, and the new language features of C# depend on the later versions - that might not be such a big deal, but it will become more acute as the language improves.
I'm a Java dev, but I have also developed on .Net and running modern .Net on Linux is about as simple as it get.
We haven’t run into a customer that wants us to host for them yet (and probably won’t ever in our market of banking).
Just one thought worth looking at.
Every client gets 256 bits of entropy cookies which uniquely identify their “device”. The server will then deal with this as required to guide auth flows.
Good to hear as we need to take this step soon. The bigger hurdle for us is a number of production apps in DNF 4.x that also leverage DevExpress (god knows why). Incredibly costly to stand up in EC2 instances and the ROI just isn't there.
As developer and systems engineer you should have been aware of that before starting your work. Now you are chained to the Windoes world and real computing environments are out of reach for your project.
https://isdotnetopen.com/ goes over these in more detail, but I'd rather use an ecosystem where I don't have to worry things will be progressively locked down in the future.
C#
JavaScript/TypeScript
Python
Edit: golang is small in terms usage but is on the way up definitely
All the rest are in decline or remaining at a constant level of acceptance.
So if hiring / recruiting is important, use C# or TypeScript or Python.
If you want to cause yourself deep hiring/recruiting pain, build your systems with Ruby or use lesser known frameworks and languages such as Erlang/Elixir.
C# seems like an excellent choice for Linux based development - it's mature, there's a vast talent pool, theres vast knowledge and community resource for getting problems and questions answered.
It will always be big and always be around, but it's losing popularity.
I think at this point my last real major gripe with .NET is Visual Studio. I've used it on and off over the years, but every time I get back into it, it's just so much mental overhead to try and understand how the hell things are organized. It's like jumping into an ice bath coming from JetBrains/VS Code land. Just really unpleasant, but I don't think I'll be able to get away from it with this older C# code base.
Somewhat unrelated. I really wish Microsoft would improve the install/packaging story for their C++ build tools on Windows. Trying to guide your IT department on how to install specific compiler versions to get TensorFlow/PyTorch and more importantly other less popular Python packages that require you to build from scratch on Windows has been a nightmare for so long. It's one of the things I mostly singularly dread dealing with. I really wish we could just enable the dev/compiler tool chain support without requiring admin credentials and have it be fully automated instead of trawling around the nightmarish Microsoft downloads site.
We are fully remote with flexible hours and offer 4 day work weeks.
The following packages have unmet dependencies.
libc++1-14 : Depends: libunwind-14 (>= 1:14.0.0) but it is not installable
libc++abi1-14 : Depends: libunwind-14 (>= 1:14.0.0) but it is not installable
E: Unable to correct problems, you have held broken packages.Just thinking from a Ubuntu package level, where libraries live in packages separate from executables, it might be possible to create library packages using the result of ‘dotnet store’. Then executable packages could reference them when running ‘dotnet publish’. [2] That way multiple executable packages could share common libraries.
Replicating the packages of a language package manager (Nugget in this case) into a system package manager (apt in this case) is probably not fun. You will end up with dependency nightmares or one system package per version of Nugget package. So maybe it’s not worth doing.
[1]: https://ubuntu.com/blog/install-dotnet-on-ubuntu
[2]: https://docs.microsoft.com/en-us/dotnet/core/deploying/runti...
(And where the hell is support for .NET Core on FreeBSD???)
If "Canonical and Microsoft are committed to working together", probably the former.
[1] https://docs.microsoft.com/en-us/dotnet/core/tools/telemetry
Pretty cool and interesting that a big linux vendor is on board with .net.
https://learnxinyminutes.com/docs/csharp/
it looks more like Java than c++ to me.
On a different note, I will state this again: I think microsoft will acquire Canonical one day.
There's also https://github.com/dotnet/maui from Microsoft but it's not mature yet.
The times sure have changed
I don't have data, however, from what I see/read, there is a tendency of developers/companies using .NET environments to just go for Azure. It looks like it comes as a big package, while it doesn't have to be like this, but hey, that's how it works especially in enterprise companies.
How much does/did it cost to port .NET to mac/Linux? Compared to what you gain just by having a few customers in the cloud, maybe crumbs: provide a good dev environment, people will clearly opt for your cloud services.
From the .NET Core 1.0 announcement made in June 2016: https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...:
> Today we are at the Red Hat DevNation conference showing the release and our partnership with Red Hat. Watch the live stream via Channel 9 where Scott Hanselman will demonstrate .NET Core 1.0. .NET Core is now available on Red Hat Enterprise Linux and OpenShift via certified containers.
Maybe because it's not a popular language, but the F# experience for me has been bad - tried it two years ago with F# 5, and recently with F# 6. The documentation in both cases was immature/inconsistent to broken.
The usual features (e.g TP's) that are used to sell the language though I feel are oversold and tbh not the main reason F# users like the language - in fact I think TP's need an overhaul and are a distraction. Inlining code for math (which is just getting an equivalent like feature in the next C#), unions/records together, functions and type inference, leaning to compile time vs runtime dispatch in code style, etc I feel are where its strengths are at. More than features I've found for large scale projects its just easier to spot bad code in F#, less bugs have made it ot Production when .NET teams have tried it, and less of it makes it to code reviews.
I've found F# tooling at least for VS Code more stable than the C# equivalent. But that's not saying much - most languages plugins for VS Code don't feel that stable to me if not JS (e.g. the Java one used to crash on me all the time). In VS Studio, Rider, etc are options.
Documentation should be improved sure especially for people getting into it; but it is the smaller language and documentation goes out of date quickly. This obviously penalises the new starter without a mentor/senior dev to teach them in the job/elsewhere.
Early on one of the big selling points was reading all those type provider articles. Then I've tried it a couple of months ago and it was such a broken mess - not worth the time. From what I've read this isn't just my experience.
With, record types, switch expressions, top level expressions, file scoped modules, global usings, etc. C# removed a lot of cruft. Roslyn source generators actually work unlike type providers. If they improved the REPL/scripting aspect of C# I think there would be very little arguments for F# other than catering to FP crowd who like to like |> to |> write |> like |> this instead of this(like(write(to(like))))
Anybody knows if this affects the ease of installing on Debian 11 in any way?
MS provides packages for Debian. https://docs.microsoft.com/en-us/dotnet/core/install/linux-d...
Tbh I'm surprised they haven't been acquired by Microsoft yet. They're clearly aiming straight for it.
I probably would do the same if I were them, too.
It seems like they spooked the community with this VSCode plugin thing but it also feels like not that big a deal. MS wants VSCode to interface with things they can sell along with the open source. Is that so bad? I get the worry that the MS support of OSS could dry up but that could be said for all kinds of OSS projects with corpo backers, no?
It's not strictly unreasonable for MS to offer a proprietary debugger, but it is bass-ackwards for the core .NET team to not offer an open source debugger or open standards compliant debugger interface to go with their open source language.
Providing the basics as open source and then charging a little for some extras should not be the end of the world. You see the same in the Jetbrains ecosystem where e.g. the community edition of Intellij is free and open source but they have a paid version with a lot of extras.
Paid products for developers are not as common as they used to be but we are talking about tools that improve productivity a lot for people that make a lot of money using those tools. Developers (my self included) are oddly stingy when it comes to spending on software but at the same time think nothing of blowing a few thousand dollars on hardware.
And that one isn't usable outside of Rider either.
1) Don't trust Go because of Google
2) Don't trust C#,F# because M$ (yes with dollar sign)
3) Don't trust Java because Oracle
4) You gotta use XXX tech, which has no jobs in your area
Yada Yada... yet is probably using VSCode or GitHub. Just ignore it.
https://www.reddit.com/r/Minecraft/comments/vjpz2w/ingame_ch...
Fuck Microsoft.
We still have copilot case in front of us.
There is a good reason projects like the Rust Language are dual-licensed under MIT AND Apache2 because only the later protects you from software patent claims.
So I wouldn't be so sure about MS not having any legal means to shut down forks. Even if they might not win in court, as long as they can make up something up, they still have enough legal war money to effectively shut down any unwanted fork just by threatening legal action.
Or please elaborate a little what you mean by "betraying".
Obviously, I have no idea what exactly will MS do, but after reaching some adoption target, MS will try to extract as much money as it can, because that's what they do.
The other posters in this thread mentioned the debugger is still proprietary. Anyway, I'm not touching this.
Microsoft is probably the most aggressively mediocre company in history, and the poor quality of everything has extracted an enormous lost productivity cost. Those of you old enough to remember IIS and early internet Microsoft know.
Even today, it takes five full seconds for my work Outlook webmail to load. Every person in the organization waiting for each task in Outlook n times per day adds up to a lot of lost productivity. And Outlook adds nothing to email that we haven't had since forever. Microsoft just took it over and made it slow and convinced the corporate types to use it. Rinse and repeat for everything they do.
I picked up and used XNA for the global gamejam 2012. It wasn't a terrible experience, so I went to use it again for 2013 but they'd since killed it off.
For older applications, I would consider Mono or WINE if you really want to run it on Linux. We are experiencing the same scenario where we have an application that was built on .NET 4 over 10 years ago and there's a couple of packages we rely on that will not work on .NET 5/6. We have a rebuild planned, but it will be a large overhaul.
I don't understand - what's stopping you from using JetBrains Rider? I use it and I work on some pretty ancient .NET projects from time to time.
As an individual, I only have a little bit of time to tinker with personal projects, and while I like C#/.NET so far, I'm not yet at the point where I feel comfortable paying for Rider's subscription. So I'm also mostly using VS2022 Community and VS Code (on macOS) so far. Hoping to eventually get to a point where paying for Rider becomes a no brainer.
Not sure if this is what you mean, but vs_installer.exe supports command line arguments like --add, so you should be able to craft a giant command line for IT to copy. Used it for work for the NodeJS equivalent of your use case.
From the installer GUI on a machine with the correct set of components installed, click the “More ▼” button, then choose “Export Configuration” and follow the resulting prompts.
Alternatively, the installer’s “export” command-line operation does the same thing.
To use the resulting config file, either supply its path using the “--config” option to the installer’s “install” and “modify” command-line operations, or apply it from the GUI by clicking “More ▼” and choosing “Import Configuration”.
This is also handy in non-IT deployments to quickly replicate an existing VS install on a new machine.
Incidentally, even if you are going to go with the “giant command line” approach, the export mechanism is an easy way to figure out a valid set of component IDs to supply on said command line, though it doesn’t necessarily generate the smallest set of component IDs able to produce a given configuration, due to the presence of workload IDs and the fact that component dependencies are automatically installed, even if unspecified.
See eg https://www.debian.org/doc//debian-policy/ch-sharedlibs.html which says
> The run-time shared library must be placed in a package whose name changes whenever the SONAME of the shared library changes. This allows several versions of the shared library to be installed at the same time, allowing installation of the new version of the shared library without immediately breaking binaries that depend on the old version.
In this libunwind case the situation is more complicated, the its different versions have conflicting subdependencies.
The first part seems to add confidence that if the right apps/developers came along, Canonical themselves likely wouldn't have a problem putting them in the distribution. The second part would explain why there aren't just apps waiting in the wings for it and why "the community" (or at least certain vocal parts) may still not be as welcoming of .NET-based apps in the distribution this time around like it played out that previous time.
From a technical perspective it's pretty much a solved problem for any language ecosystem whose dependency management is reproducible, is uniform enough to support basic automation, and supports some measure of vendorization.
We are starting to work through it here: https://github.com/dotnet/source-build/discussions/2960. Any advice/tips/contributions would be welcome, I think.
I'm not sure going back to shared runtime libs is worth the headache but I guess if you were really resource constrained but running .NET it would work for you.
Also notice that our default build instructions are for Fedora: https://github.com/dotnet/installer#building.
I'm the post author.
About 2 months ago they crushed hopes that official FreeBSD support will happen anytime soon by clearly stating that at this point, updating their Quality Assurance process to support FreeBSD would not make business sense for them as they have to put together an extensive test suit and manual testing procedures for every OS. Microsoft folks remain friendly and helpful in the thread though.
The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process. This is one of the things that complicates its inclusion in the ports tree. Building .NET for FreeBSD is close to rocket science, the community has worked to make the process way simpler. It is frustrating that the .NET team refuses to take things from there. Providing FreeBSD support is what I would expect from them to strengthen their cross-platform posture. This is the last major platform they need to support, and one being heavily used for servers.
As someone who is not a part of the FreeBSD community, I just wanted to chime in to say that the FreeBSD Ports people are absolutely correct here, and that the build time behavior you describe is Bad Behavior™ that is likely to get in the way of any distribution (Linux or FreeBSD or macOS or anything else) that follows basic best practices with respect to build sandboxing on their CI/CD systems, build clusters, etc., even if it can eventually be hacked around.
Building software outside of a sandbox with restricted network access is how you get lovely exports like credential scrapers in your setup.py or your NPM install hooks, perhaps running as root. Downloading your dependencies at build time from within the build system without first emitting a manifest with hashsums of what you intend to download is a huge problem for reproducibility, too.
That would make a lot of sense, despite the backlash it would generate.
Remember when they acquired GitHub, developers were vouching to move over to GitLab. Yet very few did.
The same would probably happen if they acquire Ubuntu. Developers would vouch to move to another distribution, yet few will, because Ubuntu is so much nicer to use than the competition.
I'll never trust Microsoft again after all they did in the 2000s. Transitively, I'll never trust any comparably sized company.
GitHub benefits from a powerful network effect: if you want contributions from the greatest number of developers, you need to be on the platform they use and understand.
Ubuntu doesn't have a comparable form of social lock-in. As long as they are popular and until portable and/or containerized package formats for Linux mature, they do exert some network pressure on publishers, but not really end users.
> Ubuntu is so much nicer to use than the competition.
I don't think this has been true for some time. Canonical's server offerings are pretty much coasting on the mindshare that they gained with current-gen Linux sysadmins and developers who grew up experimenting with desktop Linux in the aughts, when the usability delta between Ubuntu and other mainstream distros really was vast.
They still benefit quite a bit from their willingness to bundle proprietary software with the OS, and from sheer inertia on the desktop, where they are still most likely to receive native packages by proprietary software vendors.
But the collection of desktop operating systems that actually attract new users to the ecosystem who will become the next generations of Linux sysadmins is increasingly comprised of distros that are not based on Ubuntu. User-friendly Arch downstreams now have more and more of theml mindshare that Ubuntu did when I was 'growing up.
The most popular Ubuntu-based distribution, which has actually surpassed Ubuntu both in interest from new users and in its reputation for OOTB usability, deviates strongly from Ubuntu in some core technical aspects that make some Ubuntu knowledge non-transferable.
APT is aging poorly, even compared to its RPM-based counterparts. It has recently been at the center of some high profile blowups where package installation triggers a catastrophic cascade of uninstallations that newbies would likely perceive as 'bricking' their installations. This has damaged the reputation of the most popular Ubuntu-based distros, including Ubuntu itself as well at driving home the case for portable/containerized package formats.
The success and growth of these portable package formats, including Snap itself, additionally threaten to undermine Ubuntu's strategic advantage because they work pretty much as well on any distro as they do on Ubuntu.
Moreover, Canonical's own offering in that space is already driving users away from Ubuntu. Snap is slow, clunky, space hungry, and bandwidth hungry, and the way that Ubuntu has chosen to force Snap packages for key software, e.g., Firefox, has had a negative impact even (and perhaps especially) among non-technical users precisely because it has a shitty UX.
Meanwhile Snap has failed to gain much developer interest outside of Canonical, and looks likely to suffer many of the same adoption problems as previous Canonical offerings in the space of core system software like Upstart and Mir. It seems that Canonical has not figured out a way, in the past decade or so, to displace Red Hat as the most influential corporation on projects that require widespread, cross-distro adoption to succeed.
Similarly to the situation witb portable packaging formats, there's a pretty clear trend in the wider Linux world away from relying on old-school package management 'raw' in favor of immutable operating system images. There are Ubuntu derivatives in this space, but the clear leaders are NixOS on the radical side and Fedora Silverblue for the more conservative approach that reinforces/enhances traditional package management tools with OSTree to gain some of the same benefits.
It may be that Canonical's advantage in the server space and among developers is 'sticky', now that Ubuntu is established in those markets, and that it's less ripe for the same kind of play that Ubuntu made by building mindshare first on the desktop. They may also catch up in some of these areas.
But for all of the reasons I outlined above, I don't think Canonical is in nearly as strong a position to retain its relevance as GitHub was, especially in the long term, in the face of one more thing that makes it less attractive to new desktop users for whom much of the appeal of running Linux in the first place is escape from Microsoft.
Why? There is nothing "Enterprisey" about .NET Core. It's a perfect fit for both fast-moving startups and big enterprises.
- Alpine: https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/c...
- Arch Linux: https://github.com/archlinux/svntogit-community/blob/package...
- Fedora: https://src.fedoraproject.org/rpms/dotnet3.1/blob/f36/f/cli-...
- RHEL: https://gitlab.com/redhat/centos-stream/rpms/dotnet6.0/-/blo...
- Ubuntu: http://archive.ubuntu.com/ubuntu/pool/universe/d/dotnet6/dot...
The homebrew build of .NET is the only non-Microsoft build of .NET that seems to keep it enabled (https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/...).
I am looking at the sources at https://packages.ubuntu.com/source/jammy-updates/dotnet6 and (as far as I can tell) they are applying a patch called 1500sdk-telemetry-optout.patch (originally from Fedora https://src.fedoraproject.org/rpms/dotnet3.1/blob/f36/f/cli-...) that is supposed to make telemetry opt-in.
There's a better fix landing upstream for .NET 7: https://github.com/dotnet/sdk/pull/25935
That being said, I've used .Net and C# for over a decade and it's frankly just a clunky language and toolset. It's gotten better with Core (now just.Net), but it's still just not there. It's not a secret that we've been doing more and more TypeScript where I work, but I recently did a little bit of Go and Gorm made EntityFramework feel like something from the stoneage.
So I'm not sure I'd really recommend it unless you already do a lot of .Net. It's not that it's bad, it's just that it's a dated way to build things in a world where the Java way of doing things makes less and less sense.
Once I disable Entity Framework object cache globaly (AsNoTracking), it becomes close to the ideal db toolkit for me.
I see a lot of strings in Gorm docs. Those are probably not checked during compilation. This alone differentiates Gorm and EF quite a bit. https://gorm.io/docs/create.html
Not wanting to get in a debate on whether you should use an ORM, but I just don't see anything really special about Gorm that makes the other frameworks "ancient".
When I look at this page: https://gorm.io/docs/advanced_query.html I see the same exact crap that makes me wary of JPA Criteria API.
[0]: https://github.com/bflattened/bflat
I am not a vs/c#/.net dev but I tried it once on a windows machine and thought it integrated well and seemed to be a really nice DX. Probably the nicest DX for an "enterprise" stack.
Other than that, it is smooth and in many advanced scenarios Linux has better support than macOS, unfortunately (still decent, just has quirks).
Also, check out Native AOT in the upcoming .NET 7 because it is really nice for building small and lightweight CLI utilities in .NET and just shipping them to users like you would if they were written in C++ or Rust.
That seems untrue. On the Cloud side every .Net shop I know from startups to government/enterprise are now deploying to Linux or Linux containers.
On the developer side 75% of .Net devs are on Visual Studio on Windows but a big and fast growing segment are using JetBrains Rider on Mac/Ubuntu.
Not everyone who uses Azure is a "Microsoft shop", in terms of programming tech stack. Plenty of people use Azure as a cross-cloud redundancy play, or because they do business with Amazon competitors that refuse to have their data on AWS.
It's the reverse in AWS, they have a bit more Windows market share than Linux. And he also backed up your statement.
His take (which was just his speculation) was that the virtualization stacks ran those OS's more efficiently. HyperV with Linux VM's and KVM with Windows VM's. I have no idea if that's true or not.
If you plan on shipping server software, I expect it to run on Linux, particularly in a container.
.NET definitely has first-class support on both Linux and Windows.
- It supports structs, and unboxable structs called "ref structs". They let you to avoid GC/heap-alloc for small data structures with clear ownership semantics.
- It uses type reification for generics instead of type erasure. Combined with value-types, this can produce very optimized code. The downside is larger binary sizes.
- It allows unsafe programming with pointer arithmetic where performance is truly critical. This is where C# is closer to C/C++ than Java.
- Supports native compilation to a target architecture. This lets you avoid JIT overhead and lets you ship self-contained binaries (like Go).
- .NET supports source generators which can let you keep maintainable code and generate an optimized one.
Performance aside, C# is a very pleasant language to use, and .NET is a delightful runtime. I'd say give it a try and see it for yourself.
The main target is enterprise software systems and web backends. Asp.Net is a very mature framework for Web APIs and MVC applications.
Entity Framework is a decent ORM solution supporting several popular DBs with tools for code generation and migrations, and LINQ is a complementary query language that is useful for in-memory collection operations as well as db queries.
And I think the largest value is in the NuGet software library ecosystem, things like MassTransit for service bus and queue communication and many many others.
It’s a well-supported ecosystem of first party and third party software with a lot of modern features, but definitely still in the realm of managed runtimes so not a competitor to C, Rust, etc.
*ASP.NET Core
Microsoft relies on "fire and motion"¹ to sell to developers, and typically reimplements instead of working with open source projects.
Recent example: only Visual Studio 2022 supports .NET 6, time to upgrade.
[Service]
Type=simple
ExecStart=/usr/bin/dotnet /some/path/myapp.dll
WorkingDirectory=/some/path/
Restart=always
User=someone
Group=someone
[Install]
WantedBy=multi-user.targetFor digitalocean I followed this post which is probably way out of date now https://www.hanselman.com/blog/publishing-an-aspnet-core-web...
For the k3s site the source is here https://github.com/EliotJones/LetsShip/blob/main/kubernetes/... though worth noting I have set up LetsEncrypt incorrectly but that's my lack of k3s understanding.
https://docs.servicestack.net/ormlite/litestream
If you don't want to use Docker, you can also easily deploy to Linux using rsync + supervisor:
Literally 'dotnet {AppName.dll}' and that's it.
Also "Oh and we need to hire two full time devops engineers to take care of the thing" :)
Seems about right, most of the .Net jobs are very corporate :-)
hm that's weird, with yay it only ever adds new electron versions, never removes the old ones. e.g. there's electron12 to 20 in the repos and they can be installed side by side
There is also VS Community, which is a free version of VS, has this debugger, but has fairly strict licensing limitations (e.g. it can't be used in corporations).
But it's hard to convince a C# dev to use F# when they're so comfortable and see no obvious need to switch.
[1]: https://www.microsoft.com/en-us/windows-server/pricing?rtc=1 [2]: https://parquantix.com/linux-windows-aws-cost-comparison/
But it should be possible to write independent .NET debuggers -- I believe Jetbrains has done so, Rider can debug C# code without the problematic Microsoft component.
And I think lldb works with .NET apps.
* In synthetic benchmarks
https://www.techempower.com/benchmarks/#section=data-r21
Personally I think that some of their tests are pretty close to what web applications might actually do a lot of the time (fetching the data, processing it, saving it), for example, see here: https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...
Sure, sometimes the code you see in benchmarks can be a bit more clever than the code you'd see normally, but for the most part TechEmpower seems close enough to be a vague indicator towards what frameworks/languages/stacks have decent performance.
It also helps you get a feel for how big the differences are between any two given platforms, like using something like Java + Spring and Python + Django, which may or may not be relevant in actual business conditions, since you might also want to iterate quickly.
Host: https://gist.github.com/neon-sunset/767cb0693c3ff222f78b236c...
HTTP Benchmark: https://gist.github.com/neon-sunset/d936e54bfec1031d1628c338...
The only other real way is to write two programs that do the same thing in both. You need to put in the same degree of runtime/environment-specific optimizations (which, notably, will result in different code), but except for in trivially simple applications (eg: "TODO app") which are arguably also "synthetic", the optimizations are always going to leave room for debate.
> There is no ethical consumption under capitalism
is said to de-emphasize or criticize arguments that are centered on consumer choice which is exactly what you and GP are doing by saying
> You have no choice but to depend on big corporations for key software platforms; advising or choosing to stay away from this one or that one matters little
Same goes for trusting Vue.js instead of React (Meta) and Angular (Google).
Also our Ruby engineers liked the flexibility so much that they exposed our entire database as a service to customers, which we had to emulate and support.
Two sides to every position.
It's great if your users are disciplined and experienced Rails engineers who understand how the system works, but we don't live in fantasy land and a year later, we are so very constrained by the unlimited DB access that we're rewriting it all and leaving ActiveRecord out of the equation.
I'll always maintain that Rails is the first tool I'd reach for in a new web startup, and the first one I'd discard after growing past ~20 engineers.
I'm continuously shocked at how much bad ActiveRecord code there is lying around given that it's so easy to just look at the SQL it generates and be like "yeah this looks reasonable".
WHY SPONGEBOB WHY!?! Why do you pass around your relations making all of ActiveRecord part of your external API? It's so hard to do stupid things with AR if you pretend that AR objects can't leave the scope they were fetched in.
ActiveRecord is the least of your problems, then... seems like you may have a fundamental problem of inexperienced or foolish devs.
Our Tcl ORM was doing Sybase, SQL Server, DB2, Informix, Oracle and even Access, across Windows 2000/NT, AIX, HP-UX, Solaris, Linux, in 1999 - 2002.
But we never went big into US, so Rails gets the credits.
And we were not alone in this regard, there was Vignette, Cold Fusion, Zope,...
But your list is incomplete! .NET is also part of Alpine's community repository https://pkgs.alpinelinux.org/packages?name=dotnet*&branch=ed... and is also available in Homebrew https://formulae.brew.sh/formula/dotnet
Other distributions are welcome to join: https://github.com/dotnet/source-build/discussions/2803
It obviously lacks a lot of the wider .Net features, like having easy access to ODATA for all your models.
I'm just glad the number-space has been sorted out. It was annoying to learn that ".NET 2", ".NET Standard 2" and ".NET Core 2" are very different things.
From my understanding, thats not quite right. AFAIK framework was adapted to differentiate it from standard, core and mono.
https://stackoverflow.com/questions/51390971/im-lost-what-ha...
It's the other language stacks that are smaller, but just get more attention on startup-related discussion boards.
That promise seems only to apply if you use the .NET runtime. If you used a forked project, it might not apply.
They've already started integrating LinkedIn into Outlook. They will probably be doing the same thing with GitHub in Visual Studio, and downplaying others (like GitLab). Will it affect my use? I don't know. I doubt it, but I wish I didn't feel like I need to be watching them like a hawk now, and be ready to move my code to another provider at short notice.
The really stupid part? Out of other companies who could have bought it, and would be interested in it, Microsoft is probably the best choice. Certainly better than Oracle or Salesforce.
I also have no issues depending on corporate things that I don't like, for example GitHub, as long as they can be replaced with minimal loss. I'd git remote set-url origin <something else> and be done with it.
This makes the assumption that the viewer knows what reasonable SQL looks like in the first place.
> unconditionally trust Microsoft
But the poster I was responding to was pretty clearly saying that we should:
> unconditionally distrust Microsoft
I've signed many antitrust petitions for them over the years. And they have won a fair amount of good will since Satya came on and pushed for cultural change, as well as a larger pivot towards cloud and open source.
So, you know. It's a mixed bag is my take.
To me, it's clear Microsoft wants to force people to use VisualStudio over VSCode. Likely not an issue for a .NET shop, but it's yet more shenanigans by Microsoft
Why is that a requirement to take it seriously? I've been deploying apps developed in OSX/Windows to linux boxes for 20 years...
I don't like Visual Studio and haven't touched it since I realized VS Code worked fine.
(I'm more of an Eclipse/NetBeans/VS Code kind of person.)
You're welcome.
There are a few that require compiler interop which don't work, like using new syntax on records for specifying the fields (e.g., "record A(int a, int b)").
Records can be enabled like this [1]
[1] https://github.com/louthy/language-ext/blob/main/LanguageExt...
The implicitly assumption in the .NET choice is that dependencies may not be backwards compatible, so compile against a specific version and go ahead and ship that assembly in your self-contained deployment. Yes your packages are bigger, but disk space and bandwidth are cheaper than developer time and support costs.
That's why I say it's largely a solved problem for language ecosystems that tick a few basic boxes.
Can't Nuget and MSBuild support this? Can they not dump lockfiles like common build tools for Rust, Go, Javascript, Haskell, Python, Nim, PHP, etc., do? Is there a general problem (like there is with Java) where actually building from source is so difficult that it is rarely done?
Anyway there's already a suite of Linux packaging options built around the kind of app distribution model Microsoft expects, and Canonical even has one of their own! I don't see why they wouldn't support distributing .NET applications as Snaps, or maybe even automating the creation of Snap packages for .NET applications.
I think historically in the .NET world, package consumers have expected pre-compiled assemblies and not source code and so that's what the ecosystem has developed around.
You don't have to. You can package the application together with the right version of the library, as a single package.
https://marketplace.visualstudio.com/items?itemName=ms-dotne...
Works with Linux x64, Alpine Linux 64 bit, macOS Intel, Linux ARM64, macOS Apple Silicon, Alpine Linux ARM64, Windows ARM, Windows ia32, Windows x64
.NET 6 is the first where they fully supported M1 Macs, maybe you last looked before .NET 6 released? Either way, VS Code is definitely a supported way to work with .NET.
- .NET Hot Reload is only implemented on Windows. It requires support in the .NET runtime, which is technically possible to implement, but the team has not gotten around to implementing it for years. This doesn't have to do with the issue around MS removing the "dotnet watch" command, it's for the "Edit and Continue" feature in IDEs.[1][2]
- MS was considering deprecating Omnisharp, the open-source language server that implements C# support for VS Code, and replacing it with a closed-source version. Since the announcement, commits to omnisharp-vscode have dropped off significantly. The lack of Omnisharp would mean there would be no real open-source C# development environment for Linux anymore, since MonoDevelop was abandoned a few years ago.[3]
[1] https://youtrack.jetbrains.com/issue/RIDER-31366/EditContinu...
[2] https://github.com/dotnet/coreclr/issues/23685
[3] https://github.com/omnisharp/omnisharp-vscode/issues/5276
My understanding is that they did in fact implement it, but then ripped that code out before the release.
I doubt this. Microsoft's monetary strategy around .NET for a number is years has been "look at how easy you can deploy/run/monitor your .NET app on Azure!", I don't see that changing to anything else unless there's a massive change of priority and executive leadership at Microsoft.
I just can't imagine it makes any business sense to be that hostile in today's world.
That hasn't been true for the last few years.
Source, elsewhere in these comments: https://news.ycombinator.com/item?id=32483239
As I grow older I guess I am growing more fond of statically typed languages. It's easier for my decaying/distracted brain to reason about. There is less mental overhead I suppose [might be a good blog post?]
They both have a good database migration system and various generators for scaffolding views, controllers, etc. To be fair I believe Entity Framework does most of the work for the .NET side on the database developer tooling but I just consider it part of the .NET ecosystem since it seems to be the go-to ORM/database tooling library. I want to be fair to Rails -- I really think they set the bar very high for other frameworks. Productivity w/ Rails was unprecedented when it first came out. I started during the Rails 3 to 4 upgrade.
Both ecosystems have easy access to outside libraries using Nuget/Gemfile. So pulling in a background processor like Sidekiq [Ruby] or Hangfire [C#] is fairly easy.
Cross platform support is acceptable across both frameworks as well. I can setup an EC2 instance and run both Rails and .NET applications side-by-side. So deployments are going to be similar but I would argue that .NET has the upper-hand because it can deploy do a self-contained deploy so you don't have to worry about installing dotnet in the deployment environment.
I am using Blazor Server and I am not going to say something drastic like it will kill React but it is pretty awesome. I can build my entire web experience with C# but with Rails I have to introduce React when I sometimes dont want to. Blazor prevents me from having to write HTTP code from my front to backend systems and as an indie developer that is a godsend.
Both have gorgeous documentation -- I thought Rails was good and thorough but .NET ate their lunch.
I'm not even sure it's an "older" thing -- it's nice just to have less mental overhead.
The things that used to turn me off from static languages (eg: most of the benefits dynamic languages have) have disappeared. Generics allows creation of some powerful re-usable code (eg, List<T> or RunningAverage<T>). Tools to easily convert any random JSON or XML to concrete classes make it a simple extra step to consume any API.
The benefits are massive. Code-completion just frees your brain from having to remember or deeply think about what's available. Type-safety giving compile-time (or even coding-time) errors prevents so many stupid problems that, in a dynamic language, take a runtime check to find.
Though, for a purely back-office app with minimal state, that might be OK
Blazor Server retains the circuit for up to 3 minutes if the connection is lost, so you do not loose the connection even if the websocket connection is interrupted.
It is also not correct that it needs a websocket connection. It builds on SignalR which will use websockets if available but will fall back to other methods such as long polling to emulate a persistent connection.
Blazor Server absolutely has it's place, but you need to know when that is. You can even scale it out on multiple servers, but at least until .NET 7 you'll need to ensure "sticky" connections (the client must connect to the same server based on e.g. IP address, cookie or similar).
Do you know about Hotwire? It's Rail's html over the wire solution and seems comparable to Blazor.
sudo apt install dotnet6
Could you be so kind and open a bug for this at https://bugs.launchpad.net/ubuntu/+source/dotnet6?
Thanks in advance.
> I can think of a reason not to compile from source: it's essentially statically linking code into your assembly which can be huge problem for middleware packages that want to override the specific version you depend on. This is very common with the JSON serialization library, which is highly backwards compatible.
I think if .NET were integrated into Linux package management systems in the 'organic' way, 'building from source' here would still be 'building from source with the assistance of the distro package management tooling', which would mean that you would get intermediate build artifacts for all the deps, recursively.
If you have to do that manually, it would suck. But when automated tools can generate those packages, it works relatively nicely.
> I think historically in the .NET world, package consumers have expected pre-compiled assemblies and not source code and so that's what the ecosystem has developed around.
Yeah, and I can see how distros burning their own compute bandwidth building the same binaries into their own artifact repository systems instead of using Nuget might seem like more of a religious rite than a purposeful task.
But I think the ability to uniformly inspect and update the software on the system is a big deal when it comes to Linux distros, as is the ability to add source patches, especially for backwards compatibility or security fixes, to most people involved in putting distros together.
I don't know if Canonical is up for it with Ubuntu, but it does sound like building dotnet applications in a way that is conventional for Linux distros is certainly possible. Alternatively, something like AppImage, Flatpak, or Snap seems like a natural fit for distributing apps with libraries shipped directly by the publisher that Ubuntu or other distros could use to include .NET applications.
Considering their "collaboration" with Canonical, it feels like Microsoft is paying Canonical in order to get help for strangling Linux desktop inside the Windows ecosystem, finally extinguishing desktop Linux installs once and for all.
As a payback they're leaving server space to Canonical, but port their software to work on Ubuntu, so they have a suitable "free" platform to monetize their software. Canonical can make boatloads of money by selling support, Landscape and similar services meanwhile.
I'm thankful to them for their Copilot shenanigans though, they kickstarted the motivation inside me to be even more serious about the services and software I use. I left GitHub, slowly moving away from Google services, etc.
I would say that if that is your perspective, then you probably didn't have a close up view of them and how they operated before and after. There's been a lot of spilled ink about it; I won't rehash it here.
> it feels like Microsoft is paying Canonical in order to get help for strangling Linux desktop inside the Windows ecosystem, finally extinguishing desktop Linux installs once and for all.
I expounded on this in another thread - Desktop Linux isn't likely to be something MSFT spends any amount of time concerning themselves with as competition. Realistically, it's not real competition and any harms done to it probably were borne out of callousness or ignorance rather than competitive spite. The competition is OSX and ChromeOS (which I would not consider 'Desktop Linux').
I have witnessed "before" enough, so I distanced myself from them pretty sharply, and I didn't bother to check "after" that close. It's my fault, I accept it, but from this distance the end result doesn't show any meaningful differences. So, it's something to ponder if you ask me.
> Desktop Linux isn't likely to be something MSFT spends any amount of time concerning themselves with as competition.
It's may not be competition, but is a big hurdle against locking down PC ecosystem and converting them to appliances. If they can run all Linux apps under Windows, they can revoke all 3rd party signing keys, make Secure Boot mandatory and tell judges "See, it all works under Windows. We're no monopoly. We already ship the environment free with new PCs, anyway."
This stance against Microsoft is one of the rare firmly held strong opinions of mine. I certainly would prefer not hold this so firmly, but they made it impossible over the years.
You don't love getting 404s almost all the time?