I don't know if I would say 'well'. For simple GUIs it's OK but, for non-trivial GUIs I would use the approach to write the GUI frontend code in C# and have it call the F# 'backend'. If for no other reason than that the support and documentation for doing GUIs in C# is much better.
How about mobile?
Never tried, but I'm guessing more or less the same story as above. I would probably start by looking into .Net MAUI for that.
And how does it compare to e.g. Scala?
The biggest difference is that Scala is a much bigger and more of a multi-paradigm language. F# feels smaller and more focused and on its ML roots and functional programming. Not saying that Scala is less 'functional' than F#, but Scala supports you writing your code in a much more OOP way if you want. Yes you can (and sometimes have to) do OOP in F#, but it doesn't feel natural.
no shortage of people saying that the only thing that matters is your algorithms.
To be a little bit fair to those people, I have been in many situations where people go "my matlab/python code is too slow, I must re-write it in C", and I've been able to get an order of magnitude improvement by re-writing the code in the same language. Hell I've ported terrible Fortran code to python/numpy and gotten significant performance improvement. Of course taking that well written code and re-writing that in well written C will probably give you a further order of magnitude improvement. Fast code in a slow language can beat slow code in a fast language, but obviously never beat fast code in a fast language.
Hejlsberg seemed quite negative when it came to cross platform AOT compiled C# in several comments he's made, hinting at problems with both performance and maturity on certain platforms.
Yea, sounds like cross platform AOT compiled C# not being mature and performant was a big reason that C# was rejected.
One other thing I forgot to mention was that he talked about how the current compiler was mostly written as more or less pure functions operating on data structures, as opposed to being object oriented, and that this fits very well with the Go way of doing things, making 1:1 port much easier.
Why is the TypeScript team moving to an entirely different technology
A few things mentioned in an interview:
Cannot build native binaries from TypeScript
Cannot as easily take advantage of concurrency in TypeScript
Writing fast TypeScript requires you to write things in a way that isn't 'normal' idiomatic TypeScript. Easier to onboard new people onto a more idiomatic codebase.
The question comes up and he quickly glosses over it, but by the sound of it he isn't impressed with the performance or support of AOT compiled C# on all targeted platforms.
I worked at Cyberia's second location in Kingston in 1995
Wow, now there is a blast from the past! I hung out there quite a bit in 1995-1996. That was also the first place I used the actual internet (as opposed to BBS's or CompuServe), shortly after it opened. I can probably thank Cyberia for at least a small part of my future career success.
It's essentially a case of brand dilution. Today 'Harry Potter' is a brand that has certain values. If a new Harry Potter book shows up on the shelves tomorrow I can be very sure it's a kid friendly, easy to read, book about wizards. People can feel safe buying as a present for their niece or grand child that likes Harry Potter. In this alternate future a 'Harry Potter' book could be literally anything. If that is 'good' or 'bad' is left as an exercise to the reader, but something would definitely be lost.
Would the copyright holders of Zork get royalties in this scenario, like with cover versions of songs?
The other problem is that in this scenario people will just be slapping the names of things that were popular x+10 years ago on literally anything. People will just make the lowest effort loot box laden pay-to-win mobile games you can get onto the App Store, and advertise them as sequel or tie-in to that old popular game/book/movie.
Copyright timer would be reset for every new release. So the version of the library you released in 2000 would be out of copyright, but the version you released last month wouldn't be. I guess there is a risk that someone will take your version from 2000, reverse engineer it, and release a competing product, but it seems like a minor risk.
authors whose work still has some commercial value decades after its creation.
Sure, but who should capture that value for those works. Is it more fair that all the value goes to the publishers and TV/movie studios making adaptations, rather than some of it being shared with the author.
start a bunch of threads and e.g. invoke subprocess.run() from them
Done that many, many times and honestly combining python with parallel is in many cases the best way to go. Write your python script to be as fast as possible on one core and then use parallel to run it on all your cores. This has the added advantage that you can go from running on all the cores on your machine to running on all the cores on a 100 machine cluster by just changing a couple of lines of code.
I don't know if I would say 'well'. For simple GUIs it's OK but, for non-trivial GUIs I would use the approach to write the GUI frontend code in C# and have it call the F# 'backend'. If for no other reason than that the support and documentation for doing GUIs in C# is much better.
How about mobile?
Never tried, but I'm guessing more or less the same story as above. I would probably start by looking into .Net MAUI for that.
And how does it compare to e.g. Scala?
The biggest difference is that Scala is a much bigger and more of a multi-paradigm language. F# feels smaller and more focused and on its ML roots and functional programming. Not saying that Scala is less 'functional' than F#, but Scala supports you writing your code in a much more OOP way if you want. Yes you can (and sometimes have to) do OOP in F#, but it doesn't feel natural.