> “We cannot share details on the exact fix at this moment, for obvious security reasons.”
This seems a bit disingenuous. To people with a bit of understanding of cybersecurity, they are admitting that they haven't solved it; but to most of their customers, it will sound like they fixed it and are being cautious.
It sounds like their architecture enables them to solve much more interesting problems than would usually be encountered in meeting their business requirements.
All languages have redundancy; it serves as a form of forward error correction. I recall some sort of study (sorry, no link) finding that information density was (by some metric) similar across different languages. So it's not just inefficiency; it's part of the language's necessary inefficiency.
Of course, some forms of redundancy would be better than others--in cases where people aren't sure which particle to use, it probably isn't doing much good. However, language evolution is able to achieve some optimizations, and I suspect the particles people know tend to be the most important. For example, the many sushi or shellfish particles might sound particularly silly, but if you're in those industries, maybe they are helpful in maintaining important distinctions in a noisy kitchen/market, or in written records. If you're a customer you probably don't know them, and you don't need to.
Epistemic status: Wild-ass guessing from my armchair.
Interesting idea. I've just tried it with a couple of languages:
- TS with Vue: SFC are not really working (it's showing a style change as if the whole stylesheet were replaced with a mostly-identical stylesheet).
- Rust: It doesn't seem semantic at all. It's showing a lot of character-level insertions and deletions that seem worse than how git-diff or GitHub would break down the changes.
It doesn't seem ready yet for what I'd like to use it for.
I'm sorry you didn't have a good experience testing the tool. If it doesn't work / makes things worse than a standard diff, that's definitely considered a bug. It is probably something specific to your code and not a general issue. It would therefore be great if you could open an issue [1] or support ticket [2], ideally with some sample code, so we can take a look. Thanks in advance!
I can't picture how that would work. While collaborative features require that some objects are shared and synchronized, efficiency and programmer sanity rely on the fact that some objects are not. If synchronization is opt-in, how would a language integrate it any more fundamentally than a library can?
Also, CRDT's don't provide synchronization for free. They ensure that all concurrent modifications will be merged somehow. If the data being synchronized has any structure, it requires careful CRDT-aware data model design to ensure the merging is semantically reasonable (or that, in the worst case, incompatible changes produce a detectably broken state).
Think about things like browser profiles or password managers that are kind of predicated on multi device and how none of that stuff is what you’d call zero setup. Does every app that wants to do this stuff need a key base or drop box backend? Is apps joining an ad hoc k8s network mesh or relying on a preexisting central redis or postgres or something really necessary for something like sharing data structures?
There’s definitely some room for interesting work here and language level support could be cool.
Elixir interpreter clustering and otp is maybe the closest existing thing, which is awesome but only for existing erlang fans.
I don't know what kind of computer weenies you know but speaking for myself: needing to interact with someone to get exercise would add a major hurdle for me. OTOH, I'm really getting in to minmaxing myself in Garmin...
I went through the same paradigm shift with cycling. I used a cheap bike that was slow and heavy because higher efficiency wouldn't allow me to get exercise any faster. Then I got a nice road bike, and it's so much more fun to ride, so I'm riding a lot more.
Well yeah. SSDs are worse than HDDs in every way when the denominator is capacity. The headline would be the opposite if they were comparing per IOPS. The shocking conclusion: Use SSDs when you need fast random access; use rotating media for bulk storage.
This seems a bit disingenuous. To people with a bit of understanding of cybersecurity, they are admitting that they haven't solved it; but to most of their customers, it will sound like they fixed it and are being cautious.