> This saved time I would otherwise have spent debating with coworkers. But it’s not always right and it is easily led astray (and will lead astray), so you need a clear idea in mind, a firm hand, and good judgment.
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.
`EDITOR=mg` is a great find. I never knew of it before! One caveat I found is that it doesn’t support unicode (at least not in the default mac installation).
You can preallocate your data structures and control memory layout in Go.
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.
I’m not sure. I keep asking the LLMs whether I should rewrite project X in language Y and it just asks back, “what’s your problem?” And most of the times it shoots my problems down showing exactly why rewriting won’t fix that particular problem. Heck, it even quoted Joel Spolsky once!
Of course, I could just _tell_ it to rewrite, but that’s different.
I just asked Claude to create a memory system for itself for one of my projects. It created a file based utility written in Rust on its own. I offered it to use beads but it declined as beads is a task tracker and what we needed was a spec tracker.
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.
It’s a worthwhile answer if it can be proven correct because it means that we’ve found a way to create intelligence, even if that way is not very efficient. It’s still one step better than not knowing how to do so.
Glad you found it helpful! Most of it is distilled from High Performance Browser Networking (https://hpbn.co/). It’s a very well organised, easy to follow book. Highly recommended!
Unfortunately, it’s not updated to include QUIC and HTTP/3 so I had to piece together the info from various sources.
Here’s a conceptual background about how and why HTTP/3 came to be (recollected from memory):
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’d been looking for networking books meant for software developers for a while and just ordered “High Performance Browser Networking” and “Kubernetes Networking” a few hours ago. If only this was posted yesterday!
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.
On-shore manufacturing requires an on-shore workforce. I’m wondering how this will sit with any company that wants to invest in on-shore manufacturing. I mean, what’s the big picture here?
I was considering a purchase, seeing as it is such a wealth of information and history. However, there are expletives in chapter titles! That’s a no-no for a collection-worthy book.
Subversion and lies are human behaviours projected on to erroneous AI output. The AI just produces errors without intention to lie or subvert.
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.
You're right about that. However, I find it easier to understand Go's concurrency model by starting with dataflow and then adding one more requisite (channels), than starting with classic fork-and-join and then making a bigger jump to message passing concurrency.
> Funny thing about Go is that as a compiled language, folks often need to send the source-code to the deployment servers to compile on them too.
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.