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

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.