6,510 karma · joined December 4, 2013
Since we have backup offerings at Eon we have the excuse to build really good digital twins for our software factory and the sketching algorithms and data engineering/science experts to make the data realistic.
This was definitely more "reinventing the wheel" than reusing a projects - Era is optimized for reads and a lot of data, we stream/read everything from a datalake so state is mostly immutable and we don't have to worry about e.g. collecting personal user information or scale too much.
The hard part here is obviously the very long and expensive estate generation for companies rather than the digital twins (that are interesting and million of lines of code but less exciting to the scientist in me. If the rsearch is interesting lmk and I'll send the papers over.
We have a lot of interesting results from research partners but most of it is unfortunately still under embargo. If you're in SF you're welcome to say hi (hit me up, my email is user at gmail .com )
Iran doesn't need to conquer or hold Hormuz they just need it in missile/drone range - it's not symmetric.
As for the impact on the global economy - the entire world is letting Iran hold its gas/oil hostage because of something the US did. I'm not sure why those countries don't pressure Iran more they're not at war with them they shouldn't be embargo'd.
You have not heard of it because it primarily targets feature phones and primarily in emerging markets. If you are not in the market for a feature phone in India or building software for one it makes total sense you're blissfully unaware.
(And as the other comment mentioned, after a very successful run as a FirefoxOS fork - Android caught up )
This indicates there was actually a lot of technical merit in it and the problem was with the GTM and leadership.
The fact it's taking a while to release is still insanely fast. I'm sure they may be some bumps.
Being skeptical is good and some stuff succeeds and some doesn't - but building tools is still fun and cool, whether it's useful or widely adopted or not :)
Node has 4-6 weeks without a meaningful release (other than security stuff) pretty much every December. I think the criticism in the article is unfounded and whomever needed/wanted a release should have asked first instead of writing an "angry" blog post.
(I'm a Node.js maintainer)
As an Israeli (note the article exposing them is Israeli too) I was not aware until I saw this and I definitely intend to protest/organize about this (though to be fair I've been protesting about other stuff in the past and the climate here sucks).
Israel has several "cores" of technology. The military stuff is shameful (as well as other stuff). It's not just the NSOs (or less infamously the Wiz's/Palo Altos etc).
There are plenty of good things though - startups in the biotech/health/classic "tech" space. I'll spare you the long list of stuff like Mellanox that drives Nvidias in data centers and leave the googling of medtech to you. Lots of neutral stuff too.
If you're fine with deploying several versions of workers (and are on a reasonably new version) you can just avoid the determinism issue altogether with their k8s controller.
If you do need to have some long workflows, there is an explicit hook for "what happens to existing workflows on version upgrade".
But to be fair - none of the other orchastrators I used (like AirFlow) made me write workflows.IsNewCode/IsOldCode like temporal does. On the other hand AirFlow doesn't even have the capability to do that in the first place (or at least it didn't last I used it).
- Temporal itself is written in Go and we use Go for our backend so we expected this to be a natural fit. - Temporal makes writing activities in Go very explicit and boilerplatey - This in turn makes testing more difficult than it needs to be often - Temporal doesn't play well with Go's concurrency model at all (all stuff like goroutines needs to go through its special workflows.Go) a lot more often you have to write stuff that "appeases" temporal. - The whole workflows.ExecuteActivity(...).Get(...) is weird, having futures in a language explcitly designed to avoid that is weird. - All our compute isn't done on temporal workers anyway, its done (in another AWS account, owned by the customer) in batch compute (aws batch, lambda, ec2, whatever) so our temporal code isn't CPU heavy but is highly concurrent and needs a very high reliability guarantee. - Compare that to temporal with TypeScript, where it's simple and easy to use the same code inside or outside of temporal. Testing is trivial and the code looks like "regular code".
Determinism sucks, you do have to work hard and make everything idempotent in activities like we would for durable software anyway. The language we used was incorrect (Go) and has a lot of boilerplate compared to alternatives we later investigated (Python and TypeScript). Visibility can be slow and misses information. We needed to write our own APIs to work effectively with Agents for root-cause analysis of failures.
With all the caveats - Temporal is amazing, it feels much better than previous orchestrators I used like Prefect or Airflow. 100% would adopt again.
Luckily, I've been vibing with Devin since this started having it build a cleanbox emulator on top of real s3 tuned for my specific use case. It's a lot less general but it's much faster and easy to add the sort of assertions I need in it. It's no localstack but for my limited use case it works.
The fact you are getting irrelevant ads is a good thing that indicates that is probably working.