Rust maintainer perfectionism, or, the tragedy of Alacritty

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
  • alacritty

    A cross-platform, OpenGL terminal emulator.

    I take it this is about https://github.com/alacritty/alacritty/pull/4987?

    If so, as a non-user of macOS: I look at that picture and say that putting it in a white box makes it very ugly and I’d reject it too. It makes it stick out like a sore thumb in a different direction—compare it to the Terminal icon next to it, which doesn’t have such white padding. Now if there’s a problem with the scale of it, that it’s currently going to the edges of its bounding box but should have 10% padding on all sides, that I could understand, and I would expect a patch to scale it down to 80% for that type of consistency to be accepted. It might even be worth experimenting with taking the original artwork and increasing the border-radius to match Apple’s style, though that’s definitely going to be more iffy.

  • nix

    Rust friendly bindings to *nix APIs (by nix-rust)

    This post fails to speak to me on two fronts:

    * The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe* wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code. The author unfortunately chose a particularly messy and bug-prone corner of the POSIX APIs to wrap, and ran into a correspondingly intensive review process. I've merged simpler wrappers[1][2] with no fuss.

    * Alacritty seems to work just fine. I switched to it about two months ago, after using nothing but (heavily customized) rxvt-unicode for a decade. Maybe it's because I don't use ligatures or images in my terminals (I thought we were talking about non-"toy" functionality!), but I haven't found myself wanting for anything beyond what Alacritty already does. And the scrollback seems to work nicely. To summarize: where's the tragedy?

    [1]: https://github.com/nix-rust/nix/pull/1342

    [2]: https://github.com/nix-rust/nix/pull/1331

  • InfluxDB

    Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  • wezterm

    A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust

    There is also Wezterm which does have support for ligatures https://github.com/wez/wezterm

  • Etherpad

    Etherpad: A modern really-real-time collaborative document editor.

    I'm perfectly ok with a maintainter reserving the right to modify or even force-push a PR. If feature-wise the PR has value, but there are other requirements that have to be meet in order for it to be mergeable, I see no problem in the maintainer making his hands dirty. This contributor's work is recognized, and the maintainer can keep growing the project the way he wants.

    Not every occasional contributor will become a project member, so it makes no sense to impose too much burden on him. Maybe he only wants an interesting feature added.

    Some of them will eventually become interested in becoming regular contributors, and that is even better, but every one should be left freedom of choice.

    In my experience as Etherpad maintainer (1.6.5 through 1.8.4) this approach worked very well. For example https://github.com/ether/etherpad-lite/issues/3540 (and the related PR https://github.com/ether/etherpad-lite/pull/3559) where deep changes that went very smooth, not only code wise, but above all wrt the relation with the contributor, who was smart and collaborative.

  • coreutils

    Cross-platform Rust rewrite of the GNU coreutils

    I actually have experience with this specific code. I recently fixed a bug in a function that his PR also touches: https://github.com/nix-rust/nix/pull/1521

    And I have a PR to fix problems in another Rust wrapper of the same libc functions: https://github.com/uutils/coreutils/pull/2653

    It's hard to get right. Skimming the PR, the feedback looks reasonable.

  • kitty-icon

    An alternative app icon for the Kitty terminal emulator (by k0nserv)

    There's a similar thing with Kitty, which has a pretty bad looking icon that has sentimental value for the maintainer. The maintainer has expressed that they have no interest in changing the icon.

    I simply made my own[0] and replaced it on my machine, easy enough and I fully respect the maintainer's position. It takes 30 seconds to replace the icon with an alternative, in fact you can probably automate it if you wish.

    0: https://github.com/k0nserv/kitty-icon

  • tilix

    A tiling terminal emulator for Linux using GTK+ 3

    I use tilix[0] - it has both tabs and split windows with excellent customization options (accessible via UI). It is quick and I haven't had any issues with it so far.

    [0]: https://gnunn1.github.io/tilix-web/

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • kitty

    Cross-platform, fast, feature-rich, GPU based terminal

    catting a file in kitty can delete files from /tmp [1]. I don't think Kitty's enthusiasm for merging features without thinking about them hard enough is a good way to go either.

    [1]: https://github.com/kovidgoyal/kitty/blob/2350952d054bcaf945a...

  • rust

    Empowering everyone to build reliable and efficient software.

    Quoting woodruffw:

    > The `nix` crate is a cornerstone of the Rust development ecosystem: if you do anything that requires POSIX or various nix-specific APIs beyond those wrapped by the standard library, then `nix` most likely provides a high-level and safe wrapper for them. Perfectionism is a virtue in this context, one that keeps large parts of the Rust ecosystem from accidentally consuming buggy code.

    I think "refuse to integrate code until every conceivable thing is thought out and dealt with" is the right* approach when contributing unsafe code to Rust projects, especially to a foundational crate. Rust is designed around the separation of safe code (which allows non-expert programmers to write code with the speed of C and the safety of Java), and safe APIs around unsafe code (exposing a interface around dangerous primitives, constrained so non-expert programmers can't misuse the API to achieve undefined behavior, use-after-free, dereferencing wild pointers, reading uninitialized memory, etc.).

    To ensure that safe Rust is actually safe (can't achieve segfaults), third-party libraries which expose safe APIs around unsafe code (like nix) should be proven/provable to never use-after-free, write to wild pointers, expose uninitialized data, etc. This is a high bar to clear, and takes dedicated learning to develop the necessary expertise. But not doing so would expose users of the library to possible segfaults when users "hold the API wrong", which is the failure mode of C++ that Rust exists to avoid. Sadly, the compiler and standard library itself has some unsoundness bugs (described as the "worst kind of bug") which allow convoluted code constructions to result in segfaults despite not containing `unsafe` blocks . These are tracked at https://github.com/rust-lang/rust/issues?q=label%3AI-unsound.)

    On the topic of application-level code quality (rather than foundational libraries), I believe that for native applications, code which can't be proven to be memory-safe (either because the program's author doesn't know C++ and the libraries well enough, or because they accept poorly written code from outside contributors) is a significant factor towards the instability of C++ apps I've used. I'm not sure how to best develop this knowledge; perhaps newbies creating/maintaining codebases could be mentored by more experienced developers (who hopefully have prior experience with the app or problem domain)? Perhaps managed/GC'd languages make it easier to write approximately-correct code, since they don't require global architectural knowledge and flawless reasoning to avoid segfaults. However it still takes global architectural knowledge and flawless reasoning to avoid race conditions.

    Even though I value code quality over velocity, and despite how incorrect memory-management and threading inevitably results in broken programs, I hate to admit that that gatekeeping code quality and user-facing experience (perhaps architectural design?) could result in more stress, less progress and contributors, and a worse end result.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts