I found that out in the context of imperative-style language development. I wanted the IR to be as commands with structs and it took some effort to steer it away from Lisp.
58 karma · joined January 6, 2013
It could be a case of AI being differently intelligent, though. Here are some of the patterns I encountered:
Repetition: AI never breaks a sweat repeating the same thing over and over. This is fine with code because there are more tools to catch and eliminate it and even so, it matters less as long as the code works.
Jumbled statement order: AI has a glossary of facts and it is not very careful about the order of… shall I say, revelation… of facts. We have a certain way of building understanding in deductive steps. AI writing disregards that. (Aside: I actually started using an Answer Set Programming tool to keep the LLM on track.)
Mixing attribution and control: we have a sense of what things are passive, what are active, what controls and what follows or reacts in a situation. AI mixes it up badly and suddenly you have stuff like “the lead shade is red but it has nothing to show for its presence around orange” instead of saying that the red accent doesn’t contrast well against orange.
Post-training flavours: I think this is clear from how Claude models write vs. other trainers’. Even accounting for intelligence differences, Claude has an empirically worse writing style.
Having forward progression with staged and committed states (or any other intermediate states required) is more tractable.
The “will lead astray” part is concerning. If you already have a clear idea in mind, you probably don’t need to have the debate with coworkers.
If you are having a debate with coworkers or AI, you would rather that they be knowledgeable enough to not lead you astray.
In cases where I don’t have a clear understanding of some area, yet I don’t have someone knowledgeable to talk to, I have found myself having to discuss the same point with multiple LLMs from multiple angles to tease out the probable right way.
In summary: obviate experts, receive correct guidance, save time —- pick any two.
Also, despite GC there’s a sizeable amount of systems programming already done in Go and proven in production.
Given how much importance is being deservedly given to memory safety, Go should be a top candidate as a memory safe language that is also easier to be productive with.
Of course, I could just _tell_ it to rewrite, but that’s different.
Long winded way to say that it’s now easier to just create something to fit your needs… like 3D printing components.
Claude Code already has a built-in task tracker for short/mid term tracking.
Unfortunately, it’s not updated to include QUIC and HTTP/3 so I had to piece together the info from various sources.
HTTP/1.0 was built primarily as a textual request-response protocol over the very suitable TCP protocol which guaranteed reliable byte stream semantics. The usual pattern was to use a TCP connection to exchange a request and response pair.
As websites grew more complex, a web page was no longer just one document but a collection of resources stitched together into a main document. Many of these resources came from the same source, so HTTP/1.1 came along with one main optimisation — the ability to reuse a connection for multiple resources using Keep Alive semantics.
This was important because TCP connections and TLS (nee SSL) took many round-trips to get established and transmitting at optimal speed. Latency is one thing that cannot be optimised by adding more hardware because it’s a function of physical distance and network topology.
HTTP/2 came along as a way to improve performance for dynamic applications that were relying more and more on continuous bi-directional data exchange and not just one-and-done resource downloads. Two of its biggest advancements were faster (fewer round-trips) TLS negotiation and the concept of multiple streams over the same TCP connection.
HTTP/2 fixed pretty much everything that could be fixed with HTTP performance and semantics for contemporary connected applications but it was still a protocol that worked over TCP. TCP is really good when you have a generally stable physical network (think wired connections) but it performs really badly with frequent interruptions (think Wi-Fi with handoffs and mobile networks).
Besides the issues with connection reestablishment, there was also the challenge of “head of the line blocking” — since TCP has no awareness of multiplexed HTTP/2 streams, it blocks everything if a packet is dropped, instead of blocking only the stream to which the packet belonged. This renders HTTP/2 multiplexing a lot less effective.
In parallel with HTTP/2, work was also being done to optimise the network connection experience for devices on mobile and wireless networks. The outcome was QUIC — another L4 protocol over UDP (which itself is barebones enough to be nicknamed “the null protocol”). Unlike TCP, UDP just tosses data packets between endpoints without much consideration of their fate or the connection state.
QUIC’s main innovation is to integrate encryption into the transport layer and elevate connection semantics to the application space, and allow for the connection state to live at the endpoints rather than in the transport components. This allows retaining context as devices migrate between access points and cellular towers.
So HTTP/3? Well, one way to think about it is that it is HTTP/2 semantics over QUIC transport. So you get excellent latency characteristics over frequently interrupted networks and you get true stream multiplexing semantics because QUIC doesn’t try to enforce delivery order or any such thing.
Is HTTP/3 the default option going forward? Maybe not until we get the level of support that TCP enjoys at the hardware level. Currently, managing connection state in application software means that over controlled environments (like E-W communications within a data centre), HTTP/3 may not have as good a throughput as HTTP/2.
I had read Andrew Tanenbaum’s book on networking when I was in college. Great book, fun to read but as a developer, I could never really apply the knowledge from that book in my work and it’s been a gap that I only managed to bridge through unsystematic learning so far.
Unfortunately, casually throwing around terms like prediction, reasoning, hallucination, etc. only serve to confuse because their notions in daily language are not the same as in the context of AI output.
Doesn't seem like a situation precipitated by something in Go. I've found cross-compilation to be very easy and effective. Having your build setup on the deployment servers would negate the advantage of the dependency free single-binary deployment.