zesterer

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.

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.

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!

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/

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.

Thanks for your kind words, they mean a lot.

Frankly, I spend a lot of time feeling similarly uncomfortable about my relationship with computers and the industry at large. I think, perhaps surprisingly, I'd call myself a 'technophobe' for this reason.

I think there's a parallel universe out there in which the arc of technology bends toward a future I actually want to live in, but I'm fairly sure we aren't in that universe today. But perhaps if we talk more about how to use the darned things in a manner that enhances the human experience rather than detracts, we can get closer to it.

That's fair enough!

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

That's odd, I've not heard that reported by anybody else. If I get time I'll look into it.

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.

Author here. Off the top of my head:

- Software is simpler than you think when you boil it down. There's a massive incentive to over-sell the complexity of the problem a solution is trying to solve, to pull in users. This is true both for proprietary products and, to a lesser degree, FOSS. You can probably replace most of the tools you use day-to-day in a weekend or two - provided you keep practising the art of just building stuff. I'm not saying that you should, but it's worth keeping in the back of your head if a tool is driving you mad.

- You can achieve 80% of the functionality with 20% of the work required to build an off-the-shelf solution. In a surprising number of cases, you can do the same with 20% of the integration cost of an off-the-shelf solution. A lot of software is - to put it quite bluntly - shit (I include a lot of my own libraries in this list!). There are probably only a few hundred really valuable reusable software components out there.

- Aggressively chase simplicity and avoid modularity if you want to actually achieve anything. The absolute best way to never get anything useful out of a project is to start off by splitting it into a dozen components/crates/repositories. You will waste 75% of your time babysitting the interfaces between the components rather than making the thing work.

- Delete code, often. If you look at the repo activity (https://git.jsbarretto.com/zesterer/zte/activity/code-freque...) you'll see that I'm deleting code almost as much as I'm adding it, especially now that I've got the core nailed down. This is not wasted effort: your first whack at solving a problem is usually filled with blunders so favour throwaway code that's small enough to keep in your head when the time comes to bin it and make it better.

- It is absolutely critical that you understand the fundamental mode of operation of the code you've already written if you want to maintain development velocity. As Peter Naur said, programming is theory-building and the most important aspect of a program is the ineffable model of it you hold in your head. Every other effort must be in deference to maintaining the mental model.

Yeah, it's a pretty blatant cult masquerading as a consensus - but they're all singing from the same hymn sheet in lieu of any actual evidence to support their claims. A lot of it is heavily quasi-religious and falls apart under examination from external perspectives.

We're gonna die, but it's not going to be AI that does it: it'll be the oceans boiling and C3 carbon fixation flatlining that does it.

(they are all wrong)

A fun property of S-curves is that they look exactly like exponential curves until the midpoint. Projecting exponentials is definitionally absurd because exponential growth is impossible in the long term. It is far more important to study the carrying capacity limits that curtail exponential growth.

I'm slowly preparing it to be released, I just have a lot of IRL stuff going on!

They did. It's called 'DNS' and you can set up a 'page' about yourself if you want.

Right, and if the original statement is true - that price drops are killing supply (without providing houses at a sufficient level) - then that implies that housing does not work like a traditional commodity. Which it doesn't.

Are you ok

The point is not the final product, the point is the process.

I love this, this is exactly the sort of thing I've experienced too: building the toy project gave me an on-ramp to something similar but much more complicated in the future.

Apologies, I overhauled the entire website (backend and all). I wrote a post about it, if you're curious.

That sounds as good a reason as any to become a pirate, frankly

This is the point, yes! Toy software is not production-worthy. It might not even be sufficient for your own personal use. It's about building proof of concepts and rapidly scouting out the terrain of a field you don't know much about, and getting a souvenir to remember the experience with.

Oftentimes I find that I enjoy one of the projects so much that I take it further than 'toy', but that usually ups the time estimate by an order of magnitude.

I think what you've identified is the "certain kinds of learning" I mention in the post.

If I want to learn about the structure of ELF binaries, I don't figure it out from first principles. I can't: the decisions that went into its design where highly specific to its history and the sensibilities of its creators, and in a modern context a lot of those decisions are near enough random. These are the sorts of things you should use specs, docs, Google, and maybe an LLM for.

What I'm talking about is, I guess, 'constructive' learning. I might not be able to build my own ELF parser through guesswork, but I probably can write a binary format of my own and a simple OS kernel to read it, given enough time. It probably won't look much like ELF, but the process of discovery that'll happen will teach me about why ELF came to be and what problems is solving, and also about the wider design space that sits around it.

My suggestion is that you should not use an LLM's help for the latter.

I like to think of it this way: if you bolted me to a chair in a room with nothing but a laptop, a text editor, and a compiler, what might I be able to create if you left me for 10 years? What couldn't I create because I wouldn't have sufficient implementation-specific information?

(I'm the post author) Actually, I would recommend that you don't ask an expert friend for help. If you get really stuck then maybe do some light reading about the topic: but the point is to throw lots of things at the wall and puzzle your way through it. Figuring things out from first principles is fun and also provides you with a litany of creative thinking skills to help you tackle other problems. I firmly believe that spending time confused is an essential ingredient in the process.

Obviously, you're welcome to do as you please though, mileage may vary, etc.

That's a really neat little gizmo. Makes me want to spend more time playing around with web tech.

All great ideas to add to my todo list!

The 10/10 was a copy & paste typo, sorry! Amended now.