fcurts

I doubt they (still) have such capabilities.

As always, a good start would be to provide exceptional evidence for each of your exceptional claims, instead of casually stating them as facts.

Some criticism from the scientific community:

* Not peer-reviewed

* Not published in a journal (but self-published on a personal website)

* Questionable filtering excludes high-quality studies

* Questionable weighting boosts low-quality studies

Semantic analysis is a broader term that (for languages with a type checker) includes type checking. https://cs.lmu.edu/~ray/notes/semanticanalysis/

It uses heuristics to derive semantic information from the parse tree without doing a full semantic analysis.

What's "dumb" about Anycode is its semantic features such as "go to definition", code completion, etc., not its syntax highlighting. Alas, Anycode is a separate project.

> The tokenization speed issue is already addressed by the language server protocol [...]

It's not really addressed. The semantic tokens API is intended for semantic highlighting:

> Semantic tokenization allows language servers to provide additional token information based on the language server's knowledge on how to resolve symbols in the context of a project.

Abusing the semantic tokens API for syntactic highlighting is slow, unnecessarily complex (why do I need to implement a language server just to do syntactic highlighting?), and only a partial solution (still need a TM grammar, still don't get correct code folding, etc.).

If you're concerned about the long term effects of the vaccine, you should be double concerned about the long term effects of the much more complex and much less understood virus.

> JDK 17 has most of the good features of Scala and Kotlin.

I keep reading on HN that "Kotlin isn't much better than Java X". Having used Java and Kotlin (mainly targeting JVM) full-time for 6 years, this doesn't match my experience at all.

Here are some of my favorite Kotlin improvements over Java that I leverage all the time:

* Much improved type system (nullable types, function types, declaration site variance, type aliases, contracts, better type inference, reified function type arguments)

* Local variables are final by default ("val")

* Type-level distinction between read-only and mutable collections (but compiled to Java collections under the hood, so no conversion required when interacting with Java)

* Much improved collection API

* Much improved lambdas (e.g., no pain points w/ mutating variables and checked exceptions)

* Extension functions (incredibly useful in practice)

* Much better DSL capabilities (great for UIs, generating HTML, etc.)

* Lazy properties (more generally: delegated properties)

* Coroutines (looking forward to Java's Loom; by then coroutines will have dramatically improved my async code for 5+ years)

* Great serialization support (kotlinx.serialization)

* Pragmatic macro-like capabilities via inline functions and compiler plugins (removes lots of boilerplate)

* Multiplatform support (JVM/JS/WASM/native; Graal native image is a good alternative to Kotlin/native and also works for Java)

Although I'm glad to see that Java is still improving, it will never get close to Kotlin. The most obvious reason is that many of Java's early design decisions were revised in Kotlin but are impossible or impractical to revise in Java. Also, Java carries the burden of being a platform language, whereas Kotlin can focus on being the best possible application language.

These days, I only use Java for libraries intended to be used from languages other than just Kotlin. In that case, I don't want to force Kotlin on users (stdlib dependency, debugging, etc.).

Many vaccines require three shots. A key difference is that the timespan between second and third (booster) shot is much longer than that between first and second shot.

You'll pay a hefty fine if you don't get vaccinated (and that fine will eventually be enforced).

You'll pay a hefty fine if you don't get vaccinated (and that fine will eventually be enforced).

People betting on Ivermectin instead of vaccines, masking, social distancing, and proven treatments is extremely dangerous.

None of them are official, and I bet they make major simplifications (the one you just linked to is for Java 1.4). I doubt actual language/tooling implementors benefit much from them.

> but for example Java has a formal semantics.

I don't think that's really true. The Java language specification is entirely prose. The book you linked to was written by "outsider" authors and published in 1999 (!).

I own both a MBP (2019) and an Asus Zephyrus G14 (2020). While the latter is good value for the money (I use it for gaming), chassis, screen, sound, touchpad, fingerprint sensor, and reliability are much inferior. If you want to compare the new MBP to PC laptops, at least compare apples to apples (ROG Strix, Legion 7, etc.). Otherwise you're just arguing that a high-end laptop isn't worth the money to you, which is fine but has nothing to do with Mac vs. PC.

You are comparing a high-end MacBook to a mid-range Asus. Build quality costs money.

Right. It would be more accurate to say that he is using an unproven treatment and is putting himself and others at risk by not getting vaccinated.

The insanity is to be more afraid of unknown risks of vaccination than known risks of infection and the risk of relying on unproven treatments that are harmful or ineffective.

Keeping an open mind that an unproven (for Covid) drug might eventually be proven effective is one thing; relying on an unproven drug or spreading unproven claims is another.

It's called "horse medicine" when people take Ivermectin tablets intended/dosed for horses.

Nobody says that Ivermectin definitely doesn't work. What's being said is that there isn't sufficient evidence that it does work, and that until such evidence exists, people should stick to proven measures and shouldn't spread unproven claims.

Spreading unproven claims could, for example, cause people to rely on Ivermectin instead of getting vaccinated, which would be an extremely dangerous bet with almost nothing to win and almost everything to lose.

It was running on specialized hardware in the cloud. But Stockfish and Lc0 have long since surpassed Alpha Zero.

Especially when combined with Antora (https://antora.org).

That must be why you are so misinformed about Gradle.

Fortune 100 here. Gradle is the dominant Java build tool (thousands of projects). I haven't seen a single project move back to Maven. Some projects are moving to Bazel, but that's not a walk in the park either.

Gradle has had reference-style API documentation for as long as I can think: https://docs.gradle.org/current/dsl/index.html

It already exists: https://docs.gradle.org/current/userguide/gradle_wrapper.htm...

I'm not skeptical but grateful for the vaccines.

The vaccines are paid for by health insurances and the government. Even if you don't trust these institutions, keep in mind that it's in their best economic interest to protect you from this disease (vaccines are cheaper than ICU patients), curb its spread, and allow businesses to reopen (which increases tax revenue).

The US has the most effective vaccines (Pfizer and Moderna). Every other country in the West wants them (but unfortunately there isn't enough supply). There is absolutely no reason to fear a conspiracy. The real threat is that not enough people will be vaccinated soon enough, causing more health and economic devastation. You can do your part by getting your shot and encouraging others to get theirs.

Sadly, a significant number of performance/sandboxing/debugging features is only available in EE. Also holds for JIT (at least wrt. performance).