HN user
Bought the app, this is great. Can I make a feature request? I’d love for it to include a sequence of “levels” or existing equations to try and solve in order of increasing difficulty, and maybe a way to generate a random interesting one. Would love to use this to teach others with a mechanism for regular practice.
Plus modern interconnects like CXL are also layers on top of PCIe, and USB4 supports PCIe tunnelling. PCIe is a big collection of specifications, the physical/link/transaction layers can be mixed and matched and evolved separately.
I don't see it disappearing, at most we'll get PCIe 6/7/etc.
I’m sure this work is very impressive, but these QPS numbers don’t seem particularly high to me, at least compared to existing horizontally scalable service patterns. Why is it hard for the kube control plane to hit these numbers?
For instance, postgres can hit this sort of QPS easily, afaik. It’s not distributed, but I’m sure Vitess could do something similar. The query patterns don’t seem particularly complex either.
Not trying to be reductive - I’m sure there’s some complexity here I’m missing!
Unfortunately I don’t have any recommendations to give, my experience starts and stops at application development. Though I would love to spend some time in a datacenter!
Potentially have a look at Infiniband and Clos/fat tree networks?
My more generic recommendation would be to explore semantic scholar for impactful/cited papers, look for some meta analyses, and just dig through multiple layers of references till you hit the fundamentals (typically things published in the 80s for a lot of CS topics).
Once you're past the fundamentals, if find yourself interested in high-performance networking, I recommend looking into userspace networking and NIC device drivers. The Intel 82599ES has a freely available (and readable!) data sheet, DPDK has a great book, fd.io has published absolutely insane benchmarks, ixy [1] has a wonderful paper and repo. It's a great way to go beyond the basics of networking and CPU performance. It's even more approachable today with XDP – you don't need to write device-specific code.
Do you have any career advice for someone deeply interested in breaking into high performance GPU programming? I find resources like these, and projects like OpenAIs Triton compiler or MIMD-on-GPU so incredibly interesting.
But I have no idea who employs those skills! Beyond scientific HPC groups or ML research teams anyway - I doubt they’d accept someone without a PhD.
My current gameplan is getting through “Professional CUDA C programming” and various computer architecture textbooks, and seeing if that’s enough.
I disagree, “req/res body cookies that’s it” is not the underlying system. It’s an abstraction over the TCP/IP and HTTP stack.
What happens when you need to disable nagles, avoid copies of the request body, use websockets, gRPC, etc? You’d need to pray that the framework gives you an escape hatch.
Is there a way for me to subscribe to updates on this? I’d love that!
Can’t you just swipe down from the top of the screen and press the Bluetooth icon, or am I missing something?
You should share the design principles!
What translation is this? I love the writing!
They sell an API product, of which documentation is an absolutely core, user-facing part of their product. It doesn’t make sense not to own something that differentiates your products value proposition.
Is that not accurate? There’s only so many hours in the day, and I have to split them between competing priorities.
If I don’t have time for something, I don’t have the remaining hours to spend on it, given the time I’ll spend doing other things.
Having your caching set up I correctly is verrryyy easy to do. There’s lots of things you can miss, and don’t realise until a whole lot of traffic hits you
I’m hoping by more projects adopting Bazel, we get more powerful libraries, and it becomes trivial to use.
I’m using Bazel to build my rust project (Using the rules_rust rules) and it’a become quite a pain to use in concert with docker.
This is not a complaint about Bazel specifically, its fantastic, and easily my favourite build system bar none.
However it cannot cross compile Rust. This means if I’m developing on my MacBook, and I want to compile a Rust binary and put it in an Ubuntu docker container, I can’t do it on my host machine. I need to copy the source into the container and build it there, using multistage builds.
But this is -extremely slow- because it cannot take advantage of Rusts build caching. I’m talking 10-15 minutes for my small Rust project.
Has anyone run into this? How do you work around it?
I’ve considered running a Bazel remote execution server on a local Ubuntu VM, but this feels like so much extra complexity just to use Rust, Bazel and containers.
Assumptions about the users, not assumptions made by the users.
I tailor all my resumes to the companies I want to work at. Each have different role descriptions and things they value.
If I want to commit a few hours of my life working there, I find it valuable to do some legwork beforehand.
Off-topic, but what streams! Would love to follow along with some interesting Rust ones.
They’re not doing anything wrong, but working with generics, traits and async code is very much against the grain of the 2018/2021 editions of Rust.
The async story hasn’t finished, and is definitely the area that needs most improvement in terms of developer experience. There are a number of gated features and RFCs that propose solutions to these problems (e.g. GATs), but they haven’t been moved into the core language yet.
That doesn’t mean Rust is inherently bad or difficult, only that we’re working with an early version. Rust is young! We didn’t have futures until 2019, iirc.
Lots of core Rust concepts (lifetimes, ownership, references) need to be rethought for how they fit into asynchronous programming, and how to make everything compose well together.
I don’t think it’s true that any given “basic” design pattern should should necessarily be simple in every language.
Certain things are short and elegant in Rust. Certain things are short and elegant in Python. Each optimises for different things.
I also don’t believe it places “extraordinary complexity” on the shoulders of the programmer; this complexity is often a sign you’re doing something wrong, or working against the grain of what Rust is optimised for.
I’d assume 2.5M refers to the number of containers, not physical machines. And that since containers are virtualised and largely a developer convenience, there’s not a big reason to try keeping that number low.
I don’t believe it’s particularly new. Microsoft has thoroughly embraced this in the Teams API, so I wouldn’t expect it to go away soon.
How does this apply to not needing queues? I suppose you can rely on your language runtime to juggle the various jobs and concurrent threads (analogous to workers), but then you lose a lot of the benefits of having an explicit MQ system. If your system goes down, for example, you’ll lose all the in-progress work.
Actually, is that the point I was missing? That the benefits of an explicit MQ system are not always required, so it can be simpler to just rely on the async primitives of your language?
Aren’t queues simply a requirement to do asynchronous processing? And MQs are a way to do it while keeping your application stateless, and with features to make it easier to recover from failure (e.g. persistence, DLQs).
I love discovering simpler solutions to problems! Could you explain this a bit more - how could you design things that seemingly need a queue, without a queue?
Is this true? I’ve always felt “locked out” of any serious academic career as someone who, in their undergrad, focused on getting into industry rather than on research experience.
What does that path look like?
Could IRC bots do video conferencing and live screen sharing?
It’d be very cool if they could!
With webview based applications becoming more and more common, maybe HTML is all we’ll ever need.
I think that is the wrong question to ask. Web apps are more productive, almost by default, because you don’t need to rewrite the application for each distribution target.
I can build a web application and deploy it on the web, on Windows, on Mac OSX, on iOS, on Android, on Linux, immediately. With minimal extra effort, assuming I know what I’m doing.
Correct me if I’m wrong (it’s possible), but I don’t think that’s at all possible with native libraries, or even cross-platform frameworks like Qt.
It also means companies don’t have to hire multiple product teams. They can hire one team.
So even if native development is 10-20% more productive (I’d disagree, but for arguments sake), it’d still fall short.
Webtech might score low on the CPU efficiency scale, but it scores very high when it comes product timelines, headcount, payroll and (arguably) ease-of-hiring.
This is why I think webtech almost always makes more business sense. At least for your typical SaaS product.
This is why I’m excited for WASM. We might finally have the tooling for truly cross-platform development without sacrificing efficiency/low level control.
I really don’t think this is such a bad thing. It makes it much easier to develop software and has helped result in the explosion of awesome digital products that we see today.
I do have my fingers crossed that Rust+WASM+WGPU will bring about some more efficient products, though.
But I don’t think non-technical users value memory efficiency as much as we like to think sometimes.