vdombr

Yeah, they won't have a chance to rewrite cp and mv in Rust.

Do people need this "more features in a shorter time"? I can say that, for me, I stopped reading changelogs because some software that I use started to update too often. If there are any new features that were added, I probably won't notice them.

And I remember times when people got angry at companies for "improving their UX" and breaking the daily routines of their users.

Well, yes. Now you can create an MVP in 2-3 days, you know :D

I did some projects, but there are some things that I don't like. For example, when I wrote a program for my old ThinkPad, I didn't only create a useful utility for myself, but also learned and practiced Qt/C++. Now, I don't learn anything new, nor do I practice my skills when I "create" something. Maybe, the things I'm learning are how to prompt LLMs, add necessary skill files, and so on.

It's been almost half a year since we got powerful enough models, and I'm wondering, where are all those great things that were created with them? Maybe it's just me, but nothing has changed in my life so far. No improvements, but definitely, I need to be more careful when reading, listening, watching, and using things, as bad quality slowly creeps everywhere.

And I'm personally not happy with that. To manually test something, we have QA, to shape business requirements, we have a business analyst and a product owner. Now a developer needs to be a 3-in-1 person?

It was mostly HTTP/JSON tests with some sort of validation, basic auth and logging. I think Ruby is used the most for this. I see many companies switching from Ruby to Go or FastAPI for this basic web services stuff, and I have no idea why. Ruby needs to improve its memory management, but the speed is pretty good.

Thanks! That was exactly my point. The ruby community has made many performance improvements since 2.0, including JIT compilation, fibers and ractors.

It’s more like goroutines or other lightweight concurrency mechanisms. If threads are OS-level concurrency primitives, fibers are scheduled within Ruby itself, which makes them much more efficient than threads.

In fact, I got the following results in HTTP benchmark tests:

Go:

* Latency under stable load: p95 0.25–5.32 ms, p99 2.20–9.92 ms * Memory: 23–31 MB RSS across HTTP scenarios

Ruby:

* Latency under stable load: p95 1.03–6.45 ms, p99 2.32–8.30 ms * Memory: 84–295 MB RSS, depending on the scenario

Fibers can also handle WebSockets better because WebSocket workloads involve more I/O waiting.

A typical Falcon setup uses N workers, one thread per worker, and many fibers. Since the fibers are cooperatively scheduled within a single thread, this avoids much of the context-switching overhead associated with OS threads. Multiple workers can still run in parallel across CPU cores.