inglor

I work with Devin daily (as well as Claude and a few others) and I can attest it's not a cheap product but it's a good one and it saves me a bunch of time.

Cool! Here is a GH repo demonstrating unbounded favicons I made 11 years ago - it crashes some browsers - wanna guess how long it took each one to fix it :D https://github.com/benjamingr/favicon-bug

We've had discussions about this sort of stuff before.

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).

Israeli here - I'll try to write this the least political as I can since I on one hand disagree strongly with the government and on the other my experience has been getting antisemstic (yes, not anti-zionist) comments whenever this gets discussed a lot (and likely downvotes but who cares I've been here 10 years and have more fake points than is important anyway).

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.

Actually Temporal does have a way to avoid determinism called rainbow deployments.

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).

Sure, basically:

- 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".

In the last two years, we built (with a team of 15, now 100) a billion dollar business on top of Temporal that performs business critical applications for fortune 500 companies. We couldn't be happier with temporal.

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.

Rust is really fun to work with and the compiler is great, just make sure the rewrite takes compile times into account since larger projects often have to be organized in a way that makes compilation reasonably fast.

Sure you can, if you have a legitimate case you can ask npm to unpublish and they handle things manually :)

We mitigate this attack with the very uninspiring "wait 24h before dep upgrades" solution which is luckily already supported in uv.

First minio and then localstack, as an open source maintainer I find that abandoning their community is bad faith. I totally get wanting to monetize but removing the free product entirely feels like such a betrayel.

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.

You are not misunderstanding anything, I use Go and Rust/TypeScript in my daily work and you are correct - it is the OP that does not understand why people use lockfiles in CI (to prevent minor updates and changes in upstream through verifying a hash signature).

You likely turned off any privacy invading feature and didn’t let the app track across apps.

The fact you are getting irrelevant ads is a good thing that indicates that is probably working.

Addy's users have been developers and Google has been very responsive in the past. I was usually able to get a hold of someone from teams I needed from Chrome DevTools and they've assisted open source projects like Node.js where Google doesn't have a stake. He also has a blog, books and often attended conferences to speak to users directly when it aligned with his role. I agree about the general Google criticism but I believe it's unjustified in this particular (admittedly rare) case.

You're right https://github.com/arXiv/arxiv-docs/blob/develop/source/abou... this needs a 2023 tag @dang

Postgres has like 300+ types but mostly stuff like decimals should work the same way it does with Postgres (with the edge cases like NaN existing in Postgres but not parquets accordingly)

Also, any planned support for more catalogs?

This is really nice though looking at the code - a lot of the postgres types are missing as well a lot of the newer parquet logical types - but this is a great start and a nice use of FDW.

They seem to disagree https://gitlab.com/fdroid/fdroiddata/-/merge_requests/27861#...

We don't flag general apps, e.g., ebook readers and browsers. But bible readers are not general apps. They are designed to read bible and there are NSFW contents in bible.

Honestly I think their argument is pretty weak, especially since like you said in this case it was a bible reading tracker.

Discussion of the merge request to mark it as nsfw https://gitlab.com/fdroid/fdroiddata/-/merge_requests/27861 https://gitlab.com/fdroid/admin/-/issues/252

Edit - found more context: https://f-droid.org/2025/09/29/google-developer-registration... https://news.ycombinator.com/item?id=45409794

I still don't get it to be honest.

Can we keep hn focused on startup and hacker culture and tech and not politics?

There are enough politicized spaces as it is

Sure, Palo Alto can acquire Cyberark and then use its sales organization to up-sell its customers on CyberArk's offering.

I've seen this at Microsoft where acquiring startups that provide capabilities and then incorporating them into Azure or Defender led to the usage of those capabilities skyrocketing and those particular acquisitions (not going to specifics because NDA) ended up being profitable.

The problem is that you come to a prestigious place like Microsoft and end up using horrible outdated software.

Credit where credit is due at my time at Excel we did improve things a lot (migration from Script# to TypeScript, migration from SourceDepot to git, shorter dev loop and better tooling etc) and a large chunk of development time was spent on developer tooling/happiness.

But it does suck to have to go to one of the old places and use sourcedepot and `osubmit` the "make a change" tool and then go over 16 popups in the "happy path" to submit your patch for review (also done in a weird windows gui review tool)

Git was quite the improvement :D

Not to disrespect Dan here, each discovery is impressive on its own but I wish we had a better way to preserve this sort of knowledge.

@dang - I hit "reply" once (I am sure of that) and I see my (identical) comment twice in the UI. Not sure what sort of logging/tracing/instrumentation you have in place - I am not delete'ing this so you have a chance to investigate but if that's not useful by all means feel free to do so.

I am not sure the wheel can be rediscovered many more times but definitely check out Kris's work from around 2010-2012 around q-connection and streaming/rpc of chunks of data. Promises themselves have roots in this and there are better formats for this.

Check our mark miller's E stuff and thesis - this stuff goes all the way back to the 80s.

I am not sure the wheel can be rediscovered many more times but definitely check out Kris's work from around 2010-2012 around q-connection and streaming/rpc of chunks of data. Promises themselves have roots in this and there are better formats for this.

Check our mark miller's E stuff and thesis - this stuff goes all the way back to the 80s.

A node worker_thread is not a thread either though :]

Unlike Node.js, Rust's Tokio allows us to spawn a new Task and run futures within it.

Nice article! For future reference in Node.js this would be `worker_threads` or if you want a higher level tokio like API something like https://piscinajs.dev/

This has been possible in Node.js for quite a while

--

Also for blocking I/O CPU bound parallelism I've found Rayon to be a pleasure. It has a few caveats but it leverages the Rust race condition checking well and it's very ergonomic.

I happily mix it with `tokio` in an application that is CPU bound but has to perform some async I/O (due to the SDKs it uses)

I worked for 4 startups that were operating for years at a loss with revenue, all are profitable today and all were acquired.

My current startup is also not profitable, we're burning money but we're already signing big contracts and I hope in a year or two we keep growing rather than become profitable (1B+ valuation in a year).

Becoming profitable, even at this point is just a matter of deciding to stop expanding - but neither us nor our investors want this given there is so much potential for growth and more revenue streams on the line.

this is ycombinator's news aggregators, I suspect you're not going to get a "don't take risks and build things" vibe - it's a startup accelerator after all :).