rileymichael

ibm also acquired datastax (managed pulsar) this year. building on top of these specialized managed service providers is becoming increasingly risky. at this point i'd rather use one of the kneecapped cloud provider offerings if possible (azure event hubs / aws msk / etc.) than risk being extorted in a few years as the result of some acquisition. at least you can work around the limitations..

anyone have an idea on how streamnative is doing? we're considering them for managed pulsar and unfortunately nobody else is in the game

buildkite is leaps and bounds above the others. especially if you need to really tailor your workloads to the change diff (say in a monorepo), the dynamic pipeline support is superb.

really surprised there are no others though. dagger.io was in the space but the level of complexity is an order of magnitude higher

> What we want is to solve problems

speak for yourself, i want to understand everything and be elbow deep in the code

highly recommend twirp, even in current year. connectrpc seems to have stalled so there isn't a ton of languages w/server support, and because of the grpc interop on top of their own protocol it's a bit of an undertaking to roll your own.

the twirp spec however is so simple you can throw together your own code generator in an afternoon for whatever language you want.

this isn't really the case. a lot of legacy code may still be running the version it was developed against, but java 17+ has a sizable share of the ecosystem now that all of the popular libraries require it. spring for example bumped their baseline to jdk 17 in 2022.

unfortunately they've never really taken off so folks reach for explicit state machines instead. there have been a handful of options on the jvm over the years (e.g. quasar, kilim) but they're all abandoned now, the loom continuation API is internal with no hint of it becoming public, kotlin's aren't serializable and the issue is inactive (https://github.com/Kotlin/kotlinx.coroutines/issues/76), etc.. such a shame

> it means you have the skill and knowledge to ...

sure, but in the real world the overwhelming majority of people loudly proclaiming the benefits of AI don't actually have the skill or knowledge (or discipline) to do so / judge its correctness. it's peak dunning-kruger

https://dbos-project.github.io/ has all of the info

the OP wasn't clear but that's effectively what i settled on by launching workflows (within steps) via the dbos client. keeping that an implementation detail in each service though is probably better + solves the db awareness, just need to do the endpoint/rpc plumbing. thanks!

yeah i think that's a step in the right direction, but ultimately as long as the workflow executor needs to know 'who runs this step' there will always be some friction compared to other systems like temporal.

people live-dumping their comments into a text doc while i'm presenting with no ability to know _who_ left a comment (unless they manually prefix their name) really showcases that its the wrong tool.. https://i.imgur.com/vEttouw.png

glad to see the java sdk released, i've been following it for a while.

one of the rough edges i've noticed w/DBOS is for workflows that span multiple services. all of the examples are contained in a single application and thus use a single dbos 'system db' instance. if you have multiple services (as you often do in the real world) that need to participate in a workflow.. you really can't. you need to break them into multiple workflows and enqueue them in each service by creating an instance of the dbos client pointed at the other services system db. aside from the obvious overhead from fragmenting a workflow into multiple (and that you have to push to the service instead of a worker pulling the step), that means that every service needs to be aware of and have access to, every other services system db. also worth noting that sharing a single system db between services was not advised when i asked.

(docs for the above: https://docs.dbos.dev/architecture#using-dbos-in-a-distribut...)

> But it feels a bit weird to client side construct an Exception only to stuff it into a Result.error(...) instead of actually throwing it

yep, `kotlin.Result` constraining your error type to `Throwable` is a real headache as it forces you to still model your domain logic via exceptions. it also means people can still accidentally throw these exceptions. not to mention the overhead of creating stack traces per instantiation unless you disable that on every subclass.

i recommend using https://github.com/michaelbull/kotlin-result?tab=readme-ov-f... (which has a nice breakdown of all the other reasons to avoid `kotlin.Result`)

yep i mentioned that in another thread below. very excited to see it added, but it will be some time until its production ready / they implement the full feature set

oh how i wish they were in azure. azure's postgresql flex offering is horrid. for some reason the HA standby instance can't be used as a read replica, it's filled with maintenance windows / downtime-ful upgrades / etc..

absolute order, you're correct. but several systems support demultiplexing an interleaved stream by some key so that order is retained for all messages in each key space (pulsar key_shared subscriptions, azure service bus sessions, etc). you're still serializing consumption / have an exclusive consumer for each key, but with global parallelism.

here's the equivalent in parallel-consumer: https://github.com/confluentinc/parallel-consumer?tab=readme...

> you can make it work just as well as any MQ based system

you really can't. getting per-message acks, dynamically scaling competing consumers without having to repartition while retaining ordering, etc. requires a ton of hacks like client side tracking / building your own storage on top of offset metadata / etc.. and you still won't have all of the features actual message queues provide.

to make it worse, there is very little public work/discussion on this so you'll be on your own to figure out all of the quirks. the only notable example is https://github.com/confluentinc/parallel-consumer which is effectively abandoned

if you need a durable log (which it sounds like you do for if you're going with event sourcing) that has those features, i'd suggest apache pulsar. you effectively get streams with message queue semantics (per-message acks, retries, dlq, etc.) from one system. it supports many different 'subscription types', so you can use it for a bunch of different use cases. running it on your own is a bit of a beast though and there's really only one hosted provider in the game (streamnative)

note that kafka has recently started investing into 'queues' in KIP-932, but they're still a long way off from implementing all of those features.

reactive is on the decline in the java world post-loom (virtual threads) and should be nobody's first choice. writing plain old imperative code is vastly simpler to write / debug / reason about.

Brian Goetz even went as far as saying loom is going to kill reactive entirely: https://www.youtube.com/watch?v=9si7gK94gLo&t=1165s

> keep in mind that this activity is going away for most engineers (but not for all) in 1 - 2 years

sure thing. we've been '6 months' away from AI taking our jobs for years now

> To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try

to build a modern java project with gradle, you need _any_ jvm installed on your pc. you execute a task via the gradle wrapper (which is committed alongside the code) and it will download and invoke the pinned version of gradle, which then downloads the configured java toolchain (version, vendor, etc.) if it can't find it on your machine.

it just works.

to be direct, there's really nothing for you to do — it's a branding issue. if i were to link graphite to any of the devs i know that are actually interested in improving their development workflow, they would immediately close out after one look at the landing page. they have zero interest in AI and certainly won't pay for it to be shoved down their throats. graphite is now perceived as an AI company first, not a developer company.

you state that users don't 'have to use ANY of our AI features' — does that mean you have an opt-out toggle that fully hides any mention of it (e.g. in your 'AI-powered PR page')? if so, how long will that stick around? how long will your core products remain unsullied once your investors start to pressure you to push AI more? these sort of concerns around long term direction keep myself and others from adopting graphite.

shame to see a company that was originally targeting a niche (devs that care enough to pay for a tool for stacked diffs) do a complete 180 to chase the AI bag. i have to imagine the overlap between the original users and ones interested in 'graphite chat' is miniscule.

for anyone that's looking for a no-fluff stacked diff tool to replace Graphite, i've found https://abhinav.github.io/git-spice/ to be solid

> You can't do anything like Omarchy with macOS

you certainly can. Omarchy doesn't appear to be anything special, just a tiling WM (of which there are plenty of on macOS: aerospace, yabai, amethyst, etc.) with some preinstalled applications + basic dotfiles. people have been running similar setups for years on macOS

it's quite alarming reading the comments in that thread. people 'losing themselves overnight' and sharing that '4.0 made my life worthwhile'.. this is so unhealthy.

did all of the devs leave?

https://www.businessinsider.com/github-ceo-developers-embrac...

there's an official template here: https://github.com/detekt/detekt-custom-rule-template/tree/m...

and here's the diff for a 'real world' rule I implemented: https://github.com/michaelbull/kotlin-result/compare/master....

i've been writing kotlin since 1.0 (2016) and my past few jobs have been at startups using kotlin entirely on the backend. it's really enjoyable, there isn't another language with as good of a development experience due to Jetbrains controlling both sides.

coroutines are the biggest downside imo. they're great for android and other environments, but now that we've got loom on the jvm they're needlessly complex (accidental blocking calls, coloring, headaches with libraries that use thread locals, reentrant lock, etc.)

both of those examples (auto imports + refactoring) 'just work' in Jetbrains editors, and have for a decade, without any AI at all! and you have the added benefit of no hallucinations when doing a refactor across hundreds of KLOC

> It’s so good that I complete the work of weeks and months within days

and yet you're pulling 14 hour workdays..