The language server protocol is diametrically opposite to the way that IntelliJ works. For each language, IntelliJ builds its own internal representation (PSI) of the source code. There are a lot of language specific things, but there are also a lot of commonalities between languages.
I have no idea how you would morph (say) IntelliJ's Java support to use a LSP without basically throwing everything away and starting over.
Caveat: I never worked at Jetbrains, but I did work for two years supporting Android Studio and IntelliJ at Google, which involved a lot of work in its internals.
I'm not really arguing that the JetBrains ecosystem is equivalent, or necessarily better, than the LSP approach. It's just that this article seemed to base the existence of the LSP as some evidence that JetBrains' approaches with MPS, etc, are "corporate enterprise bloatware", which will be displaced by VS Code.
I just haven't any evidence that the LSP is creating a disruption, which is what the article is asserting.
Right now, it seems like you still have Microsoft as the main driver of the VS Code ecosystem with a few other contributors, and JetBrains really drives a lot of its ecosystem, with a few contributors. Not really seeing much of a difference, and, it doesn't seem like the products or business of JetBrains is significantly challenged by VS Code.
I mean, I haven't heard anything like Google deciding that VS Code will replace Android Studio, right? If the LSP was a true disruptor, I'd think that after a few years, that would be true. I'm sure eventually there will be more and better support for Android development in VS Code, but that probably won't displace Android Studio much.
This proposal is fundamentally different from C++ templates as they exist today. You don't just chuck a type in there and let the compiler have a go at it, SFINAE style.
The major difference is the first proposal separated interfaces from concepts, later proposals (very wisely) unified them. Only concepts could be used in type constraints.
They also switched from parenthesis () to square brackets [], thankfully.
Australian minimum wage is about 15 USD per hour, which is a wage that can sustain people if they do not spend excessively. The economy is not tanking, the same type of jobs exist. Are you claiming that the Australian standard of living is generally horrible as a result of this? That it would otherwise be better for everyone if there were no minimum wage?
My full time job was to make Bazel more efficient for about 1.5 years. The answer is: it really depends.
If you are executing 100,000 novel parallel C++ actions, then compilation for that might be I/O bound? If these actions are all cached though you would likely be CPU bound instead, as the build system works hard to discover that all the work is already done.
I haven't had many issues with non-determinism when using Bazel/Blaze? Especially when you use remote execution or sandboxing it's pretty hard to avoid being hermetic.
This is admittedly contrived, but sadly not unrealistic.
Again, I am not picking on Bazel here. Correct builds are difficult enough to get right even when everyone involved wants to keep the build correct! But, the reality is that a lot of real-world build conditions can be downright hostile. (did you know that ext4 vs xfs can change the order JARs in the same directory are loaded off the classpath? I wish I didn't!)
Yeah fair point. At Google a lot of these non-deterministic rules are either banned through "date" just not existing on remote execution machines, or through determinism tests that ensure rules behave. Maybe in real-life scenarios it's not as easy as I claim, as you suggest.
I lost my Pixel 3 recently and upgraded to a Pixel 4 (but had a Pixel 1 as well). You skipped right to the worst incarnation - no fingerprint unlock, mediocre battery life.
Why?
Face Unlock is a godsend, Pixel 3 was my first phone with fingerprint scanner and I hated every minute of using it.
It was unreliable piece of &^*&^%&^, I had to teach it my fingers every week during the cold season (which in my country is close to 7-8 months) and during summer I had to do it only once a month maybe - during winter the air gets colder fingers dry out especially if you have allergy (and I do).
And it was slow, I did unlock with pattern faster.
As for battery, I don't feel that it is poor in Pixel 4 (I ditched Pixel 3 as soon as the preorders for Pixel 4 started), but I use wireless charging all the time, I have it at work and at home, so my phone is almost always at 100%.
And now I'm puzzled, why did they bring back fingerprint scanner in Pixel 5? Apple didn't bring it back after they jumped the face unlock wagon.
Not to mention inferior CPU/CPU in Pixel 5, it looks also worse than even in Pixel 3, but the price is still premium.
So basically now we get a Nexus quality phone with Pixel price point.
I'm having the exact opposite issue -- going from the Pixel 3 to 4, Face Unlock is absolute trash. With FP I already had my finger on the reader as I was pulling my phone out of my pocket / picking it up, and it'd be unlocked and ready by the time I had it held up. Face Unlock fails every other try, adding a few seconds to the unlock, it doesn't work with masks. It's super frustrating and no amount of re-learning is fixing it. Pattern/PIN unlock isn't an option (keep in mind this is also your encryption key for full device encryption), so having to type in a passphrase even occasionally is a PITA.
Otherwise I agree, my battery life feels fine, and the upgrade to the 5 doesn't seem all that worth it.
Oh, in my case Face Unlock is reliable, sometimes to reliable, when I try to put my phone away it suddenly unlocks because my face was near :)
Oh and a trivia about Pixel 4 Soli (which is a gimmick, nothing more), I was wondering why my music suddently restarted so frequently when I was in car.
And I found out why after few days - since a week we have a lot of rain, so when I drive I have windscreenwwipers and this was somehow being picked up by soli (when my phone was mounted near windshield, but not that near) :)
Yeah I had to disable the proximity sensor for the music controls, it 1) triggered constantly when I didn't want it to, and 2) took 4-5 tries when I actually tried to use it (ie swipe to the next song with dirty hands in the kitchen). It's a neat idea, just unpolished.
I'm surprised you had as much trouble with the Finger scanner as you did. I never had to retrain my fingers in all the time I've owned it (going on 4 years now)
I live in the Canadian prairies, so cold + long winters are no stranger to me, and the fingerprint just always worked. The face unlock fails more in the winter because I'll be wearing a scarf or headcover which renders it useless. Heck, even in the summer it fails frequently because I'll have sunglasses on
You have to work extra hard and give up language niceties to reduce allocations, more so than certain other languages that are more value oriented.
You want an List<T> of objects? It's now a list of pointers to individual allocations. You want a Path class instead of just passing strings around, for type safety? One extra allocation per object.
I have no idea how you would morph (say) IntelliJ's Java support to use a LSP without basically throwing everything away and starting over.
Caveat: I never worked at Jetbrains, but I did work for two years supporting Android Studio and IntelliJ at Google, which involved a lot of work in its internals.