This is largely FUD, written with the intent of sounding professional and with expertise, but in practice there are many tell-tale signs that the author doesn't really know what they're talking about.
> the biggest drawback of async is the fragmentation of the ecosystem
95% of the ecosystem uses tokio nowadays. async-std has been dead for a long while. There are other runtimes for specialist purposes, but pretty much all async libraries will work with tokio, and you should just use tokio. It's fine. It's well maintained. It's not going anywhere. It's hit a stable 1.0. There is basically no reason to not use it.
> So, if you think that you didn't have enough work solving the problems of your users, you now also need to update your toolchains, Dockerfiles, dependencies and more, every 6 weeks.
This is complete rubbish. Rust's edition system means that Rust code written back in 2015 will (largely, bar some minor soundness issues that have been found since then) still compile. You're under no compulsion to update anything, and cargo's lockfiles ensure that your builds don't suddenly break. If you want to upgrade, do so! But it's exceedingly rare that code ever needs to change when doing so. It's about a painless an upgrade experience as it's possible to have in this industry.
> Rust is betting everything on a powerful language backed by advanced theory, but it forgot that developers need more than a language to build solutions to businesses' problems.
No, it didn't. Rust's standard library is not designed to give you everything you need to build a large program. Instead, it's designed to specify the interfaces that other libraries in the ecosystem require to talk to one-another, and it's been remarkably successful at that. Take a scroll through [the docs](https://doc.rust-lang.org/std/) and you'll see that: it's almost all traits, fundamental types, and other shared abstractions that are used by the rest of the ecosystem. Any non-trivial program is supposed to end up with third-party dependencies: the critical thing is that those dependencies can talk to one-another painlessly, and that promise is largely delivered upon: everybody uses the same interface for `Future`, `Iterator`, `From/`Into`, `Allocator`, `Clone`, `Eq`/`Cmp`/`Hash`/`Ord`, `Error`, `Debug`/`Display`/`FromStr`/`ToString`, `Read`/`Write`, `Sync`/`Send`. That's the sign of a remarkably successful and well-engineered set of abstractions.
I've been writing Rust backend services for years and the 5% has never mattered, I don't even bother checking if things advertise tokio support. Which ones in particular caused you trouble?
You're talking about a different thing to OP. OP is talking about the OSI and the specific incarnation of 'open-source' that came with it, you are talking about the more general social pattern of open collaboration.
It is worth noting that although the result here is visually impressive for erosion aesthetics, it is also not practical for the generation of physically-plausible lakes and rivers. Proper hydrological simulation is required because non-local information is crucial, something which this shader technique doesn't attempt to simulate. Without that, you're likely to end up with rivers flow uphill and lakes that don't properly overflow from valley passes and suchlike.
Source: I'm a core dev for Veloren, which uses a very detailed hydrological simulation for its world generation. More info here: https://veloren.net/blog/devblog-43/
Thanks, I'm glad to hear it :) Unfortunately I've not had much time to work on it recently for personal reasons, but the project is still very much active and receives regular updates!
No, nano is not my daily driver. It's what I use when I want to quickly edit a file with root access because, funnily enough, I'm not in the habit of running my primary editor with superuser permissions :) Nano is a low-hanging fruit that was the first of many tools I gradually massaged the editor into replacing.
Nice work! And yes, that gradual acceleration of productivity where your fixes and tweaks from the past compound on your ability to get things done in the future is a great feeling.
A thing that shocked me as I was working on the text editor was how capable modern terminal emulators are when you account for ANSI extensions. First-class clipboard access, mouse events, precise text styling, focus tracking, system notifications, key press/release events, etc. are all possible with a modern terminal emulator. There's not really anything else you need to build a very competent, ergonomic editor UI.
You can even use tools like trolley to wrap the entire application up in a ghostty-powered shim that presents the application as a native UI application: https://github.com/weedonandscott/trolley
I appreciate this, but I'm not concerned with the capabilities of the terminal or the GUI. What would be unhelpful, to me, would be to build a TUI because then if I wanted to send the actual app state to - for instance, a web browser which runs the library in WASM - the only way would be to pipe the terminal output across the shared buffer, instead of just blitting the app/editor state into it (or the relevant messages, like CRDTs).
Contrast that with a library: I could capture the inputs from any source - browser, native app, network, etc - work with the data using the single library, and then render the result in whatever client (or as many clients) as I wanted.
Yes, absolutely. I've since switched to rope-backed buffers, but I don't think the rope itself is actually adding much from a performance standpoint, even for really very large files.
We talk about big-O complexity a lot when talking about things like this, but modern machines are scarily good at copying around enormous linear buffers of data. Shifting even hundreds of megabytes of text might not even be visible in your benchmark profiling, if done right.
When benchmarking, I discovered that the `to_pos`/`to_coord` functions, which translate between buffer byte positions and screen coordinates, were by far the heaviest operation. I could have solved that problem entirely simply by maintaining a list of line offsets and binary-searching through it.
Unmentioned in the post, but I have since switched to a third-party rope library (crop, not ropey). At some point I'd like to implement one myself, but for now this does the job.
That is certainly true! If your target is end users, use the off the shelf solution that has been inspected by many eyeballs. The best part of building tools for yourself or a small community of people is that you only need to cover the relatively tiny subset of functionality that you actually use.
> the biggest drawback of async is the fragmentation of the ecosystem
95% of the ecosystem uses tokio nowadays. async-std has been dead for a long while. There are other runtimes for specialist purposes, but pretty much all async libraries will work with tokio, and you should just use tokio. It's fine. It's well maintained. It's not going anywhere. It's hit a stable 1.0. There is basically no reason to not use it.
> So, if you think that you didn't have enough work solving the problems of your users, you now also need to update your toolchains, Dockerfiles, dependencies and more, every 6 weeks.
This is complete rubbish. Rust's edition system means that Rust code written back in 2015 will (largely, bar some minor soundness issues that have been found since then) still compile. You're under no compulsion to update anything, and cargo's lockfiles ensure that your builds don't suddenly break. If you want to upgrade, do so! But it's exceedingly rare that code ever needs to change when doing so. It's about a painless an upgrade experience as it's possible to have in this industry.
> Rust is betting everything on a powerful language backed by advanced theory, but it forgot that developers need more than a language to build solutions to businesses' problems.
No, it didn't. Rust's standard library is not designed to give you everything you need to build a large program. Instead, it's designed to specify the interfaces that other libraries in the ecosystem require to talk to one-another, and it's been remarkably successful at that. Take a scroll through [the docs](https://doc.rust-lang.org/std/) and you'll see that: it's almost all traits, fundamental types, and other shared abstractions that are used by the rest of the ecosystem. Any non-trivial program is supposed to end up with third-party dependencies: the critical thing is that those dependencies can talk to one-another painlessly, and that promise is largely delivered upon: everybody uses the same interface for `Future`, `Iterator`, `From/`Into`, `Allocator`, `Clone`, `Eq`/`Cmp`/`Hash`/`Ord`, `Error`, `Debug`/`Display`/`FromStr`/`ToString`, `Read`/`Write`, `Sync`/`Send`. That's the sign of a remarkably successful and well-engineered set of abstractions.