dm3

Monthly payment depends on Kanton as well - in the German part you can still get basic insurance for 250 USD/month.

I'm very surprised you find this workflow more efficient than just writing the code. I find constructing the mental model of the solution and how it fits into existing system and codebase to be 90% of effort, then actually writing the code is 10%. Admittedly, I don't have to write any boilerplate due to the problem domain and tech choices. Coding agents definitely help with the last 10% and also all the adjacent work - one-off scripts where I don't care about code quality.

Disadvantages don't list performance hit for proxying every operation through another indirection layer. Can this sort of interface be implemented with zero overhead in Rust?

That's why you see such a difference in time saved using LLMs for programming across the population. If you have all the domain knowledge and the problem is generic enough it's a 100x multiplier. Otherwise your experience can easily range from 0.1x to 10x.

This approach to security is backwards. It's way harder to find security issues than to never include them in the first place. This approach might work for another webapp but I highly doubt a retroactive security analysis is practical for a more involved system.

Looks like we're in a similar situation. What is your current go-to for setting up lean incremental data pipelines?

For me the core of the solution - parquet in object store at rest and arrow for IPC - haven't changed in years, but I'm tired of re-building the whole metadata layer and job dependency graphs at every new place. Of course the building blocks get smarter with time (SlateDB, DuckDB, etc.) but it's all so tiresome.

What would be the largest difference to Kurrent (former EventStore)?

I find LLMs via Aider great for:

* code translation - e.g. convert a self-contained implementation of a numerical algorithm from one language to another and generate test cases and property tests which make sure the implementations are equivalent. The goal is to avoid having to proof read the generated code.

* one-off scripts - any task where code design doesn't matter, the amount of code is limited to couple hundred lines (GPT-4o) and the result will be thrown away after use.

* API exploration - producing examples for APIs and languages I'm not fluent in. Reading reference documentation gives a better understanding, LLMs get the results out faster.

> I think it's a bit of a myth that (ignoring FPGAs) that writing a low-latency software trading system is a time/cost expensive process.

This depends a lot on the complexity of the trading system and the trading venue specifics. A system to trade single stocks or futures can be built, certified and running in 3 months. A system for options market making will take a lot longer.

Interesting that this is Clojure and it doesn't mention Hoplon/Javelin[0] as prior work. I've used Hoplon/UI[1] to implement a moderately complex web app ~6 years ago. The library is practically a prototype, pretty much dead by now. However, I found the ideas interesting.

I find the biggest benefit of using a fringe library like this is the ability to read and understand the whole implementation. It's really simple compared to something like React.

[0]: https://github.com/hoplon

[1]: https://github.com/hoplon/ui

People are already making progress on this, e.g. the H3 project[1].

[1] https://arxiv.org/abs/2212.14052

I wonder if HdrHistogram[1] could have done the job. Didn't find any references to that one in the post.

[1]: http://hdrhistogram.org/

Oh wow, do you find this sort of a career fulfilling?

Had to do the same. However, I do handstand push ups on small parallettes[0] which keeps the wrist in the similar position as doing fist push ups, but doesn't hurt my knuckles.

[0]: https://woodpower.com/products/woodpower-parallettes-push-up...

How did it work out? Very curious, as such granularity of deployable units seems absurd unless it's deployed into a single runtime...

Very good points. Agree with most of them - especially the lack of interfaces. I'm currently working on a ~30k LOC Julia codebase which was mostly written by myself. This is split into ~80 packages within a monorepo. I've never ran into problems with tests taking too long as tests for a single module take a reasonable amount of time to run.

I'd really love a PackageCompiler that would "just work" though. Julia 1.6+ made a lot of progress in pre-compile times. However, nothing beats being able to easily release a binary...

It's using a standard-year/month/day convention which might be what's required in that particular case. It's definitely not a generic solution.

I think this is completely OK. We treat our physical valuables with care. Why would we treat our digital valuables otherwise?

They were probably also sourcing their state from the events. However most of their problems come from sharing the events between the modules/services which is not a part of Event Sourcing.

> I think one major problem is that "Event Sourcing" can mean subtly different things to different people.

You're right. Here's a list of posts[1] about Event Streaming which claim to be about Event Sourcing. The discussed article is in the list.

[1]: https://github.com/oskardudycz/EventSourcing.NetCore#1319-th...

I'll answer for Switzerland which also has a strong bicycling culture. People cycle while they're physically able. I have a neighbour couple who are around 70 and cycle everywhere in the city limits.

Don't worry! I gave it as an example of a behaviour we learn as kids which is easily explained because we know about microbes and the process of teeth decay.

However, people have been cleaning teeth for thousands of years. My (naive) belief is that people associated the procedure with good health but weren't able to explain why it works. It was mostly tradition or good habit passed on through generations. Citing Wikipedia[1]:

> The Indian method of using wood for brushing was presented by the Chinese Monk Yijing (635–713 CE) when he described the rules for monks in his book:

> Every day in the morning, a monk must chew a piece of tooth wood to brush his teeth and scrape his tongue, and this must be done in the proper way. Only after one has washed one's hands and mouth may one make salutations. Otherwise both the saluter and the saluted are at fault.

[1]https://en.wikipedia.org/wiki/Tooth_brushing

I understood the "traditions" GP mentioned as cargo-culted practices tied to the decision a single person makes going through his life. Like not eating pork, brushing teeth or boiling pasta uncovered.

I agree that you can easily find abstract ideas people hold true about the world which would require serious re-education in order for the opinions to change.

How would a person follow a tradition of economic growth?

Do you mean consumerism? I don't think that one fits either as it's something people choose to do because it provides satisfaction.

Could you give some examples of traditions that an average American follows which are beneficial and would be hard to explain? I honestly couldn't come up with anything...

This is very interesting. Are there any books you'd recommend on the topic which would explain the directions pharmaceutical science is heading towards to a layman?

I understand this thread is about dumping on ES... However, I must notice in your case it was an audit log. An ES system wouldn't work at all without access to events.

This is a bit different. You are talking about a domain where the developer is usually the domain expert. You know very well what "procedurally generated terrain", "3D renderer", "database", "screen" and "framebuffer" are. Even if you don't - good and unambiguous definitions are usually just a couple internet searches away.

Now imagine you need to encode behaviours for a system where domain experts use terms and jargon you've never heard before. Even worse, users of the same system coming from different departments use the same terms to mean different things. How do you draw the boundaries there? That's what the GP finds disappointing - there is no single guide or reliable process to jump into a new domain and get the boundaries right.

I find the original tactical DDD patterns as useful as the gang-of-four OOP patterns these days. Modern languages made the latter irrelevant. Modern DDD practice emphasizes getting the strategic aspects of DDD right: language and boundaries.

Doesn't matter if your code has a type named `Aggregate` in it. Matters if you get your consistency boundaries right.

> I'm not so convinced that it's something you can get just by better communicating with "the business" either.

I don't have a good answer for this. I personally try to keep my modules small so that there's not more than a ~week worth of stuff to redo if understanding of business (or business itself) changes. I often fail too.

> We also couldnt agree on where the limits of the bounded contexts really lay. Most documentation on this issue is a mere handwave saying "you figure it out" or "it'll become clear when you do these exercises with the business" (it didnt), which is odd given how vitally important it is and how damaging it is to bound the wrong things.

This is the hardest part of software design. No wonder there are no clear cut rules on how to do it. You have to be both a domain and implementation expert to get the boundaries right on the first try.