Hacker News Reader

peter_lawreyon Which Doc Format Is Best for AI Specifications?

TL;DR: Markdown for AI working documents, AsciiDoc for curated human-reviewed specs, HTML only as a publishing target.

AI has improved over the last 6 months, with quality in the mid-range. It takes less effort to get it to produce a mediocre-to-average-quality solution. In many cases, this is good enough. For production, while we still need a rewrite, there is less effort required to prototype it first.

peter_lawreyon [dead]

A common mistake appears to be that only when women have fewer than 1 child does the population drop long term...

peter_lawreyon Testing Java Memory Management with Chronicle-Fix Using AI

This post explores using AI as a mock User, something AI is particularly suited for. - AI remembers nothing from previous tests by default. - It has a broad knowledge set - It reads most of the documentation

peter_lawreyon Tune Code Before Your Garbage Collector

In this post I look at a simple event to response latency benchmark, MarketDataSnapshot to NewOrderSingle at 50K/s for 30 minutes using JLBH to test Chronicle-FIX. The goal is to compare a system which is doing redundant work (in this case logging each message using SLF4J), compared with not logging (Chronicle-FIX records every message internally using Chronicle Queue) and how this changes the choice of Garbage Collector

peter_lawreyon Why low-latency Java still requires discipline?

Thank you for the feedback

peter_lawreyon Why low-latency Java still requires discipline?

Good feedback

peter_lawreyon Why low-latency Java still requires discipline?

This is a high-level article; for lower-level details, I also posted.

https://blog.vanillajava.blog/2026/06/testing-java-memory-ma...

https://blog.vanillajava.blog/2026/06/why-you-should-tun-cod...

Suggestions welcome, it can be hard to know what to include or not.

peter_lawreyon What do you believe is different about low-latency microservices [video]

7 Frequently Asked Questions about Low-latency Microservices in 7 minutes

peter_lawreyon Java is very fast, if you don’t create many objects

Most Iterators should be placed on the stack anyway. If they are not and you have a random access collection like ArrayList you can use an index, but this is rarely needed. If you are going to change code, perhaps Stream(s) are a better choice, these are also placed on the stack most of the time.

peter_lawreyon Java is very fast, if you don’t create many objects

A friend of mine is working at Oracle on collections that support primitives e.g. List<int>, Set<long> https://openjdk.org/jeps/8261529

peter_lawreyon Java is very fast, if you don’t create many objects

Iterators tend to be placed on the stack in hot code. In the benchmark I had to make sure these object weren't optimised away.

peter_lawreyon Java is very fast, if you don’t create many objects

Mutable objects have their own issues, which can catch people out by surprise. Having good test coverage is important.

peter_lawreyon Java is very fast, if you don’t create many objects

Reusing your objects can be confusing for other developers. You need to be careful with anything exposed via an API, however internally you can me more optimised.

peter_lawreyon Java is very fast, if you don’t create many objects

In each case the default settings were used (i.e. no options were provided). In both Java 8 (Parallel GC) and Java 11+ (G1), As the GC was a small portion of the time, changing the GC wasn't expected to make a difference anyway.

peter_lawreyon Java is very fast, if you don’t create many objects

The GC isn't involved with allocation, the expensive bit here. The GC handles the clean up. The allocations create memory pressure that can easily saturate the bus to DDR if you are not careful.

peter_lawreyon Java is very fast, if you don’t create many objects

Right, it's the total object count at runtime that matters, not how many lines of code could create an object.

peter_lawreyon Java is very fast, if you don’t create many objects

This is where using a profiler like YourKit or Flight Recorder is your friend. It will show you the objects that can't be optimised away and where code bottlenecks are. It's hard to determine this in advance for Java.

peter_lawreyon Java is very fast, if you don’t create many objects

or FPGA

peter_lawreyon Java is very fast, if you don’t create many objects

Something not generally mentioned is that Java can inline what would be virtual methods in C++, it can also remove them as behaviour changes or code is unloaded.

peter_lawreyon Java is better than C++ for high speed trading systems

In the real world projects, with the developers you can get, and the time frames you are given, not the developer you might want and any amount of time, Java can be a better choice.

peter_lawreyon Java is better than C++ for high speed trading systems

You can have a look at https://github.com/OpenHFT however it is designed to have most data off heap.

peter_lawreyon Java is better than C++ for high speed trading systems

Not if you need to be able to hire a large number of developers for an investment bank. London has around 300K developers, many in fintech. There isn't that many Rust developers with say 10 -15 years fintech development experience.

peter_lawreyon Java is better than C++ for high speed trading systems

That assumes your commercial model is based on an arms races of just being the fastest. This is not a model investment banks have used for some time.

peter_lawreyon Java is better than C++ for high speed trading systems

Or you can use Apache 2.0 open source licensed libraries which are used in low latency trading systems and pay for the level of support your organisation needs and no more.

https://github.com/OpenHFT

peter_lawreyon Java is better than C++ for high speed trading systems

If you can have any developers you want and have unlimited time, C++ is a good choice.

However, if you are a bank, which not where every developer wants to work, you have a limited budget, limited time and you have a project which isn't technically exciting (but can make a lot of money for the bank) you might find the developers you have who understand the business are more productive in Java and the resulting trading system is faster than the one they might have written in C++.

When you have some teams developing in Java and some in C++ you get to see which teams are more productive for your organisation.

peter_lawreyon Java is better than C++ for high speed trading systems

A lot of code in any language is a red flag.

peter_lawreyon Java is better than C++ for high speed trading systems

Say you have a strategy which is only going to make money for a few weeks, every day you delay means you are losing money. If you are in a Bank, correctness is always the most important and speed only helps you reduce cost/make money, but it's not the core of your business model.

peter_lawreyon Java is better than C++ for high speed trading systems

Some people use Azul Zing but we typically use OpenJDK or Oracle JDK.

peter_lawreyon Java is better than C++ for high speed trading systems

Not all your services/code needs to have the lowest latencies so you can have a team which just needs to be able to translate the business requirements and a couple of people to optimise the critical code.