I think it's just an intractable problem at this point. There's probably millions of physicists on Earth. Everyone working in a company knows just how hard it is to get even hundreds of people to agree and read and understand the same things.
The fact is, there are just too many people doing too many things. When any technical paper sounds like gobblygook to even people in the same field but in a different specialty, it's no surprise this happens, especially when coupled with the modern pressure to scientifically publish and modern "journalism" trends.
The unfortunate reality is that humans seem to have this innate desire to get rid of ourselves. I see us trying to automated everything. To what end, I do not know.
I find it interesting how the software industry has done everything it can to ignore F#. This is me just lamenting how I always come back to it as the best general purpose language.
Probably the intersection of people who (a) want an advanced ML-style language and (b) are interested in a CLR-based language is very small. But also, doesn't it do some weird thing where it matters in what order the files are included in the compilation? I remember being interested in F# but being turned off by that, and maybe some other weird details.
To be quite blunt, that sounds like a rationalization. To me "well-organized" would mean that the order conclusively does not matter. Otherwise I feel like I'm eventually going to end up randomly rejiggering the ordering until the compiler stops whining.
I don’t want to use a language with unknown ecosystem. If I need a library to do X, I’m confident I can find it for Go, Java, Python etc. But I don’t know about F#.
I also don’t want to use a language with questionable hireability.
Haven't used F# too much myself but one of the strong points is because it shares the CLR with C# you can use any of the many packages meant for C# and it'll work because of the shared runtime.
To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields.
They've effectively dropped it a couple times in the past, and while they're currently putting effort in, the company as a whole does not seem to care about stuff like this beyond brief bursts of attention to try to win back developer mindshare, before going back to abandonment. It's what Microsoft is rather well known for.
.NET is one of the easiest to install and robust cross-platform systems out there. It's actually very impressive. I don't know of a single other platform that nails cross-platform so well.
The effort of .NET Framework to .NET Core to .NET 5 and now up to .NET 9 is well over a decade long of steady and increasing progress.
For (2), this is often misunderstood and mistated.
The JVM includes no GUI framework. .NET also includes no GUI framework. .NET happens to have a specific framework for Windows. But just like the JVM, there third-party GUI frameworks such as MAUI, Uno, Avalonia, and others.
So no, there's isn't a "large part" of .NET that isn't cross-platform.
> 3. the level and quality of official tooling provided for Linux and macOS is incomparable to their Windows offerings
> To within a rounding error of zero, I don't think anyone outside Windows devs truly expects Microsoft to maintain .NET on other platforms, so it's not really an option in many (most?) fields.
This is provably wrong, unless you want to insist despite the facts because that's what your social bubble tells you to do.
People use Microsoft open source stuff, definitely. It's fairly often decent or better.
But Microsoft's most consistent legacy across its entire existence has been Embrace, Extend, Extinguish. Any Linux-supporting project is directly opposed to their core business, aside from Azure - if it starts becoming a threat, they'll turn it into a way to force people onto their other money-makers.
By this logic we should drop Golang immediately then because tomorrow Google will either kill it or they will add unremovable telemetry that uploads all of your code directly to AdSense.
Huh? Usually languages that are ”ignored” turns out to be for reasons such as poor or proprietary tooling. As an ignorant bystander, how are things like
Cross compilation, package manager and associated infrastructure, async io (epoll, io_uring etc), platform support, runtime requirements, FFI support, language server, etc.
Are a majority of these things available with first party (or best in class) integrated tooling that are trivial to set up on all big three desktop platforms?
For instance, can I compile an F# lib to an iOS framework, ideally with automatically generated bindings for C, C++ or Objective C? Can I use private repo (ie github) urls with automatic overrides while pulling deps?
Generally, the answer to these questions for – let’s call it ”niche” asterisk – languages, are ”there is a GitHub project with 15 stars last updated 3 years ago that maybe solves that problem”.
There are tons of amazing languages (or at the very least, underappreciated language features) that didn’t ”make it” because of these boring reasons.
My entire point is that the older and grumpier I get, the less the language itself matters. Sure, I hate it when my favorite elegant feature is missing, but at the end of the day it’s easy to work around. IMO the navel gazing and bikeshedding around languages is vastly overhyped in software engineering.
It's been around for a long time and sponsored by Microsoft. I don't know its exact status, but the only reason for it to lack in any of those areas is lack of will.
> If you're wildly successful at something with significant real world influence, why would you care so strongly about something as relatively inconsequential as a board game or a video game?
Deep running narcissism, bordering on sociopathy or psychopathy.
Elixir came from Ruby developers and thus has similarly verbose syntax and macros. Erlang's syntax came from Prolog, which was used to implement the first compiler and is why Erlang's syntax is more concise.
The BEAM's real special sauce is in its preemptive scheduler in that it is impossible for one process to take down the whole system, even if bad processes are eating up the entire CPU. This cannot be done in any other language.
Worth noting as a disclaimer for people reading this: this is only true so long as external interfaces are not used. As soon as the BEAM calls out to other binaries, you lose that guarantee.
A disclaimer to the disclaimer is that you should be isolating that binary on dedicated nodes if there are stability concerns. Inter-node communication is trivial on the BEAM and it can be tweaked in the future when the scale of the system calls for it.
The fact is, there are just too many people doing too many things. When any technical paper sounds like gobblygook to even people in the same field but in a different specialty, it's no surprise this happens, especially when coupled with the modern pressure to scientifically publish and modern "journalism" trends.
reply