You must have not written much Kotlin then as no, it really won't come close still. Even if they manage to get everything planned in for 12 - which they won't - most will still wait for the next LTS anyway.
Second point is, global variables are not cleared by the garbage collector. So if you continuously add more and more global variables (which are not of future use), it will cause a memory leak.
It is if the variable is accidentally in global scope due to hoisting if it is not explicitly defined in a finer scope. Not an issue in strict mode, you'll get a reference error instead of an implied global.
This. Might not be hip and trendy, but we've been using this stack (just with React on the frontend) and it's probably the best that I've ever worked with.
Anyone who knows Java/Kotlin will have experience with Spring Boot so it's easy to find good people. The whole platform is as mature as it gets at this point and the docs/questions cover pretty much everything.
It's really easy to get started when working on smaller projects, but you can also easily scale and integrate loads of other technologies if/when you need to. You might not need a complex caching layer, monitoring, metrics etc when you're starting out, but you know you can add it in if needed.
I now realise the better test of 'var' would be to compare it to how many times it's not used. That is count the times that 'var myClass = new MyClass()' is used v 'MyClass myClass = new MyClass()'. But my regex skills aren't good enough for that and I'm not even sure if you can do it purely in a regex?
Also I imagine that 'var someNumber = 1' is used less that 'int someNumber = 1', but again, I'm not sure how to do the regex? I certainly only use 'var' when the same word is on both sides of the '=', so not in the case of int/double/decimal etc.
Back when I used to work at a large enterprise the use of 'var' was banned in our coding standards.
Using Linq was heavily frowned upon. It took quite a few years before it started to be accepted..
At one point we were also strongly encouraged to place a #region around every single method! I never understood why, and luckily that one did get dropped.
I used to work in a company with a similar policy. Never got a satisfactory answer, I think there's just lots of FUD around any language feature that looks different than what people are used to.
While it shouldn’t be banned, it should be used appropriately. We have some areas of our project that communicate with hardware where we cannot use it because of the performance hit.
Well, that on the other hand does indeed make sense, depending on the context. The only question there could be if it's a good idea to use a garbage collected language to directly[1] interact with hardware.
[1]: Well, at least directly enough for LINQ performance to be a problem.
I agree. That, and not using LINQ often enough doesn't resolve that problem per se.
Rethinking the problem (or the way you attempt to solve it) might very well improve the code much more.
One of Kevlin Henney's talks references a really neat quote by Poul Anderson on this subject:
> I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated.
Yesterday a colleague wanted to compile _and deploy_ code.
Checked it out. It .. failed to compile. Sure enough, he fixed it (and checked the change in) before deploying it (test env, thank god).
The code was generating some JSON using Linq and created JSON properties: new JsonObject(LinqExpressionHere)
The name for the property was defined as
$"SomePrefix_{x.Name}"
which he helpfully changed to
"SomePrefix_{x.Name}"
which then compiled, but crashed in the test environment because of - surprise - duplicate attributes..
> At one point we were also strongly encouraged to place a #region around every single method! I never understood why, and luckily that one did get dropped
Shudder!!
Especially since VS has plugins (or maybe it's built-in?) that will let you fold/hide individual methods, if you really want to do that!
I use it religiously now, so much quicker to program with imo as you don't need to find out the return type. Surprised it's less used than async/await though, which I think MS massively overhypes the usefulness of (and is annoyingly making a lot of classes have async behaviour by default which can result in very weird random hangs).
Although I imagine a significant number of class declarations would contain no var or async/await simply because of their nature.
What stack are you using behind the scenes to power the search? Are you storing each webpage and then doing full-text search or are you trying to pick out keywords from the resources and then match that way?
I'm not sure I wholeheartedly agree with that. The YouTube channel "REACT" could be driving some of these numbers. There's a spike in early 2016 that made me think of it - remember the whole 'REACT' Trademark craze? The Stackoverflow Trends blog post [0] from yesterday is probably more representative.
Try changing the timescale to 3 months or so for react, you get a nearly perfect pulse wave with peaks on weekdays and valleys on the weekends.
The same happens with Javascript, Java and I guess most (popular) programming languages; it might be an imperfect indicator, but one that suggests people are actively searching during their working hours (which I don't think applies to the youtube channel).
It's maybe not perfect, but definitely a lot better than 'Reactjs'. You just have to look at this topic - how many people just say React vs ReactJs. Besides Google seems to know that I'm wanting the JS framework so hopefully its filtering out some of the other unrelated 'React' stuff.
Absolutely. The line before 2014 represents the tiny baseline of people using "React" in other contexts. The entirety of the growth since then is the Javascript library.
Since your line for "Vue" shows no increase in usage after Vue.js came out, while the line for "React" does, I'm not sure this shows what you think it does.
