throw868788

Indeed. The company I work for uses F# for large revenue workloads across many services; mostly coming from non .NET dev's. It handles large scale customer traffic quite well without a hiccup and with the C# interop we never find we are blocked (e.g enterprise/vendor libs). They found it easier to learn F# than C# - it has a lot more in common with JS/Go/etc in how code is structured and maintained from their POV. Good mentorship is critical for learning and deriving extra value from it especially if coming from old C#/Java/etc. The push for C# to minimal APIs, less classes, etc from our experience has slowly made it less necessary to have F# wrappers as well - the interop ugliness usually only resides in one file (e.g. ASP.NET Startup.fs or equilvalent in given C# framework). Given our proprietary nature however we don't broadcast a lot of our dev effort/development online - I assume many F# shops are/were similar.

We've created very large scale applications in it requiring significant throughput. One of its benefits is also its disadvantages - we typically are quite productive in it and so don't feel the need to hire as many people in the team. Before LLM's were a thing we found we were wasting less time with boilerplate in general than our C# code for example. YMMV.

Its funny because I've found the opposite; the fact that the smaller community (and lets face it - most FP langs have a much smaller community than needed to get the scale you are after) the more it needs to piggy back on the army of engineers in the mainstream language target and stick to only its value add as a technology. There were web frameworks in F# that were written from scratch, but fundamentally ASP.NET is quite good and fast enough at least from my evaluations and these frameworks are now out of favor.

I personally don't have much issues using ASP.NET directly from F# (don't bother with Giraffe or anything like that); its not too hard. The routing layer is only a few classes/functions anyway - it isn't the majority of your program. I guess maybe I'm in a different position to you - I find for the few bits of ASP.NET config it isn't worth switching to C#. A few rules you need to follow but I would say that is a lot less than the Clojure learning curve and you get static typing still - that is just my opinion however.

My experience is that both languages have their pros/cons and tbh both have their challenges w.r.t adoption. My personal view is most of these challenges are not technical. The issues we complain about with the language as developers are IMO minor (i.e. things are still possible or decent compared to some other languages) and probably aren't the major factor in the wide scale technology choice away from FP in general.

For better or worse developers are often "languages takers" not "language deciders" in most big shops and this is where most of the jobs are - its only in niche elements/problem spaces (i.e small shops, dedicated niche teams, etc) where niche technologies can be worth it. This means not a lot of jobs; but when there is a job it can be higher paying. Big employers drive the market for technologies though when it comes to large scale usage and they want commodity fungible developers (i.e. resources), and are happy using a mediocre tech that gets the job done to do it. Unless there is a "killer app" where the language must be used to unlock the value most managements will stay clear of better tech - predictable, boring, commodity tech that I can get anyone in for (contractor, offshore person, etc) wins for them every time especially for the MBA/product manager/etc types. In the current economic climate developers are trying to meet the jobs that are being advertised as well (higher interest rates, less startup's, etc etc).

I do think this depends on region, as I've seen F# and Scala jobs typically outnumber Clojure for example depending on whether it is a .NET or Java shop. Mileage does vary.

However to be honest anecdotally I do think even if they aren't going down in user terms, FP languages are losing percentage market share. From my personal experience FP is no longer new; the hype of FP in general has died down. The hype has moved onto other things over the years (e.g. AI, blockchain, bare metal technologies that enable the above, etc etc).

I'm not saying FP doesn't have a lot of value. I enjoy, particularly when the program calls for it, FP languages like F#, Scala, etc. They still offer a lot of value IMO for all the usual spouted reasons.

IMO I just think the hype has moved from technologies that do things better (i.e. more efficient, less error prone, makes my job easier, etc) to technologies that do shiny new things. There are a lot of reasons for this, many of them aren't in fact technical but economic and political (e.g. management). Things like less jobs globally in tech (meaning my skills need to have wider reach), demand for specialist roles that aren't as language focused, etc play a part. Mainstream languages taking FP features as well makes the return vs risk of using a FP language even worse of a tradeoff - there's less perceived return for changing stack than before.

Would be interesting to see actual stats in F# usage which I doubt are relatively available. Given the reaction to this post from what is an old article there's still probably an underground interest in the language and some use in general. People seem to have built strong views on it either way. Especially with some posters admitting they use it professionally with a closed source culture (finance, insurance, etc). Most metrics would not be accurate given interoperability with C# - e.g Google searching I would typically look up C# code and port it for example.

Maybe it doesn't need to thrive for everyone; maybe it just needs to continue being useful for the people who employ it and add value. That's probably OK. They could be just busy building stuff instead of blogging, especially if the community is mostly compromised of senior developers (10 years +).

Seems like a common theme that people prefer the F# language, but try to explain reasons why it hasn't succeeded from a technical view. I think the reasons IMO aren't technical but what the author has stated - C# is probably worse (that's my opinion) but people who are working in it don't see the pain. Its marketing, the vibe, etc. Most of the tech issues people state wouldn't be there if adoption was bigger.

This is in contrast to Java which for a significant time wasn't showing any evolution which sparked many alt langs on that platform. Sometimes things succeed but silently, and sometimes things that should succeed just don't and maybe there isn't a real explanation. In fact I think the latter across most products is actually the most common outcome, not just in programming languages.

TL;DR I agree with the article, it suffers from an adoption chasm. Pain and herd safety are important especially when people are considering their career progression.

To your dot points:

* I think F# has .NET which is a "proven" and good enough ecosystem as well. You won't get stuck by picking F# even if it means using a C# library. Have to do the same in Scala/Kotlin and the like typically as well.

* Editor has caught up, my surprise is that you can write with Vim and kinda get away with it - only find that works in terser/scripting like languages anyway unlike C#. It has wrappers and libraries for doing things in a more F# FP manner if you wish although when I was doing F# I avoided them (i.e. I avoid things like ScalaX most of the time too).

* F# has a good scripting story; I've seen F# scripts used quite often by people even if coding in C# to check things and REPL program.

* These days F# just works too mostly. `dotnet new webapi/console/etc -lang F#` and you have a webapi for example.

* There are F# libraries around for similar things (Http, Collections, Async seq, etc). They are probably maintained to the level they realistically need to be, I would argue they still do their singular job quite well. At some point a library just does what it needs to do.

There's things I prefer in the .NET ecosystem as well - value types, inlining, etc. Having said that I seen quite a few people use it professionally to good success but they often don't brag about it and are usually quite senior and reserved about their language choice often citing other worries/risks to a project's success.

There are differences between implicit/pre-emptive and co-operative multitasking though and there is probably tradeoffs for each. For Java however, much of the existing API exposes Threads, and locks. How do you introduce better scale of existing threading code without too much porting/changes to existing codebases wihtout significant rewrites? The "we are where we are" problem exists a lot more in Java than say .NET/Node/Go/etc which IMO tips the scales more to this kind of approach.

I think that both approaches solve a lot of the same problems, but there is some problems that fit one paradigm better than the other and I don't think they are entirely mutually exclusive either. I've heard it mentioned with Loom it solves the async "colour" probglem however I think people "overblow" the color problem of the Async API too much. If most things are async it isn't really that painful. I actually like when something is marked "async" and I have to be careful how to use it. How is it async? Can the code run in parallel and join later? Is there race condition potential? Deadlock? How is it actually async, what's it sync vs async behaviour? How do I propogate the need to halt the async operation across multiple layers? Who owns the whole workflow, can I make sure the async context is propagated to that layer so they can cancel it for example?

Probably an unpopular opinion but knowing a method has async behavior, at the type level, could be a feature not a bug. It forces you to handle it at the sync/async junction and think about these things.

I see that in places I've worked. I've always resisted growing my team's headcount as I've seen it break efficiency first hand. However I'm well aware it makes our team less noticed, and less attractive when other companies ask what's my current reporting count as a metric of how senior you are.

I've used F# in a professional job and its fine - on very large scale apps for large corps. There's features in it that I feel make certain apps much easier to write that have no equivalent in C# or C# is just starting to get them. Its also easier to teach IMO than C# since code typically uses less concepts.

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.

I think this is a problem with many languages - e.g. Scala, Kotlin, etc. The easier justification really is: Does it fit your problem space? Will you save dev time overall, is it more maintainable using this tool? Do your staff prefer working with one tool over the other? Does it meet business objectives?

I don't think F# will ever be more than niche; that I can agree with you. Not because of any technical reason though; perception and marketing unfortunately does matter. Your points around "investment", etc are to me impressions/metrics around that.

In the end these things are just tools. I'm personally in a team that is doing a lot of generic math, and in our .NET based projects F# seems easier and quicker to get that performance. I know C# preview adds some improvements here but it seems more complicated than the F# approach.

Just use a mixed solution then i.e. why not both? You're picking one thing that F# isn't great at - generated code tooling which IMO isn't in the spirit of many modern languages anyway. I don't get why some C# devs tend to be antagonistic to F#. Not suited to what you use? That's fine but that doesn't mean it isn't good for others. I've seen dev's coming from other languages to F# and thinking its brilliant that would of never approached C#. I agree that each language has its sweet spot. Looking at their feature sets I think:

- Domain modelling, algorithm, business logic, etc is easier with F# in general. C# is getting better than this, but F# is there and has been there for a long time.

- Integrating with build tooling and generation tends to be C# because these tools were designed for that target (i.e not the language itself). The value is in the tooling and the engineering in that - C# just happens to be the target.

Personally with the above I've found most of the logic tends to be in F# with some C# projects for where the packages needs that build tooling support (i.e. not the language or syntax, but for the tooling or other features of Roslyn). An example would be Grpc.Tools. Most of the time these projects can use generated code anyway so the writing of C# can be kept to a minimum - i.e. not one single C# file in the C# project. Besides I think the learning curve/barrier for a language isn't really syntax, or language features - its the libraries to use, the patterns, the ecosystem, package manager, CI/CD settings, etc. Using F# isn't a large cost once you've learnt all those things that are shared which is way more than isn't.

My view: F#, or to be honest a cross-platform IDE like VS Code isn't probably appropriate for many of these apps or rather the dev workflow that Microsoft promote in those frameworks feels like old .NET to me. The frameworks themselves weren't designed for a minimal IDE, and language first development initially often assuming dev is in full Visual Studio with GUI XAML editors, EF designers, etc. To be bluntly honest with my opinion it isn't a dev workflow that would fly/got started in other more open languages including F# which should be develop-able and maintainable with a lot less tooling support.

F# feels like a different dev workflow than C#, which IMO is a very good thing in F#'s favor. It feels more like coding JS, Go, etc to me with static typing and richer features. I also think EF, as it is designed, doesn't lean to the FP approach that well.

I personally don't like EF - I'm happy with something in .NET like DbUp for migrations and straight SQL. Normally I get better performance anyway doing this and in the age of microservices I feel this pattern actually makes it easier to change DB's if you need to (but I still assert you probably never will without a rewrite most of the time) - just use the different query language and port your data access layer. Move to Redis? Just port your F# module that queries the DB in SQL to Redis code. In F# it also allows a richer data modelling experience doing it this way (e.g use of DU's for modelling cases in your domain) since db logic is decoupled from your domain types.

I never believed my domain model had to look similar to my DB table design which is what EF typically encourages. Especially with the modern features of DB's like Postgres you are leaving more and more performance on the table. In the apps I've written doing that leads to lower DB performance than otherwise, sometimes for some quite trivial apps.

TL;DR: Tooling like Resharper, designers, etc is nice but often is there IMO because the language itself is bloated and not expressive enough to just state your original intent there succinctly. If the code is enough then F# can express pretty much what C# can.

These are nice but:

- Templates are no substitute for intuitive and minimal code for a number of reasons. (e.g. how to extend, how to customize, confidence that it isn't brittle if I change one thing, etc etc). If a template doesn't have the exact variation you want (e.g. a faster logging library) the learning curve is very high for a newcomer .NET dev. NOTE: I think this applies to some other OO languages too.

- Suggesting popular packages and namespaces is a great tooling improvement. But it could also imply a closed wall garden. The fact that other non C#/Java like languages don't have this problem even with something as minimal as VS Code as your IDE shows that the tooling is trying to cover over a language and/or library problem. With the Java/C#/other old OO lang workflow you need the knowledge you need to use the library itself (convention based, which class, which extension method, which namespace for that object to configure this feature, startup class conventions, etc). It isn't discoverable even with the packages imported. Remember just getting Serilog working in new ASP.Core and it taking a day or so with all the packages, config, etc etc if you don't already know what you are doing.

I like the improved docs. But fundamentally simplification/minimization is better. I think the dev workflow that means I don't need these tooling improvements is still a better experience. I like .NET, but I do understand when using other languages they seem to not have these issues despite not having the uber tooling that C# has. They don't have package suggestions, they barely even have auto complete yet the library design feels a lot more intuitive.

I can look up say a Fastify, Golang, even some F# examples with something like Giraffe and get a web app quickly with little code and no convention magic with everything being explicit yet concise. No fancy attributes I need to remember, no conventions in my startup classes I need to understand if any customisation, even dep injection is something to learn from people coming from some other platforms rather than just standard library calls composed together.

I actually like the .NET platform, don't get me wrong, I do think it is one of the best web platforms right now. Its more intuitive than Spring/Java as a comparison but that isn't saying much IMO. For newcomers I think the user experience to newcomers who are used to a lot less ceremony could be improved further. My first suggestion would be less "developer headspace required" to get started. On a personal note I think natural F# code tends to favor this from the teams I've been in but can't put my exact finger on a reason as to why - it feels more like coding Go/JS to me at least than C#.

I think that's the barrier with C# in general - the framework nature of it means there's a lot of "I don't know what I don't know" especially with ASP.NET which is quite large in scope. Don't get me wrong - that's the usual dev reaction when switching from their familiar language/tools to a new one but I don't think, at least historically, C#/ASP.NET made it as easy as it could of been. Which namespace do I open to import the right extension method to register swagger generation? How do I configure it? All that stuff IS existent actually and having worked with both in my current role the .NET version eventually ends up being a "just works" experience. Its just hard to approach and integrate if you don't already know the "patterns" and the libraries. Sadly there's a lot to learn compared to say Fastify for a basic working app. However it is very configurable and flexible. I've seen the same reaction from dev's to the Spring Framework as well - its just feels bloated for a lack of a better term to people coming from JS.

As per another comment after having seen JS devs switch to F# for very large professional application and not wanting to go back I feel its fine for web. YMMV.

Honestly I've found F# pretty OK to use compared to some other languages, especially when not using Visual Studio on a non-Windows machine where F# IMO is the better choice. Given a cross-development experience in some of the more recent .NET teams I've been in (great that this is finally occurring btw) especially the Mac developers using VS Code prefer F#. After using it the feedback is that the experience on F#, especially since with F# Resharper is not necessary to function/develop, is preferable over C# (i.e. "its more of a scripting language").

My observation is that the ex JS/Ruby/etc devs learning curve's seem to favor F# over C# as it is more like these languages. There's just a lot less to learn, and the coding style (e.g. modules, function first, etc) is more synonymous with langs like JS than heavy OO languages. I've recently inherited a team that moved to .NET from JS, and getting them to try C# has been painful especially when using things like ASP.NET. There's a lot of knowledge I just took for granted - we don't realise how much knowledge is required to use standard Java/C# OO in a production like setting that many dev's stumbled on when they were junior but have long forgotten the learning curve they went through. They tend to be framework heavy/dependent and require much more experience. From patterns (what's a strategy, repository, etc etc), to dep injection frameworks, to which refactoring tools I need, etc, etc - where in F# in my recent experience the experience is more, but still not quite "just code and work it out as you go".

The pit of success favors F# over C# in my experience with these teams especially if you keep it simple with the features used.

My experience has been that F# appeals to coders who are using the .NET platform coming from languages like JS/Go/etc but also has static typing who usually at least in the jobs I've been in are often on a Mac. C# dev's typically come from Java/C# enterprise kind of shops. Not one is better than the other and I will work in whatever space has interesting problems to solve - I think the difference is more cultural than technical.

He's linked it here: https://devblogs.microsoft.com/oldnewthing/20190913-00/?p=10.... Its a good read. The LE format, especially with UUID 7 like UUID (seq UUID's), seems to be easier/faster to sort just using binary sorting on LE architectures which is most computers nowdays. Interesting to see all these tradeoffs.

This is what I think .NET's generics are like. Type information including all parameters are available, and JIT does as you say. The approach has some advantages (binary size, less memory instantiations when required) but a slight cost when method is first JIT'ed. This only works for VM languages though.

"hey, system, go through this btree, pull these items, merge with items from this other btree, etc”

What I've always wanted in Postgres in one quote expect to also allow other index types (e.g. Hash/BRIN/etc) in its language.

Side benefit: It also allows dev's to understand the pro's/con's of these constructs when using each one and build up their knowledge on what is really just algo's and data structures.

I guess what I don't understand by this proposal is how the exchange rate is actually maintained. Will they print a lot more cash to keep the exchange rate depreciating as thus? The devil will be in the detail of this.

Realising this is what made money a lot easier to understand for me, and simplified the difference between different kinds of money. In the end its easier just to think of them as different currencies with stable pegs. It answers questions like - how can the banks issue money? Of course some of them are easier to exchange with (e.g. bank credit over notes) and this makes them more useful in trades.

For example (bank money = real money) only because the bank is willing to keep the peg at (1.00 bank credit = 1.00 real currency) as you state whenever you use an ATM, take money out at the counter, etc. When the bank runs out of real money to maintain this peg it can and has deviated in the past (e.g. people selling their bank accounts at say 30c to the dollar in the great depression). In normal times however their much smaller money stock is enough to keep the peg going against the usual net deposit/withdrawal flow.

Of course if a central bank comes in and can lend that bank unlimited real money the peg could be maintained. Indeed that can and has happened.

I've defined it myself (when doing C# with functional heavy code but it feels clunky) but there's still edge cases where it isn't as nice especially with functions of multiple args, or functions passed in. Sure C# can do these things with more code, just like F# can jump into some unsafe code, but its nicer in F# IMO. The other thing is that the operator as above is probably allocation heavy especially when needing to complete a function inside the lambda whereas the pipe in F# the compiler just rewrites the code. In hot loops or highly repeated workflows this makes a difference.

C# Fluent API's aren't really piped things since they usually just mutate a variable underneath (hence the ignore often at the end of them in F#). I don't think fluent API's and piped functions are the same thing, and the pipe operator allows any function that matches the signature to be put in.

I do think the pipe operator is very tied into the first-class currying support and HM type inference in F#. In C# I think it makes a lot less sense.

To be honest I think each language should play to their strengths and only "steal" things that benefit their current market of users and how they work. If it augments them that's fine. Otherwise you risk cluttering the language with too many ways to do things. If you want all these F# features you probably just want F# - its not too hard to call `dotnet new classlib -lang F#` these days and mix both in together in a solution.

Having worked in a few C++ shops, at least from my experience, it can result in a lot of useless debates and internal wars if you keep on adding different features from different paradigms into the language whilst trying to keep backwards compatibility.

My view is that if you want unions/non-nullability/data vs classes even if C# gives you the features, it feels more natural to code that way in F# due to the environment around the features and years of optimising that code path. It's just less noisy and less workaround'y. i.e. each language typically prioritizes enhancements and features based on what users in that language are having pain points on. In that sense F# is much further on the data/function paradigm than C# is - conversely when doing low level stuff C# is often in front having to cater for that for some time.

Integrating the two apps hosted on different platforms is also quite difficult normally. Things you take for granted that need to be shared, reachable, etc between apps all now need to be done manually for that snowflake platform.

Sadly in my experience it is common for F# given its finance background at least historically, particularly in London/Europe. There is a culture of not showing your cards in these environments having worked in a few of them, and quietly being a success. Its an "arms race" with your competitors after all - only people in the industry jumping between companies have an idea what their other competitors are using often sometimes with "non-compete" clauses. Meetup's/conferences/articles showing your work are often explicitly banned or at best not encouraged by the companies for commercial reasons.

Different data structures have different tradeoffs that are used for different contexts. Usually arrays are faster than a linked list however I've seen arrays been used pretty badly as well with GC pressure and LOH pauses hence all the ArrayPool, MemoryPool, stuff added recently which mitigates it a little except when you need to hold it for a little longer than the current method/call. When a simple linked list would of GC'ed much easier than a contiguous block of memory (i.e. GC speed/stability more important than the slight gain in iteration speed, and a lot safer especially in high allocation paths). F# offers extra collections based on some patterns you may want to do there (e.g. recursive loops are easier with linked lists than arrays for example) but doesn't set out to provide its own mutable collections given .NET provides those already.

Type inference isn't really in C# other than some simple parts, nor are some of the features that sometimes give F# an advantage with performance that I've used. When you get used to it I find I have to transpile some problems to C# how I would write them in F# with duplication to get the same performance depending on the problem.

If you are used to C# that's fine. Using both I still think F# is usually the better language these days if your coming into it from scratch, although if you aren't maybe the "sunk cost" isn't worth it?

Many of the points here don't necessarily have to do with the language, well at least to me and could easily have occured in other languages such as coding style. Sure - the language uses some sensible defaults and is somewhat pragmatic when to be pure and when to not. But in the end programming can get complex. Even if the language steers you towards practices that lower complexity (a productivity win) you still need to understand what is going on and use the right tool when appropriate.

On a side note the performance thing seems to be a myth to me. There's no reason C# or F# should be faster or slower than one another with enough effort given the same underlying runtime. Many of the functional features are moving to be lower/zero cost in F# (inline lambdas, state machines, etc). They all compile down to IL in the end so as long as you can get the IL you want does it matter? Sure it may be easier to express more performant code in one or another depending on the domain. I could argue many cases where F# was easier to write performant code (numeric, generic algo's, explicit inline functions, inline vs ref, tail rec, compile time polymorphism, avoiding virtual dispatch preferring static functions, etc) and vice versa (native interop, until recently specialised async/await, etc).

If the patient is contagious before developing symptoms, the virus can spread very effectively even if many patients die.

For better or worse all that means is that viruses may evolve to delay their symptoms rather than overall peak severity if that's possible. It means still just as delay but with a good enough delay to spread.

I don't really see the selective pressure however for this virus to become more benign. It seems to have enough people to infect without it given how contagious it is. It doesn't really have to become more benign to allow even more spread.

I'm wondering if there is some inherit flaw in coding some data structures in Node/JS. Maybe this is just another case of the "Node tax"? Things like boxing, floating point number arithmetic, manual pop counts, array copying with bounds checks, etc would all go quite a far way to making for example the Map quite under performant by quite a significant factor especially with large collection sizes and hot loops. Have no idea what the Node runtime does/optimises for example the software version of PopCount encoded in the Immutable.js.

Having written persistent data structures in other lang's that are quite capable (170ns lookup 10,000,000 elements approx to give a rough guide) - yes it is an order slower than unordered hash mutable structures but often still faster than for example the mutable ordered ones I've tested with the advantage of still being immutable. This does benefit some scenarios where you want data sharing/cheap clones of data.

While I personally favour Postgres the biggest thing I think that MySQL has better is the "undo" log vs MVCC vacuum paradigm of Postgres. In a normal running system bad transactions should be significantly rarer than successful transactions - so making sure the normal path generates less garbage is nice. It means less garbage in the database. Tables with high levels of updates don't need high levels of locking or index updates. It also would make things in Postgres more useful like BRIN index - where an update doesn't necessarily need to change physical table order causing index fragmentation. Would make using BRIN index with things like Sequential UUID's on extremely large tables actually viable vs duplicated indexes that cause insert speed issues.

The ironic thing is Australia really only got it when their zero COVID policies weren't taken seriously enough by its weakest actor who was more into "opening up". For people who don't know Australian politics it was the NSW state.

They avoided COVID delta for months (6+) despite locking all incoming arrivals in shared air hotel quarantine systems and workers coming into the quarantine zone day in and day out (i.e. not taking quarantine seriously quarantine). Some Australian states who had better border control policies were able to keep COVID out indefinitely (e.g. WA, QLD, TAS, SA, etc).

Knowing some people who live in WA, despite overseas travel restrictions, life is pretty much pre-2019. Clubs are open, schools are running, no masks, nothing. They are thankful for zero COVID policies - the biggest one being border control and for some areas dedicated, but well resourced, quarantine facilities (NT). Only recently did NT get cases, and it didn't come internationally, but from the NSW outbreak. It's a concern since the indigenous population there typically have less health facilities.

Of course it is much easier to do this in Australia than the US or UK for a variety of reasons. Europe definitely can't do this IMO - land borders aren't strong enough.

The only way you’ll stop this thing from mutating into a variant not covered by the vaccine is by eradicating it everywhere, simultaneously.

When I hear words like everything, everyone, everywhere to describe any system I get disheartened failure is almost assured. I wouldn't design software like that for example. Whether they are engineering systems, social systems, or in this case viruses. Relying on every part to comply is the opposite of redundancy. The probability of getting everyone to comply in a group as large as this planet all at once, at the same time without lags (e.g. vaccine rollouts), etc is sadly IMO extremely small.

We probably need new approaches, some which may challenge the current status quo. I remember watching a video early in COVID where isolating populations into smaller groups allows quick treatment of each group and the ability to contain the spread (i.e. limiting the R factor). As long as highly available world air travel is around, reducing redundancy and increasing the interconnectness of our populations into a single system the virus will have an advantage IMO.