gshayban

What about libhydrogen's NORX construction with the Gimli permutation for AEAD and hashing? Seems like it checks a lot of boxes (from a layman's perspective.)

std::map and red-black trees are associative & sorted (by key); HAMTs are just plain associative. HAMTs have generally excellent performance: the typical implementations use 32-way branching, which allows for the top levels to be likely in cache.

The best thing about HAMTs is passing immutable ones around, which have free update costs and multi-thread safe. Clojure uses these to represent information that flows through a program. (By free update costs I mean: they are free enough to never rise to the programmer's attention. Obviously ops have costs.)

The self-rewriting interpreter model is so so interesting, and has already proven itself in things like peak performance, and cross-language. However, it can have the disadvantage of blowing up warmup time. Are there Truffle language impls that persist their specialized interpreter nodes across executions?

I'd love that too, but there is a startup time overhead with the Clojure runtime. Given the moves Google's made in recent wrt moving away from JIT for startup time reasons, this would be challenging.

Agreed that this is a big step, but what is being included in core is very distinct from Prismatic Schema. For example the way keysets vs values are handled is intentionally different from schema.

The rationale is a good read.

Many people blindly point to the docs to say "don't use groupBy, prefer reduce because it's faster..." Are there better examples that illustrate the fundamental differences between the two operations? Surely there is still a need for both operations

Exciting, inevitable news. Healthcare needs a shakeup. How does drchrono interoperate with medical systems? Other than SureScripts. Does it support regional labs or just LabCorp/Quest?

Disclaimer: I am writing a modern interface engine.

As a health care IT pro, I think you're right about the conclusions, but your reasoning is off.

Google is not pulling the plug because of a technical problem with the product (security/HIPAA), but a social issue. You can have the most beautiful API, repository, and website in the world, but it's worthless without any data. Ostensibly Google Health and Microsoft HealthVault are "personal health repositories" (PHR's), and live and die based on the content, not the platform.

Health care data has high complexity, lives in heterogenous silos (most of them obsolete), and has a huge variance in quality. Doctors don't understand it (and shouldn't have to), and patients certainly don't. It is certainly plausible for patients to expect that their health info is accessible to them online. With all their prowess, Google could have helped people expose their data. I do this every day with providers.

Google could have built more alliances with care providers (both large and small) and helped get an initial seed of users. They announced some, but not enough. Basically the only things the mainstream media covered about PHR's so far have been their birth, and now death. Nil penetration.

The health care industry needs technical help beyond Obama's stimulus, the existant products are so weak and suffer from so much technical debt...

I actually Google could have done well. They just didn't follow through. Now Dr. Chrono or Practice Fusion are far better positioned.

With OLED/IPS etc. taking over in the next few years, will this really support >8bpp or HDR?

Interesting move, Google

Agreed. The author supports going outside of Clojure for larger scale processing, e.g. Hadoop. This is sensible, but it's some leap to call concurrency a fad.

It's likely that Clojure will target some other runtime (in the future). Concurrency primitives in Clojure (var, ref, atom, agent, future, promise etc.) are practical, elegant, and focused tools. Why work around them?

When did HN become twitter? Using Clojure to sanify and convert doctor's notes from a giant Oracle instance on a EMR to a simple CouchDB instance.