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?
Readit NewsWhat kind or projects are more suitable for this approach? Because my workflow, sans LLM agents, have been to rely on frameworks to provide a base abstraction for me to build upon. The hardest is to nail down the business domain, done over rounds of discussions with stakeholders. Coding is pretty breezy in comparison.
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.
Everyone is slamming you but the reality is that you could use AI models + a competent developer or security engineer to _very_ quickly shore up the entire codebase and fix every single hole -- getting it to a place where it's comparable with everything else out there. It's really not that hard (and there is already a bit of research around the defensive coding capabilities of tools like Codex and Claude Code)[1].
I have personally taken this approach with web dev, granted I'm a very senior developer. First, develop features, then ask a larger/smarter model (o3, o3-pro, gemini-2.5 pro) to analyze the entire codebase (in sections if needed) and surface every security issue, vulnerability, attack vector, etc. I then pass that back to agents to execute refactors that clean up the code. Repeat until all your keys are in the proper place, all your calls are secured, all your endpoints are locked down, all your db calls are sanitized, etc etc etc.
Now, this should have been done PRIOR to release and would have only taken a few more days (depending on app complexity and the skill of the developer).
[1]: https://arxiv.org/html/2505.15216 - "OpenAI Codex CLI: o3-high, OpenAI Codex CLI: o4-mini, and Claude Code are more capable at defense, achieving higher Patch scores of 90%, 90%, and 87.5%"
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.
dm3 commented on Positron – A next-generation data science IDE positron.posit.co/... · Posted by u/amai
It's a shame that they don't have you writing marketing copy! The docs are indeed a lot more reasonable looking (to me at least). I work for a small proprietary fund and not some Godzilla company these days so maybe I'm just not the audience, but whew, for purchasing decision makers with subject matter background, that home page would have been a back button real fast if it wasn't linked from your thoughtful comment.
I'm interested in your opinion as a user on a bit of a new conundrum for me: for as many jobs / contracts as I can remember, the data science was central enough that we were building it ourselves from like, the object store up.
But in my current role, I'm managing a whole different kind of infrastructure that pulls in very different directions and the people who need to interact with data range from full-time quants to people with very little programming experience and so I'm kinda peeking around for an all-in-one solution. Log the rows here, connect the notebook here, right this way to your comprehensive dashboards and graphs with great defaults.
Is this what I should be looking at? The code that needs to run on the data is your standard statistical and numerics Python type stuff (and if R was available it would probably get used but I don't need it): I need a dataframe of all the foo from date to date and I want to run a regression and maybe set up a little Monte Carlo thing. Hey that one is really useful, let's make it compute that every night and put it on the wall.
I think we'd pay a lot for an answer here and I really don't want to like, break out pyarrow and start setting up tables.
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.
I'm working on a new Event Sourcing database that elevates the WAL into a first class application concept like a message queue. So instead of standing up a postgresql instance and a kafka instance and a bunch of custom event sourcing plumbing, you stand up this database and publish all your application events as messages. For the database part you just define the mappings from event to table row and you get read models and snapshots for free.
The real key here is how migrations over time are handled seamlessly and effortlessly. Never again do you have to meet with half a dozen teams to see what a field does and if you still need it - you can identify all the logic affecting the field and all the history of every change on the field and create a mapping. Then deploy and the system migrated data on the fly as needed.
Still in stealth mode and private github but the launch is coming.
What would be the largest difference to Kurrent (former EventStore)?
dm3 commented on Ask HN: How have you integrated LLMs in your development workflow? · Posted by u/mjbale116
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.
dm3 commented on Case study: Algorithmic trading with Go polygon.io/blog/case-stud... · Posted by u/_zkyx
> it’s largely a big firm world now.
Largely, though I receive 1 or 2 job specs every week for start ups with the keywords 'hft' and 'low latency'. Admittedly there's going to be duplication there if you read them closely.
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. Anecdata = I worked at two firms where we did a rewrite from scratch with teams of 5-6 people and traded in the market within 3 months. I'd argue a senior dev that's been around the block a few times could achieve similar when you remove corporate politics, and bikeshedding over design.
The big firm part is paying for multiple quants at $200k++ to come up with strategies and historic market data access for trading models. Small firms are getting backing as long as the co-founders are 'ex-CxO from MegaCorp'.
> 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.
dm3 commented on GraphGPT: Extrapolating knowledge graphs from unstructured text github.com/varunshenoy/Gr... · Posted by u/jonbaer
Handling state (especially long-term) is really a struggle for LLMs right now. This issue should become easier to work with as context windows scale up in the next couple years (or months, who knows!).
People are already making progress on this, e.g. the H3 project[1].
However, the challenge has shifted to code review. I now spend the vast majority of my time reading code rather than writing it. You really need to build strong code-reading muscles. My process has become: read, scrap it, rewrite it, read again… and repeat until it’s done. This approach produces good results for me.
The issue is that not everyone has the same discipline to produce well-crafted code when using AI assistance. Many developers are satisfied once the code simply works. Since I review everything manually, I often discover issues that weren’t even mentioned. During reviews, I try to visualize the entire codebase and internalize everything to maintain a comprehensive understanding of the system’s scope.