> Apps you download from the store are compiled to bytecode that is then compiled to native code at installation time.
This is only true in Android 5 and 6.
Starting with Android 7, due to amount of time it took to compile in tiny ARM CPUs, limited optimisation levels, and Java's dynamic abilities, there was a full reboot of this process.
Which is an Assembly hand written interpreter, intended to allow for quick startup in case the JIT cache is empty, a JIT compiler, and an AOT compiler that only compiles the hot paths that the JIT already had a look into, and during idle times while charging so that it can have the CPU all for itself when doing optimisations.
Additionally several other measures were taken to optmise this process, via Play Store Services, devices can share PGO data gathered by the JIT so that each device doesn't have to start from scratch, thus the interpreter step can be skipped when metadata is available. To further improve this process, developers can do training runs, and ship the metadata themselves on the APKs.
Also during the compilation to native code, depending on code access patterns, the executable code gets remapped so that there is an optimal alignment for the instruction cache when reading from the executable code cache.
Google certainly offers clang as part of the NDK, and game development is one of the few officially supported scenarios to run native code on Android.
You need Objective-C, Swift, and Metal is a C++14 dialect with extensions.
You may refer to the C++ bindings, which still not obviate the need for the C++14 dialect in the shaders, and it only works, because there is a shim to call the Objective-C runtime from C++.
Likewise there are DirectX COM interfaces that are really only usable from Visual C++ COM extensions, and the HLSL semantics depend very much on which compiler is being used, hence why there is finally a language reboot going on.
At least BASIC was originally designed as compiled language, only the 8 bit home computers made interpreter versions more widely known due to their hardware limitations.
Starting with version 5, Visual Basic "crap" was using the same compiler backend as Visual C++.
That is a side effect from Python adoption at scale in the form of CPython, even though there is PyPy crying on its little corner for lack of attention.
The slowness of Python based software, and the continuous rewrite of Python into C, C++, and nowadays Rust.
I know of very few cases of this. For the most part I find the "slow" to be in the network/IO things. Unless one is doing heavy matrix math or something similar in pure Python, which I'd seriously question.
This sounds like my experience switching from conda to uv. The speed seriously blew my mind, and sometimes still does today. But then I think about the tradeoffs: I've encountered issues with uv-packaged Python because they've optimized the heck out of it, like a few months ago I was working with tkinter and things were failing hard on ways I couldn't understand, then I switched to conda for those projects and... things just worked. Also package management isn't a thing that's regularly run, so while it's blazingly fast, it really doesn't have much effect on overall dev time. If it was just about speed, I would've stuck with conda, but uv offers a lot of actual valuable features and simplified some of my flows, so it's now my main Python project manager and conda kept as fallback.
It's essentially the same re regular desktop software. The performance for a particular bit may be nice, but it really doesn't impact the overall experience as one can only move at a certain speed as a user, and there are still those other bottlenecks. Like with my current project that's using Flet, the UI is extremely snappy and a joy in every way, but the networking bit (using iroh, which is implemented in Rust) has been a constant pain that I have to keep returning to. The speed of Rust is doing 0 to help anything, and I feel like it would've been less painful if iroh was actually implemented in Python as then I could dig into the source to see what's up and tweak to fit my circumstances, instead of dealing with essentially an immutable black box.
The UNIX philosophy was so great that the moment UNIX went commercial, there wasn't a single vendor that has left the man pages,OS APIs, X Windows or alternatives for their UNIX derivatives, as the mythical UNIX philosophy described in a book paragraph, stuck in UNIX Research V7.
Unless they are used for multi-processing in classical UNIX fashion, or proper microkernels, most applications will hardly take advantage of them.
Managed languages runtimes are probably the ones that would be better equipped to take advantage of them, for distributed JIT, GC and asynchronous code.
The Connection Machine style with StarLisp.
Very few devs can write optimal multi-threaded code that explores the single digit count of cores on their laptops or phones already.
Ya functional programming is key, as it's equivalent to a spreadsheet or digital circuit. In other words, it removes the element of time and often dynamic state, which imperative programming generally fails to do.
IMHO most concurrency problems don't actually need async behavior, they need higher-order methods and models which behave deterministically by encapsulating async behavior internally.
Another maturing solution is to use SAT solvers to prove that all exceptional behavior and failure modes are handled. I'm hopeful that AI will help with that and allow us to exercise programs fully, rather than rely on unit tests and fuzzing.
Personally I think that the UNIX model of orchestrating small async programs that do one thing well is the only proven mainstream solution. Erlang and Go come really close, but unfortunately we need a hybrid of the two, which doesn't currently exist. The pattern for that is functional core, imperative shell. Which mimics the real world where business logic can be formerly proven correct or constrained by types and categories, then we wire up programs cookie cutter style. That avoids the use of monads (promises/futures in imperative languages), which are the main footguns. The closest language that does that is ClojureScript, whose runtime is analogous to suspending and resuming a coroutine or green thread that makes Lisp calls (although that's a poor fit and I'm sure I'm wrong about it).
But you're right that we don't currently have a language that can recruit multicore CPUs. I used MATLAB/GNU Octave in the past, but think that Julia probably has a brighter future since it can already run on GPU mostly unmodified. I would not try to do it with a mainstream language like C# or Python, or even PHP for that matter. Although some of PHP's multiprocessing metaphors are pretty solid, since they intentionally use processes instead of threads like in Ruby. There the problem is latency introduced by poor process models used by Microsoft and Apple, not something fundamental with spawning processes. Real-time Linux attempts to unify the kernel under one process model to provide deterministic timing, which is hard enough for regular Linux and probably out of reach of the big OS companies, because money can't buy everything.
That is my pet peeve against TLA+ advocacy, the disassociation between a theoretical proof of a specific algorithm, data structures, and the actual implementation in production.
I rather push for tooling that allows code generation based on the formal proofs like FStart or Dafny, or is integrated with specific programming languages like SPARK, Frama-C or this Verus.
You can write everything in Lean and generate an implementation. Given that LLMs can now generate Lean proofs, this does not seem to be prohibitively expensive anymore. The real issue with distributed algorithms is that they are hard to reason about, and reasoning about them at the code level does not make the verification problem easier, it makes it harder.
I'm working on a ISO-29148 aligned spec standard with formal modelling baked in. It's meant to sit above the code with types, contracts, proofs and other objects that lower mechanically into code and/or are deterministically verified.
I'm targeting Rust primarily but my goal is that any language could sit under it via an integration layer.
The first public version of the formal specification standard isn't available yet. Pushing hard to get it out soon! But Quoin ships with an earlier version of the spec standard. It features derived property tests, which was the POC for fully adopting a formal-spec-to-derived-formal-verification ecosystem.
And yes it did had emulators for Windows 16, and DOS
https://en.wikipedia.org/wiki/Virtual_DOS_machine
https://en.wikipedia.org/wiki/Windows_on_Windows
reply