JetBrains’ Lincheck[0] is a good library in the Kotlin/Java world for this stuff. I especially like that it’s declarative, and also the way it outputs the linearizability results.
I’d put any one of extension methods, value and data classes, immutable variables, structured concurrency, and top-level functions ahead of scope functions for reasons to switch to Kotlin. But hey, if you’re switching, we’re already friends :) .
> 2) choose paths now that keep options open later.
Not sure about this one. I’ve seen teams that are too noncommittal in their architecture decisions because “what if [insert unlikely thing that’d not actually be the end of the world] changes?” Then the project ends up only using surface level features of their chosen tooling because people want to keep too many options open and are afraid to commit to something where it matters.
I think the Jetbrains team are dropping the ball when it comes to Kotlin on the JVM. They seem to be focusing their energy on KMP, and I’m not sure they have the capacity to deal with all the platforms they want to target (Kotlin/JS, Kotlin/Native, Kotlin/JVM, KMP, Jetpack Compose (?) etc). That being said, I’d strongly encourage others to try Kotlin as a Java alternative for server-side applications (Spring Boot integration is really nice, for instance). It’s such a delight to use! And it’s still my favorite language. Some features I especially like:
- context receivers (think of them as implicit parameters that are checked at compile-time)
- null safety. This is a BIG one, especially if you’re coming from Java.
- structured concurrency. Java still doesn’t have this. Note that SC is different from what was introduced in Project Loom.
- immutable variables, data classes, value classes etc.
> Hogging instances might pay, if this stops competitors getting good hosts. This would eat into PnL and is also wasteful on energy.
Aren’t reserved instances cheaper than spot?
> Bad players could do a ping test to many thousands of EC2 instances, find those which are also at very low latency to their good boxes (assuming these are competitors), and DDoS them during trading hours to hammer the hypervisor’s NIC. This would result in critical overhead occurring for competitors sending orders out.
Leaving out the logistics of how someone could do this (why are your instances reachable from the internet?), wouldn’t you have a good case with your exchange to get them kicked out?
I had a professor who hated Jared Diamond for being reductionist, and I’ve been skeptical of him ever since. However, I see the immense appeal of his theories (and the one linked here) because they’re so simple to understand. They make for good History Channel documentaries, and tidbits you can repeat at a cocktail party to make yourself sound smart.
1. It happened during the Treasury auction, and if the timing was intentional, a case could be made about it being a national security issue. The hackers disrupted the largest, and possibly most important, auction in the financial world.
2. The hackers may have unintentionally provoked an entity you definitely don’t want on your bad side: the People’s Liberation Army’s cyber arm.
3. I wonder if ICBC used a specialized courier service to send the USB stick, or if such a thing even exists. Or did they just use any old messenger service in Manhattan? If the latter, it’s funny to think that there was somebody biking across the city carrying billions of dollars worth of liquidity and settlement data and he/she would’ve been none the wiser.