To be fair, data retention is a hot topic right now in Europe, the pandemic and the increased screen time that resulted from it, the amount of accounts we had to create left and right require new regulations.
Do you have a paid account or a free account? If I store my documents on a free account for a one time send to the university application and then I forget about it, then Dropbox should purge it after a time to protect my data, as I don't have any "contract" with them like a subscription or something. The same for G2A, I have bought from them some game keys at a cheap price sometime ago and then I totally forgot that I have one, I couldn't even find the activation mail in my inbox, lol. One day in the summer I woke up with a mail that I have to pay an inactivity fee even if I'm just a row in their database and I have no contractual obligation with them.
I totally support this. It still amazes me that companies still do not delete/anonymize user accounts after periods of inactivity. Everything that is linked to your email address should be purged after 3-12 months of inactivity, including ecommerce like Amazon, game platforms like Steam, cloud storages like Dropbox, or even Hackernews. Good luck trying to find old accounts that you have used years ago, what if they were breached and now they are used by people with bad intentions. In my country (Romania), even barber shops that store user accounts for longer periods than necessary are fined the shit out of them for not closing accounts due to inactivity. Some years ago, I woke up with an inactive G2A account telling me that I have to pay a fee for inactivity. NO! I don't have to pay anything, purge it!
In Romania there's an old question to find the character of somebody: are you Roman or Greek? Because if you are Roman, you put practice above theory, you are a pragmatist, skeptic, if you are Greek you will put theory above practice, you are an idealist, optimist, at the expense of hardships in the material world and other potential drawbacks. Rob Pike chose Roman, otherwise it would have cost Google money to train those people and we don't know if those language features could bring any benefits for the kind of software they develop. As he said, they are not researchers working with category theory, instead they program ever-changing software for an imperfect world driven by profits, rather than academic idealism.
I think the JVM would also be a good choice once Loom lands. I've seen that right now the Java architects are trying to unify the ALGOL flavored Java with ML in the sense of algebraic data structures, pattern matching, local type inference. As you said, OCaml does not have a big community, library ecosystem. It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me.
The complexity that comes from the zero-cost abstractions promoted by both C++ and Rust here isn’t in performance (not runtime nor compiletime) but in programmer reasoning and refactoring.
I agree with you, I believe that simulators, games, software that are "walled-gardens" in the sense that they don't have a lot of interactions with the external world aside from IO and netcode for multiplayer games (that's a pita though), will be usually better in a purely functional model. We must either stay single-threaded or adopt purely functional programming or transactions in those kind of systems. Now, this can be achieved in both C++ and Rust as those kind of systems are not "safety critical", C++ has the edge in metaprogramming while Rust is one step forward in moving the lifetime correctness on the programmer's turf. It's hard to make a point which one is better suited right now as both in my opinion are flawed and have their advantages, it gets evangelical pretty fast. One thing I know is that C++ has the upperhand just because of the sheer amount of libraries that exist in the space and its supporters like Autocad, Valve, Epic and other companies that have billion $ infrastructure built on it.
Right now I'm working with fax machines and I have to provide a C library which is consumed by Scala services. Neither C++ nor Rust would have been an advantage as we are familiar with other methods of verification which are more battletested.
This is why I prefer to write core components in C and then call them through the FFI available in the Java, Python or Node runtimes. Or you can go the "zero-cost abstraction" path which is the middle ground, like C++ or Rust, only that abstractions are not alaways zero cost and low level details will creep into the high level APIs. Different people, different preferences. Like seriously, the only reason I still use C++ is because of its HPC ecosystem coupled with its metaprogramming capabilities which are light years ahead from anything that is offered on the market in that department. This is also the reason why game development can't get out of the C++ trap.
The future of critical low-level programming is a better C or just plain simple C used in tandem with code generators like F*, deductive program verification like Why3 or just good old mathematics that many are irrationaly afraid of like TLA+.
I think PHP gets all the clapping when in fact the statistic that the majority of the Internet uses it to power its services is misleading. Let's face it, Wordpress is a great project, it could have been written in Perl and it would still have had the perks of being Wordpress. When people use it, they don't know what happens behind, I think WP is the perfect example of what a good extensible product is and how it can build an insane ecosystem around it. The plugin architecture is there since 2004, it was and still is very ergonomic. Though Wordpress was not unique in that time, phpBB, vBulletin should be mentioned.
There's no point in creating a new VM, given that you can target almost everything by supporting JVM, CLR, BEAM, V8(JS transpiler) or LLVM/WASM for C-like languages. All you need is an optimized, general purpose IR that will be able to spit bytecode for each one of those and JS in the case of V8. To be fair, I don't think that a language like Kotlin will be able to accomplish this, it is just too complex. I believe that languages with small cores like Clojure with its monumental extension power through macros or Eff or Koka which "let you define advanced control abstractions, like exceptions, async/await, iterators, parsers, ambient state, or probabilistic programs, as a user library in a typed and composable way" such that it will fit runtimes. Like, provide the IR, the building blocks and let ecosystems develop. Some will argue that now you are moving the meaning of polyglot from the programming language to the libary-level, which is true, as seen in the Scala community, the divide between better-Java (Play), a different kind of OOP (Akka) a Haskell-like ecosystem (Typelevel) and an idiomatic Haskell-like ecosystem (ZIO). So you get Java, Erlang and different flavors of Haskell in one language which is Scala :). Many say that Scala is big and messy but in fact the ecosystems spawned by the core of the language made it like that. Scala's spec is smaller than Java's. I would argue that Scala is less complex than Kotlin, but this is highly opinionated.
And even on Android, many open-source projects decide to use Java as they can have access to a wider pool of programmers (Signal, etc). C# is only decreasing in usage, the runtime is just not there, C# has always been known in the enteprise as the language that skipped leg day. It's impressive how many features they've added in a short amount of time that make sense (though some will say, even a few of the Microsoft devs, that async/await was kind of rushed), but the runtime has only received some attention in the most recent times, lagging behind Java with approximately 10 years of research. JS is just JS, hate it or love it, it is here to stay, no point in arguing about this. Put some makeup on it to make things bearable with TypeScript and that's it.
Aside from nullable types, I don't see any other feature that Java could borrow from Kotlin today to improve. Java looks up to Scala and Clojure to get ideas, there are some strong functional programming ecosystems that were bred by these languages, like Typelevel, ZIO, actor-systems like Akka, Datalog queries, contract-based systems like spec2, Stateflow testing, matcher-combinators, generally things that Clojure does differently than the evangelical notion that type-systems are the end all be all. The rest of improvements are on the JVM, like primitive objects (value types) and generic specialization.
What are the innovations brought by Allegro and Lisp Works, relative to Clojure? Just asking as I haven't heard about those, I only have experience with Clj.
Isn't this what the GraalVM [1] guys are also trying to do? Seems like today the competition is between who is more polyglot than the other, JVM, CLR or WASM.
Sad to hear that, F# is an excellent programming language. Scala has matured a lot, there is no "better-Java" anymore, that's the reality, there are three ecosystems today, Akka, Typelevel and ZIO. The competition between these is also seen in the social media and other mediums. There's also Clojure, which in my opinion is still an uncharted territory.
We are getting into nerdy arguments. React is by far a framework, as every library that you use will be highly influenced by its constructs and rendering engine, be it React Router, Redux, or others from the Hooks ecosystem. Many say it is just a library, but in practice, when trying to bring JS vanilla libraries, there's always that edge case where it conflicts with the virtual DOM.
Though it's nice to have so many choices, devs that really want actors will pick a battle-tested platform like Erlang+OTP in the 99% of cases. Because of the natue of BeamVM, which also got a JIT upgrade recently.