And if you’re not using Kotlin, you’re probably using Java for Android dev.
Java is the dominant platform for web services, and some companies including FANGs even standardized their whole infrastructure around it.
Also, Java is basically the default programming language in some degrees.
In IEEE, VB is way way down the list. Do IEEE members use VB less?
TIOBE measures social media chatter. Odds are there are far more people posting noise about VB just due to the low barrier of entry.
Also if I recall correctly VB is heavily used to customize Excel spreadsheets, which contributes to a larger potential userbase than any programming language.
I dare say that there would be no better measuring stick than you doing a proof of concept with your own codebase, and extrapolate from there. There's a likelihood that the impact on build times will be sensitive to parameters such as how your implementation was/is put together, and what compiler you're using.
Keep in mind that this is for « typical IEEE members », which I am pretty sure is not a great representative sample of programmers in general.
It's still way better than counting references in YouTube and twitter, and weirdly enough TIOBE's results are in line with this poll.
If only std::unique_ptr and std::variant were introduced in C++ it would be possible to use the default destructor, copy and move constructor…
Your comment doesn't seem to be right at all. I mean, to start off by design std::unique_ptr disallows copying, and std::variant is completely wrong for the job. From thereon, it seems you're commenting on a problem you didn't understood.
The problem is not how to point to the Impl instance, but to get the pimpl-ed class to support copying, moving, etc while not leaking implementation details. This article adds another constraint to the problem, which is explore ways to mitigate the performance penalty caused by dereferencing a pointer each time it's necessary to access data members. Using std::unique_ptr with a pimpl is already well established, and covered in books like Effective Modern C++, but so is the performance penalty involved.
What's wrong with automating processes?
Is it not generating HTML on the server to be served to the client?
No, it generates the code that creates the DOM, sets the application state based on the user's setting, and updates the webapp to resume working in a consistent state.
It basically sends a frozen instance of a full blown JavaScript application.
What you’re describing is, in my opinion, an overly complicated form of dynamically rendering HTML on the backend.
That's because you're oblivious to the problem domain,and thus you're falling back to the unrelated but similar sounding things you're familiar with to fill in the void of your understanding of the actual problem.
Anyway, that’s my opinion on the matter
My point is that your opinion is a misinformed one,and really doesn't hold up to scrutiny.
I remember the first time I read about that concept and immediately thought “you mean the way we’ve been writing websites since the 90s?”
This is a poorly informed take. Your pop's dynamic html server side rendering has nothing to do with the problem of rendering DOMs generated by JavaScript running in a browser according to the client's state and leave it in a coherent state. Trying to pass off React's SSR for the same thing that was done in the 90s is like trying to pass off an Android app as the programs written for DOS.
I’m not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
And that's one of the reasons microservices are a thing.
There is a lot of doubling. Why the heck is there Dart/Flutter? Just use Javascript/TypeScript.
This blend of comment was once targeted at TypeScript. Still is.
The truth of the matter is that the purpose of tools is to help people achieve their goal. JavaScript is awfully broken, and many people have been investing their time to come up with solutions to fix it. TypeScript is one of the approaches, but Dart is another one. JavaScript doesn't go away because it's the de facto standard to run arbitrary code in a browser, and it carries decades of legacy code. Thus people try and try. TypeScript is now on its 5th major release, and there's still plenty of work to improve upon the mess that's JavaScript. No wonder corporations like Google invest their resources building alternatives.
learn Haskell, write better code
The same has been said about C but people just keep writing awful code in Python.
I don't think this is true. Java is an outstanding tech stack and was revolutionary in a lot of ways, to the point that it motivated others to shamelessly clone it and in the process create other outstanding tech stacks. See C#.
For starters, Java solved the deployment problem way before containerization was a thing. Developers could simply put together a fat JAR, drop it in a web server like Tomcat, and it would simply reload without a hiccup.
Java is also very tooling-friendly, and has a solid versioning policy.