throw868788

While there are upsides to compulsory voting this is one of its downsides IMO. Because you can't "refrain to vote" the parties know all they have to be is slightly better than the alternative and they will get your vote. In some ways it entrenches the two-party preferred system and means they only have to differentiate on minor issues. In the end they don't have to be good to get your vote, they just have to be slightly better than the next party in line.

If you are not satisfied with either party you still need to vote. Even if you vote for a minor party you know many who aren't as engaged in politics will vote for one of the two majors anyway on relative, not absolute basis limiting the power of your "politically engaged" vote.

That's my impression of Australia's politics. There's no perfect system.

Reified generics avoid a lot of "boxing" that comes with standard Java, and that's only one of many features there that helps. Its just easier to avoid allocations in .NET in general over Java IMO. From recent articles and improvements to the platform the team spend their effort to reduce allocations in the first place equal to trying to improve the GC (e.g. ValueTask over Java/Scala futures, etc)

I just looked at the F# vs Java benchmarks and .NET is still faster on most of them just to get a sample on more idiomatic code. The F# codebase doesn't use a lot of externals looking at the code list

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Only the PiDigits benchmark uses "extern's"; only because it seems like a lazy port. Everything else is native F# code. It beats Java in all benchmarks expect for the binary-tree one. To see a functional language match or beat benchmark level Java on many cases, at least for me, feels kinda nice. Many other real world benchmarks in house (tech choice evaluations) and third party I've seen JVM vs .NET Core also show .NET usually coming out on top recently.

The .NET GC isn't as good as the Java one. But I feel that's because the cost/benefit of improving the CLR's GC is less than Java's so the work is put elsewhere. The language (C#/even F#) generates less garbage in the first place with typical code. Any GC improvements there probably don't have the same bang for buck as in Java where allocations IMO are more frequent in day to day coding.

Not a dumb question at all. You can to an extent, but the returns diminish quickly. It isn't linear.

This fact however makes "performance per watt" comparisons misleading between different processors designed for different environments (e.g. M1 vs AMD Desktop). It takes a more power to get that much extra perf, conversely and the more under-appreciate part IMO reducing the speed a little can save a ton of power/heat if the chip is currently running at the higher power portion of the curve.

On a desktop machine most people would want them to tune for performance at quite a substantial power efficiency cost so of course a desktop chip most probably is less power efficient per unit of compute. You don't need to power it with a battery after all and there's heaps more cooling capacity in a bigger form factor so why optimise for that?

I do feel this is something that should be made illegal. In many countries it is a breach of your employment contract to diverge your pay, unionise, etc. However it is ok for employers to share data with each other, even if they don't have a business relationship other than keeping your wage down. It makes it hard to negotiate pay rises, change jobs, and get a fair market price for your wage. Doesn't feel fair to me.

They are working in .NET 5 last time I checked. Opened an FSX script, "#r: nuget SwaggerProvider", point to a JSON API and it seems to work with IDE auto complete included with 2 lines of code, no project scaffolding, or package manager files required. Things seem to be improving on this front I guess as well.

I do agree - source generators have a better API as an implementer and can generate more than classes. I guess as soon as I need to jump into a proj file and I'm working with MsBuild anyway what stops me creating my own generation framework that runs before PreBuild that generates code for my compile step? I've done it before source generators were a thing.

I also did a quick Google search - Myriad (F# library) might be something that does something similar.

They got type generators which somewhat influenced and predates the Source Generator feature by a few years. Not the same thing of course, and from what I've seen are slightly different in target/scope. (e.g. F#'s seems more appropriate for scripting where you can use it without a proj entry).

Maybe try F#? I know it isn't always an option but if you can, especially recently, its been quite productive to work in.

I don't think F# is that second class anymore especially if you are developing on Linux/Mac OSX. The more concise language/syntax is a big plus when you don't want the heavy IDE and want to be cross platform. The VS Code plugin for example seems more mature than Omnisharp and while like any other Code plugin less flaky than many of the others.

It seems to be keeping up with the broader .NET ecosystem pretty well I think - (https://devblogs.microsoft.com/dotnet/whats-new-in-fsharp-6/). In some ways it is ahead of C# as well so I wouldn't say it is behind at all.

Agreement or disagreement - my point is each company does both good and bad. What people choose to see is somewhat colored by your previous position/bias just like everyone else. Will be the devil's advocate here.

Microsoft advanced personal computing for the majority especially outside the US where Apple pretty much was non-existent for a long time. I would argue through its life Microsoft has advanced personal computing more than most of the other tech firms. Growing up every office, every PC, every time I tried to code mostly it was on an IBM-compatible machine. Apple for a very long time wasn't very competitive IMO from a product perspective, and I think recent developments are overhyped compared to some of the big innovations of the 80's, 90's (i.e. Windows 95 was big, moving from Windows XP to Mac OS is a lot less so IMO). In fact on an Apple machine most people are just doing what they did previously on their Windows machines - just needing more power to do so (surfing the internet, office productivity, etc).

I'm glad that Apple are trying another CPU, just like I'm glad AMD do and Intel did in the long distant past. Competitiveness, not culture is what drives companies to do this. But w.r.t development/coding they aren't the leader, and their walled garden doesn't personally make their dev tech stack endearing. I don't agree they are the fastest all the time (even with the M1), and I personally don't like MacOS despite being forced to use it for work daily for many years. I see the M1 somewhat as a TSMC victory and their 5nm process + Apple wanting total control to differentiate/move away from a competitive PC market to a monopoly like one. At least Microsoft wanted/encouraged PC competition and didn't charge that much for Windows on top even back in the 90's/2000's.

For a long time you could get PC's that were faster for cheaper than Mac's. While Apple's approach to vertical integration has an advantage short term w.r.t efficiency its definitely allows an "embrace and extinguish" strategy - long term having hardware as interoperable commodity (CPU, GPU, etc) is better for competitive priced computing IMO. As a buyer more suppliers means a more competitive market - vertical integration is something most companies would love to pull off as it product differentiates and creates economic margins. Apple is the worst on this aspect. They aren't an open platform and the only thing capping their price and forcing them to improve is because they are still the underdog market share wise and they want to beat the PC market. Not a fan of the Apple ecosystem lock in but that's just me, its worse than Android/Google.

Obviously they all have bad points but that's my point. All these companies have their good and bad sides. I just feel the hate Microsoft gets a lot more hate vs other tech companies. Especially given recent changes, is a bit over the top.

To be honest out of the big tech companies which one is not there to "screw users" as you put it? Especially the ones that depend on ad revenue.

- Facebook: Their users are their product. There's enough evidence to show how they "use" their users daily in news articles, leaks, etc. Recently if I recall there was a leak about them knowing the harm on children their products cause but internal culture stopping them from doing anything on that front.

- Google: The amount of data they use to target users. Users again are the product. They drop platforms/technologies like the drop of a hat.

- Apple: Heard some stories about culture there as well that aren't crash hot. Is Swift/Objective C even OSS? Very proprietory but their brand seems to give them the cool factor? Not sure.

- Amazon: How they treat their non-tech employees, etc.

- etc etc etc.

They are all companies and in the end of the day profit matters once they get to a certain size. They all have their good and bad sides. Microsoft seems to have an "uncool" image here IMO probably originating from their dominance in a previous tech age but I can't see the difference now with other big tech companies that hold this level of market power. In some ways they are better - they don't need my whole life story and invade my privacy to make money if you care about that sort of thing. They also have pushed some good technology as well - the new .NET Core platform is impressive and in my testing good performance, decent languages originating some good ideas (as do other langs), still OSS with less confusion than for example all those JDK's on offer. There's good and bad parts in all companies, and tech stacks.

Can it be better? Yes. But that applies to most tech stacks, cultures and companies as well.

Agree with this. What's more interesting is on the feature level languages do borrow/converge on each other in order to try to secure a position in the market. I note that as an example Java is consdering a .NET like Span feature (https://openjdk.java.net/jeps/412) as an example probably to close the gap w.r.t performance. There are others.

What matters more in all honesty, and what's hard to change IMO is:

- The base of the language (is it verbose, how the base features interact with each other) vs being "tacked on". A language with these features initially. e.g. you mention F# and I know it uses HM type inference, immutability by null, makes null hard to express by default, etc.

- Anything that breaks backwards compatibility (e.g. Java's generic implementation) for example including existing API's. Adding Async afterwards takes time, and changing the underlying model of the language (e.g. Python's GIL, OcAML multithreading) takes time and needs a lot more consideration. Its code, anything can change, its just harder and maybe easier to take something that was designed for that case initially. Being a polygot isn't a bad thing per se I think if it can be justified tech wise.

Just like any other human made structure even outside of programming I've known. Admittedly I think the foundation is mostly independent from .NET and is around open source projects in the ecosystem limiting the damage this could cause. Even if it is changing hands, or even collapses its role is limited and I argue doesn't affect the adoption or usage of the platform all that much.

On the other hand as an example I have experience first hand where this stuff can matter relating to some other comments on this thread: the confusion around which JVM distribution to use is directly tied to the JVM and its different builds. That doesn't seem to be the biggest problem for people in that ecosystem, but just like this .NET foundation topic confuses people outside the ecosystem as people are cautious and don't understand the implications. (i.e. do I have to pay Oracle for support if I need to limit my liability?). If I'm choosing between two tech stacks and only one has this question mark in a time limited fashion I might choose an alternative instead.

Other languages requiring significant investment (e.g. Corporate Languages) have their issues too. The appeal of Java and the .NET platforms to me is their longevity and their seriousness in keeping it alive over the decades.

Where required there are ways to force it to inline/devirtualise yourself. For example using refied generics is one way I've seen - i.e. there is no interface/virtual casting since it takes a type that implements interface, rather than the interface itself. It allows you to make polymorphism compile time rather than runtime. Seem comparison libraries to Java (closed source) that have run much faster as a result.

I do find people comparing Java and .NET Core often are compare apples to oranges however. Working on both languages it is just my opinion but the .NET platform is newer - it has a better "base" even without the same man hours. Much of the engineering time in both ecosystems is spent optimising for code typical to that ecosystem which is affected by history/legacy like any other software system.

I never buy into the tech stack argument that things are being worked on (e.g you mention Project Vahalla but I see this across many languages and tools). Seen this argument used on a number of different technologies. It compares a future state to a current state to put the favored tech (the future state) in an equal or better position. It usually punishes innovative platforms as well; because it dismisses any reason to take them up.

It's comparing apples to oranges - in this case .NET is also being actively worked on so may have other things by then. Compare current state only.

The truth is each platform has prioritized features relevant to its context. For what its worth in my experience while the JVM has many more JIT optimisations and the like it tends to need them more of them given the lack of some of those features you mention (e.g. value types). Whereas .NET code allows value types, better management of memory (i.e. Span), reified generics etc so the focus has been to allow the user to optimise themselves where required where still allowing for a decent performance default. Many of the optimisations in the JVM wouldn't have the same bang for buck in .NET and vice versa.

On a personal note I'm more of a fan of the .NET philosophy because the code is usually fast enough, and when I need to tune memory, avoid allocations, and do fast code it seems to offer more tools not in an unsafe context to do so. It allows a better "upper bound" of performance for core things IMO while keeping to bytecode/IL. Many benchmarks where the same level of application optimisation has occured from what I seen have confirmed this bias for me. YMMV

Agreed; especially since it didn't have it originally. I'm sure some compromises were made to do it in a way that fits into the execution model/doesn't cause regressions to older code. They are both good languages for sure which makes sense because one is derived from the other.

F# through itself and .NET has had the equivalent functionality for many years however (Threads, Tasks, Async's, Channel libraries, etc) being the one of the first languages (before C#) to have an Async construct. I would imagine it would take some time I think for OcAML's ecosystem to catch up API wise with this where it matters for application development. Looking at OcAML's recent release notes I see work to slowly migrate multicore into OcAML but the feature itself hasn't landed yet? Think it comes in 5.0.

I have to say though F# performance is quite good too those days from working/dabbling with both languages + the ecosystem is bigger. I would like to see/understand where the OcAML perf advantage is there is any for evaluation. The CLR has really good performance these days; its has features to optimise some things (e.g. value types make a big difference to some data structures, hot loops vs the JVM) from my experience especially if you don't allow Unsafe code for many algo's/data structures. For example I just looked at the benchmarks game (I know has its problems including bad contributed implementations for niche ecosystems) but it shows .NET Core (and therefore F#) performance is within the same scale as OcAML at times beating it (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...).

In my experience that isn't quite true. You usually OO for IO/interop if a C# library is being used, then its module code for the most part all the way down (e.g. ASP NET Core define a class for the controller, then have it interop to F# FP code for the most parts). With some newer F# frameworks you don't even have to do that these days.

Having some experience with large scale F# codebases its rare you define a class compared to records, unions and functions. 100's of functions, 50-100 small types, 1-2 classes approx is usually the ratio I've seen for a typical microservice (YMMV).

Its still nice to have shared memory especially in a functional language where due to lots more immutability it isn't as big of a price (i.e. more concurrency safe). Especially if your sharing in-memory caches and the like.

I've seen this save tons of dollars in cloud setups (100,000's) in my career in more than one place. Safe multi-threading was marketed as part of the advantage of functional programming to many people; which IMO why I find it strange that OcAML didn't have it for so long. Lightweight threads (e.g. Tasks, Channels, etc) use less system resources than processes as well.

You can do anything with anything but you usually pay some price of inefficiency to do so. That may be small, but sometimes it is large enough to matter.

I've seen both being used by hedge funds and finance/banks actually. A lot of F# use anecdotally is closed source finance (this has changed now I think) which is why IMO it didn't have as much open source visibility or people showing its use. OcAML is probably in a similar boat. Having hidden use cases however means breaking changes in the language are harder to judge.

The real reason is to attract and onboard people onto the platform. Part of me always felt they should of just put a functional wrapper on their APIs, have an API that avoids the mutative fluent interface, and then just show some F# examples. Especially for people outside the .NET ecosystem it would show how terse, yet performant and feature rich the platform actually is. It would compare well to examples from other langs/ecosystems.

In the workplaces I've been in newer developers typically try then abandon the OO paradigm. They've seen they can get by without it and get decent performance, and there is a learning curve which experienced people have already paid for and typically then take for granted (patterns, DI, class structure, interfaces vs abstract classes, etc etc etc).

A bit late but I can comment to be informative.

> I'd need to see evidence, it's hard to believe .NET can offer anything more performant than say Vert.x or Micronaut :-)

Benchmarking is interesting because it depends on your case, and the tricks used in the benchmark. Techempower has proxy benchmark at https://www.techempower.com/benchmarks/#section=data-r20&hw=... for just the web layer which shows aspcore quite high. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... I note it isn't as good with DB queries (DB framework) than Vert.x which gives points to Scala for db like APIs but there's tricks there too. Benchmark Game seems to have F# compare well with Java and OcAML (low level non-idiomatic code there I'm sure too). Been meaning to try Vert.x.

- Futures/async/await are ubiquitous in Scala

I need to look into this more but using them in the past it seems very library based (map/foreach/for comprehensions/flatMap/etc) whereas the .NET implementations tend to be like co-routines (state machine) that are compile time constructs with associated perf benefits. It adds a lot to performance; you want the async primitive to be as cheap especially if doing them in hot loops - .NET articles are full of Task/Async patterns and their benchmarks and optimizations to Tasks are constantly ongoing.

> - Scala has value types

Not in a way that I use them I guess. https://docs.scala-lang.org/overviews/core/value-classes.htm... shows quite a few limitations. They may be overcome with Project Valhalla? but it isn't there yet - its a JVM limitation not a Scala one.

They seem to be extremely limiting compared to .NET types where you can compose things together (more than one value, etc). I use this for math ALL the time avoiding any GC events at all - there's a lot of cases for quick stack allocated values that can cross function boundaries. I've worked on the JVM - its possible but much harder with uglier code. .NET seems to have many more ways to avoid "boxing" than the JVM when the JIT doesn't catch it. Especially with generic methods (unless inlined). Basic tuples, ValueTasks (like futures) and such all use this construct at times.

- JVM has plenty low level performance tricks

Sure it does. I'm liking the new things in .NET Core like Span making it "safe" to do them vs Unsafe and interop. Re-using memory (slicing parts of strings without cloning chars), etc in a safe manner is a simple example but there are others.

> Scala is plenty close to the JVM

Plenty of its abstractions however however require allocations and objects (e.g. implicits everywhere) - futures being one. IMO maybe its just me but it is easier to reason about F# performance. An example in F# would be that many allocations are only allowed explicitly (e.g. math conversions) - it actively discourages implicit behaviour for simplicity I feel. e.g. Auto-Boxing in erased generics has caused perf problems in some JVM programs I used to work on. Both platforms are capable and have their own pitfalls of course.

- self-packaged bundle' capabilities

.NET Core feature.

I think there are factors to consider one over the other; just like sometimes OcAML could be a good choice as well. I wouldn't dismiss F# for production use however having seen it used successfully on large things in Windows and Linux environments.

> talking about adoption and name recognition among non-engineers

Agree that non-engineer recognition it is a poor way to run projects but sadly that matters to some engineers I've talked to as well + comfort zones. Having F#/Scala experience means they could always find a C#/Java job and that depends on the city/industry you are in as an example.

> I see no compelling reason to adopt it over JVM

That's an opinion preferring the JVM over the CLR which is a stating potentially a personal preference? Technically both are capable so I think that's a moot point - the CLR is pretty good and Java on some things is playing catchup (e.g. value types). JVM is good too but the differences won't probably mean much to most projects.

> Scala probably has at least twice the adoption levels of F#

Scala has many good points and some use cases better than F# for sure. However to play the other side some reasons I can think of on the F# side include that default web performance favors ASP.NET Core (even on Linux) from bench marking by quite a bit over say Spring Boot/Play. The HM type inference also is a plus for F# IMO (as it is for OcAML) and it leans to being more FP first giving the FP benefits quicker with less fuss. The multi threading (Futures/Async-Await) API seems more ubiquitous in the .NET space last time I checked, less LOC to use, and is exposed on a lot more libraries/clients/etc as a first class citizen. Its also IMO a lot easier to make your whole program async and has more inbuilt language support to avoid overhead. Important things in hosting an API I think especially around thread use/scalability. F# has things like value types, compile time generics, tail recursion (for FP), Spans, and other CLR features etc which allow that low level performance tuning where required - it seems to be closer to the CLR than say Scala is to the JVM. Something I do like, just like C#, is to compile it to self packaged bundles for multiple targets (ARM, MacOS, Windows, etc) in a smaller bundle than JVM based apps.

Popularity is a proxy for risk. I would assert it only matters IF the base isn't mature and it doesn't have an ecosystem to piggy back on. Popularity is a proxy measure for "something's probably missing" which for say Scala/F# isn't really the case given their ecosystems depending on your use case. OcAML is probably less popular than F# as an example but for certain use cases could still work - sadly it doesn't have that ecosystem to piggy back of and that is a factor for some teams (not all but many I've been in). F#'s been around for awhile and reasonably mature as a base.

Scala is a good language too. But I wouldn't dismiss F# in these comparisons either. There's nuances that need to be considered. Where you want a language with the crisp FP first feel/benefits of OcAML with an ecosystem just large enough to avoid risk F# is a good compromise and will work quite well. TL;DR Nothing's perfect, more similarities than differences, and as long as you aren't blocked language isn't the big factor in project success/failure that many make it out to be.

I like OcAML as well - in fact I stated that. The original reply was to a comment comparing OcAML to F# in the context of adoption in a company to a risk adverse poster worried about costing the company "mega dollars", where one reply dismissed F# due to .NET interop. My point was really that's also the reason why IMO it is less risky to adopt for many corporations for a person such as this - there's less chance to be blocked by some missing thing. Awkward but workable on the edge cases beats having to do more work for many projects in the real world we live in.

F# isn't that risky of a language to adopt and even to non-engineer management types as you say - it's .NET. To most of them, they wouldn't know the difference so in that context it is "less risky" for that poster.

I replied with my opinion that for many enterprises (not all) looking to move into FP, F# would seem a less drastic change with many of the benefits (library interoperability/ecosystem size, threading, etc). That doesn't apply to the use cases in this article which is great/fantastic - I'm all for that!

I actually agree with most of your points, but adoption is just as much about convincing others as it is technical qualities, maybe even more so. Getting people onto the journey and making them comfortable with the risk is important.

I would argue with .NET Core F# more has an equal place on the server side (Linux even) given the problems it is more geared to solving. They are both good languages, one is based on the other after all with slightly different tradeoffs. Both OcAML and F# are more similar than different IMO.

>That's not necessarily a positive. Our job is to deliver business value, not follow the latest fashionable trends.

Just to clarify latest trends don't mean untried tech, it sometimes means just new features of existing products making it into your ecosystem. Some examples I can think of include an AWS SDK adding an option to to their SDK's for a well used product that suits your project, better well-tested support for a message bus library used by your company, a vendor product mandated by your organisation providing only mainstream language SDK's (Node, Java, .NET), etc. Yes I could make my own SDK's in OcAML (I like the lang btw) but then I'm not "delivering business value" as per your comment. It also increases the risk of project failure using the time budget allocated - in the team's I've seen using FP this would of been a real risk.

> "Basic things like multi-threading"

In my time I've seen many projects switch from Node/Python APIs to Java/.NET/C++/etc when they become high scale backends just to take advantage of the better performance envelope. Java/.NET usually is chosen if multi-threading is appropriate. Seen this happen a lot and its pretty common. Seen savings up to 200k+ USD a year for just one component where going multi-threaded helped. Its quite common once a business reaches a certain scale to desire multi-threading for a number of business cases.

> For most line-of-business/CRUD/APIs/etc.

For those standard CRUD API's you mention unfortunately the ability to use Ocaml, F#, or any other functional language often is reduced unless you are doing it already for other value reasons - its hard to justify the value add over say Java, C# or even Node. The app probably isn't doing too much anyway other than calling a database and serialising the result to the client.

It's when you add handle data in those API's or data processes, add algorithms to them (e.g. processing engines, etc), handle data pipelines that FP IMO shows its true business value, and those cases often benefit from multi-threading and/or shared immutable state. F# does well at that, has good async support, and most of the FP goodies (strong typing, type inference, etc), and has an acceptable performance (.NET is pretty good these days).

In the end my point is I think F# right now IMO is much "less risky" out of the two to adopt for most corps especially if you are doing data transformation, pipelines, and APIs (given ASP.NET Core's speed these days) especially with the broader library support. YMMV of course and this is a general opinionated statement - if those adoption risks don't apply to what you are developing great.

Sure - those applications generate C# code in the background so that's that. Its not that F# couldn't do it, but the no language that's coded by a human competes with auto-generated tooling backend (XAML to C# form code). XAML and the widgets behind them are not designed with a code first flow in mind - so when they generate 100's LOC of C# spaghetti I don't expect to code that by hand in any lang. In that case I would choose C#, or more to the point, the Designer and whatever language it generates - the language is secondary.

Those apps you list are also not cross platform as I mentioned in my comment. They are also not the apps you typically code in Ocaml either which is where the comparison/comment was coming from I feel. For cross platform development and some of the software typical when comparing F# to Ocaml, F# IMO is perfectly fine and on par with C# (sometimes better depending on the problem space).

For vendor specific issues F# ports pretty well to C#. For the very odd time you've proven a bug in F# its pretty easy to whip up a quick C# project to give to one of those "vendors" (half an hour/1 hr maybe to build a repro you would need to do anyway). To be honest most of the time they don't help you with C# either - support sadly in my experience is only on paper and never covers you fast enough when you need it. It's just a tick in the box that you have the risk covered should you ever need to resort to this; which many projects never do.

I get your point for some applications, and if you are doing those kinds of apps fair enough. Use the right tool for the job. But I personally think for languages in the JVM/.NET camp the risks of project failure are overblown and aren't as big as people make them out to be especially if they are pragmatic rather than academic and/or syntax heavy. Given they can piggy back on the bigger ecosystem to avoid getting stuck for edge cases.

I don't think the risk is that bad. Especially if you are using .NET Core as a cross platform target most of the tooling is made for Windows anyway so is mostly unaccessible. VS Code for example works reasonably as good as any other VS extension - in my experience works better than the Java one. For a functional language it has a pretty good tooling story.

For the standard Docker microservice (e.g. ASP.NET Core, GRPC, etc stack) the tooling is more than adequate.

F# is mostly a superset of C# features these days with a much smaller lag in gaps than the other way around. On the protected members it isn't the biggest issue either - you can still override the method in your app code but it just changes it to public instead for the derived class. For interoperability to override C# classes it works and you wouldn't normally notice any difference; and in F# code you tend not to use the pattern anyway preferring composition to large object hierarchies. So your not blocked from overriding protected members on derived classes if you need to get a method overriden in a 3rd party C# library.

You may be giving the impression that there is missing capability from F# that will cause risk and block your project. Given I've used it professionally I don't think that's actually the case - it won't block you from developing anything that you couldn't do in C#. At worse case - if you actually want to use the really edge case C# features you can always create another project just for that bit of code and call it from F# code given the good interoperability. There's usually ways around this too.

As someone who's used both I generally am not as big of a fan of OcAML where it matters - usage in most companies and projects. Sure it has some features that are nice but often they are "nice to have's", whereas the F# has things that IMO are more necessary for day to day development. Basic things like multi-threading last time I checked weren't as ideal (particularly for FP languages where this can shine); and the library ecosystem in F# basically takes in all of .NET reducing the risk of adoption substantially. At least my team will never be stuck inter-operating with some product, and can keep up with latest trends.

What's important are minimising the risk of adoption and also allow FP to show its value since that's what will make the adoption successful. I don't want my dev's to be stuck when adopting the new technology for a project because there is a library missing.

On the C# side depends on the problem space. If your working in a space where FP can help shave dev time substantially then F# is the better choice IMO. C# is not bad, but F# shines in certain domains in terms of dev time in my experience.

Why not both? Seen that work quite well.

All languages have their issues though, and they all make different tradeoffs. After using a number of languages compared to say C#/Java/Scala/Ocaml/etc I don't find F#'s limitations that crippling. In fact I think F# when you look at the swathe of languages with a big enough library ecosystem it makes a lot less tradeoffs than other languages in its class. At least for me it seems to be a good balance between simplicity, conciseness, expressiveness and performance - in some ways it seems nicer to code in and bring teams up in than some other functional languages I've seen. I've seen many teams adopt and then go back to Java from Clojure and Scala for example due to the complexity of the code that arises from people being too smart with the language.

The feature you state (F# unions) - that simplification has some positives as well. I can exhaustive pattern match for example. I can always use composition/pattern matching/active patterns to mix in other assemblies types cases. Is it really limiting that it doesn't do this? Would changing this mean more complexity and make other language features harder to deliver? All features introduce some additional complexity, and it more than linear typically. F# also has some interesting patterns that were either introduced first there en masse (e.g Async) or are easier to use there.

I'm a fan of static checking, and conciseness with performance close to the platform it is hosted on and is easy to reason about. I'm also a fan of easy to read and clean code that isn't "scary" to look at. F# seems to strike that balance well compared to other JIT functional languages, at least from where I’m sitting. Too much complexity and you start scaring people away and/or too much abstraction in the codebase starts to occur trading off maintainability.

Let's be honest. IMO the assumption of Australia being an island was right (as evidenced by the states that made sure their states were islands most notably WA). At this stage WA is clearly the "gold standard" of COVID management, not NSW. NSW, given the numbers it was taking through its "hotels" which never should of been permanent quarantine facilities in any case was not "an island" at all. They arguably were just lucky most of this time, and through hubris of the local people there this was considered good "gold standard" management.

The low tech easy solution for a country like Australia is really better quarantine facilities (i.e. not hotels in the middle of population centers) IMO coupled with a vaccine rollout geared to workers at the quarantine facility (and potentially freight facilities). Its easier to rollout the vaccine and subsequent updates to it for future variants to a smaller number quicker. States in Australia that limited their international intake seem to be doing better than particularly Sydney who were taking the most arrivals. It really isn't an island when your taking the brunt of international arrivals. The fact that it was even working (hotels) for as long as it did shows the effectiveness of a good quarantine strategy. Low tech, simple solutions usually trump high tech solutions that require everyone to participate (problem of the commons).