> "more recent" does not mean "the most recent"
JDK17 is the latest LTS release.
The previous LTS release was JDK11, which is already shipped with IntelliJ.
What, exactly, are you trying to argue?
934 karma · joined November 14, 2021
JDK17 is the latest LTS release.
The previous LTS release was JDK11, which is already shipped with IntelliJ.
What, exactly, are you trying to argue?
"Compiling and working code" does not mean it's valid or acceptable code. Implementations can and often are buggy, or push implementation-defined behavior which is unacceptable. This code should be flagged appropriately. Case in point, C++11 support in GCC 4.8, and how "compiling and working code" in GCC4 broke horribly in subsequent releases.
> Search for "good code red" on their bugtracker - this is going on for years.
I fail to see how this is a good or reasonable test. A cursory search shows up only indexing problems, fixed by invalidating the cache, which bear no resemblance with language support.
Do you actually have any concrete example?
That excuse isn't credible. I mean, I asked about a libraries that handled that usecase, not a standard library. If there was demand for that use case, and that demand popped up so often that it justified the adoption of a de-facto standard, why isn't there any third-party library specialized in that usecase? I mean, putting together a library takes far less work than presenting a proposal to the C standardization committee, which is open to proposals.
So, why isn't there one? Might it be that there is actually no relevant demand for it?
Is it, though?
I mean, C is around for around half a century, and C is perhaps the primary language in the FLOSS universe.
Still, why is there no widely adopted idempotent directory tree creation library?
Would it be noticeably slower to the point it's measurably relevant, though? Or are we talking about something well within the domain of premature optimization?
I mean,if you're doing IO, how often does creating a dir end up being the performance bottleneck?
> Try running their products on a more recent JVM.
Isn't JDK17 literally two or three months old?
JDK17 was released on sep 17 2021. Meanwhile, IntelliJ 2021.2 was released on July 27 2021, and IntelliJ 2021.3 on November 30 2021.
Who in their right mind would dump a stable LTS release in favour of the latest and greatest in the middle of a point release? Specially on a production project which is expected to be rock solid, and quite possibly wouldn't be able to recover from a reputation hit caused by regressions introduced by hasty ill-advised migrations?
Doesn't this just means that IntelliJ, being an independent implementation, flags problems that a compiler frontend doesn't, and vice-versa?
That's hardly a problem, isn't it? I mean, sometimes even compilers that serve as reference implementations fail to properly support some language constructs. Case in point, look at how GCC handled C++11, and how some features were only supported a couple of years after the standard was approved.
https://gcc.gnu.org/projects/cxx-status.html
> it still can't expand macros properly and autocomplete does not work at all with more advanced libraries.
Arguably, IntelliJ (or any IDE) shouldn't expand macros at all, and "more advanced" is codeword for "uses obscure features in non-trivial ways". Those are hardly problems.
I guess stability, tooling ecosystem, and ages of user/customer support info means nothing then, and being new is reason enough to scrap all your tooling and workflow?
Developers are paid to deliver features, and test-driving the latest and greatest fad gets in the way.
VSCode shines in comparison only when all you need is a text editor to quickly open a couple of files, you don't need to do anything beyond reading code without navigating files or doing the occasional typo fix, and you don't actually need an integrated development environment.
Other than that, I struggle to come up with a scenario where, if anyone already had both installed, vscode would be the preferred solution.
I use VSCode on par with IntelliJ and Clion and I wouldn't put VSCode ahead in the performance department. In fact, until a few months ago VSCode suffered from a rather eggregious performance problem caused by the pathological way that intellisense scanned files that rendered it unusable with some projects. We're talking about full blown hangs which led to forced restarts. In fact, I find the jab quite funny because IntelliJ's main performance issues are also tied to file indexing, but here I see vscode being portrayed as behaving better?
Both IntelliJ and vscode are great at what they do, and their main usability issues stem from the same type of feature/problem. Why try to one-up either of them?
I use IntelliJ and Clion daily and I have never noticed any sort of instability.
I used to experience long indexing times until I learned that I chronically misconfigured projects and included build and autogenerated dirs in the index, which is trivially solved by excluding them and invalidating the cache. We're talking about something you do once right after you import the project.
The only foobared filesystem issue I ever stumbled upon was when I toyed with junctions pointing to a RAM drive on Windows, and Clion left the junctions out of the project view.
And that was it.
Could you please elaborate and point out real world examples that showcase any instability you implied?
This sort of personal attack is unwarranted and extremely unfair. AWS is renowned for it's byzantine and ever-changing and expanding nature, to the point it's outright practically impossible to know extremely basic things such as what are you paying for and how much you are paying.
Your comment fails to prove, or suggest, that OP's claim that AWS is too difficult to use securely by default is false. To first be in a position to refute OP's point you would need to prove, for starters, that no such vendor exists, which is absurd because they do exist, don't they?
In fact, if anything it supports OP's claim, as you've just pointed out that AWS even tries to profit from their problem of making it too difficult to use it securely by default by selling a premium service to audit credentials.
Log4j is not java. In fact, you can have log4c# or log4rust or log4fortran with precisely the same design, and consequently the same design problems and vulnerabilities.
Deploying a service to a single region is not, nor has it ever been, "customers don't know how to use AWS".
If anything, cargo culting this belief in global deployments being necessary, specially with services that have at most a regional demand, is a telltale sign a customer has no idea about what he is doing and is just mindlessly wasting money and engineering effort in something no one needs.
This blend of bad cargo cult advice sounds like a variant of microservices everywhere.
Your question reads as a strawman. It matters nothing if EC2 is also available in Mumbai or Hong Kong if by default the whole world deploys everything and anything to us-east-1, and us-east-1 alone.
https://www.reddit.com/r/aws/comments/nztxa5/why_useast1_reg...
Also quoted from CDC's FAQ:
> "In two different studies from Canada and Scotland, patients infected with the Delta variant were more likely to be hospitalized than patients infected with Alpha or the original virus that causes COVID-19."
https://www.cdc.gov/coronavirus/2019-ncov/variants/delta-var...
The thing is, us-east-1 represents the whole AWS for the majority of us.
I disagree. Stylistic choices should not block a pipeline. It's impossible to argue in favour of blocking a release just because there's a whitespace in a place where it makes some random developer frown. The robustness principle also applies here.
And no, build/critical errors are not the same as stylistic/linting errors.
I'd say that running linters in precommit hooks is the ideal use case, as linters do not belong in CICD pipelines (i.e., it would make absolutely no sense to block a release just because a whitespace didn't matched an arbitrary rule) and linting stuff before committing also eliminates iterations in code reviews to handle inane stuff like where to break a line or how many spaces come before and after a bracket.
So why would a glorified traffic signal be allowed to deny you service just because it disagrees with you?
What's the problem, exactly? I worked on projects which enforced precommit hooks running unit tests, and all the precommit and CICD test stages did was run the tests that were already in the repo.
Also, I don't understand what would be the problem of calling out-of-synch tests in precommit hooks and the CICD, given that precommit tests are used as a failsafe to not block the pipeline with broken commits.
They price their offering a tad on the expensive side. From a cursory search, easydns prices some domains at between 2x and 3x the prices offered by the likes of namecheap.
Why should content be a concern, or relevant, for a registrar?
If this was a CDN then I guess that this sort of meddling could be debatable, but DNS?
There's a world of difference between criticizing a government for imposing a lockdown at 10pm instead of 11pm or enforcing a 80% occupancy limit instead of 50%, and attacking basic public health measures like taking a vaccine based on sheer lunacy and conspiracy theories.
When I took my first jab, the local clinic handed out a flier explaining in no uncertain terms that:
a) the current batch of vaccines work by giving our immune system a workout to be able to experience a COVID infection as either totally unnoticed or at most a mild case,
b) the current batch of vaccines does not nor did ever guaranteed you won't contract and spread COVID,
c) even with all shots we still need to practice basic higiene and health precautions like wearing a mask, wash hands, and social distance.
We're talking about pre-Delta times. This has been widely known from the start.
How come antivaxxers are the only ones repeating cynical comments on how the initial batch of vaccines, which we all are lucky to have but are still at the level of being better than nothing, would be a silver bullet?
Can you please elaborate on exactly which study are you referring to and your reasoning to accuse it of being "terrible"?
Meanwhile, we've endured at least two strains which are significantly different than the original 2019 Wuhan strain, and thanks to the vaccine the mortality risk has dropped to residual levels.
The only interpretation where this assertion rings remotely true is if you follow a definition of "high level language" which boils down to "it's not assembly", which has not been the case for around half a century.
It makes absolutely no sense to claim that languages such as COBOl and C are even close at the same level of abstraction, just because C is compiled, has loops, and has a standard library.
It is a real world CVE of use-after-free on real world Rust code in production.
This demonstrates that, unlike claims from fanboys, mindlessly migrating to Rust does not magically make your code safe and immune to vulnerabilities such as use-after-free, and just like with any other language you still need to know what you are doing.
No, not really. C was always, right from the start, a kin to portable assembly. You'd be hard pressed to come up with a language from the 70s which was at the same level or lower than C. Neigher Fortran nor COBOL nor ALGOL nor Lisp nor BASIC were lower level than C. Precisely which language, other than assembly, leads you to believe that C ever was considered a high-level language?
I don't understand what leads anyone to argue otherwise.