Mine is a dockerized Pharo that I deploy it as a microservice in Elasticbeanstalk (so it scales up/down and autoheals nicely). It's 2 smalltalk backends, plus one microservice which depends in one javascript microservice for one feature. The only reason for that nodejs microservice was firebase-auth. The NPM package was already available there so it made sense to just use that one. The rest is all good from Pharo.
And the frontend begun with react but I've switched to Svelte. I'm enjoying Svelte's clean concepts a lot!
All long haul commercial aircraft are twin engine now. The 747 is a relic and used almost exclusively for cargo now, and the A380 has ceased production. The game changer was new ultra high bypass engines like the GE90 that made the fuel savings of a twin engine configuration attainable by having sufficient thrust to replace four. Also with increased reliability, ETOPs regulations have allowed for twin engine jets to operate across practically any stretch of water. And with the decentralization of routes, the need for huge 400 passenger planes has gone as well. The future will be entirely twin jet.
Nothing so far electric has come anywhere close to the energy density of kerosene, and given how important it is for planes to be as lightweight as humanly possible, expect kerosene to remain in use for many decades to come.
Unless, of course, a revolution occurs in battery technology that makes them more energy dense than kerosene.
A tesla's battery pack is about 1000 pounds. The gasoline that would get a car to travel the same distance weighs about 100 pounds. For long haul, the fuel/battery weight would dominate engine weight, so unfortunately, I don't think planes will be using batteries for a while.
Electric will absolutely have a role in commercial air travel. It's going to revolutionize inter-city travel that is currently too far to drive comfortably, yet not quite far enough to warrant dealing with a flight by allowing people to hop on a tiny aircraft with minimal security flying out of small airfields. Think routes like SF-LA. But it's never going to replace jet fuel for long haul flights barring unimaginable breakthroughs in battery tech.
If commercial aircraft go electric (which as the other commenter pointed out, won’t be happening for a while), the number of engines would be 0. Electric motors are not the same as gas turbine engines.
I think you mean there would be no internal combustion engine. According to Oxford, an engine is "a machine with moving parts that converts power into motion". So an electric motor is still an engine.
Actually Qantas still uses QF74 (a 747B) doing non stop routes between SFO & SYD. LA to Sydney is done by A380. Other carriers use 2 engined dreamliners.
You might find this interesting - https://en.wikipedia.org/wiki/ETOPS - That's part of what's changed the hub-and-spoke model of the past since twin-engine planes can now go much further from an emergency landing.
By playing around with the ETOPS options on Great Circle Mapper you can see the 787 can fly over any part of the Pacific. Aircraft with lower ETOPS ratings would have had to fly non-direct routes to ensure they didn't stray too far from a usable airport.
Twin-engine aircraft have only one working engine if one fails, and there are rules regarding how far they can be from the nearest suitable airport in that case.
In practice that means that each type of twin-engine aircraft has a limit: Can only be that far from shore. For aircraft with more reliable engines the limit is higher, so they don't have to pick island-hopping routes when crossing oceans.
Saving in developer salaries is the only tangible one. You could argue there is less context switching for developers between languages, but I’ve never actually heard that from someone who builds the apps.
LLVM was always intended to be a compiler IR rather than a "JIT for C", and the "virtual machine" in the name was named as much to refer to the idea that it's a more direct model of an instantiation of the C abstract machine as any actual ability to perform dynamic optimization.
The big push LLVM made early on was on being able to do ahead-of-time, runtime, and idle-time optimization; the latter of which is mostly reflected in profile-guided optimization. The poor quality of its dynamic optimization [1] and the general reluctance to use profile-guided optimization means that LLVM ended up focusing hard on optimizing ahead-of-time like traditional C compilers. The fact that people got too easily confused about what LLVM actually did caused Lattner to de-acronymize it officially several years ago.
[1] A more difficult problem for C and C++ is that actually collecting enough of the code in a single IR representation is surprisingly hard, as build systems are completely and totally inane, and that's before you start trying to figure out how to glue in things like assembly files or glibc.
This is super cool, thanks for sharing!
Are there any books or other resources that you found helpful in learning and implementing Whack? I’m dabbling a little bit with PLs and would love to hear your opinion.
You might find Types and programming languages - Benjamin C. Pierce to be particularly interesting. There's a GitHub repo with a list of materials, can't seem to find it. When I do, will remember to share!
Thank you! Looks very interesting. As for working with LLVM codegen libraries, would you recommend anything beyond the official docs? I found that most books for this sort of thing are based older APIs from a few versions ago.
I haven't come across good material on the matter. If you do use C++ I do recommend you employ RAAI idiom in code generation for help with lexical scoping for your language.
If you need well-maintained mobile SDKs, Mapbox's pricing model is a lot more straightforward. If all you need is basic mapping on the web, OpenStreetMap is adequate.
"we once patched openssl to ignore client cert expiry because somebody forgot to create a process to update keys in the field and all the customer cars started falling offline because their certs had expired."
I don't get the point of this article - why single out Google specifically, when a lot of tech companies (as the article notes) hire contractors?
Furthermore, TVCs at Google can use many on-site perks, and I know a few who transitioned into Googlers. I strongly suspect this isn't common at most companies.
Google's being singled out because they, like some others, are so excessively greedy with profit these employees go without so they can hoard money they barely even pay taxes on. They have optimized to rob their employees and their cities, states and countries.
For me, trying to implement an unbeatable tic tac toe game using the minimax strategy. I promised myself I wouldn’t look up any hints online outside the Wikipedia page on minimax. It was several weeks of call stack overflows, reading through logged game states, and waking up at night to try ideas. The code for the final result now looks so simple and elegant, but it’s very deceiving.
