mov_

I agree with you, it's weird that Swift JSON is so slow and binary isn't necessarily faster.

My exasperation is you were surprised by JSON becoming an issue, when this was the most controversial design decision about the project. To me, it's completely unsurprising.

On the github page https://github.com/xi-editor/xi-editor:

  JSON. The protocol for front-end / back-end communication, as well as between the back-end 
  and plug-ins, is based on simple JSON messages. I considered binary formats, but the actual 
  improvement in performance would be completely in the noise. Using JSON considerably lowers 
  friction for developing plug-ins, as it’s available out of the box for most modern languages,
  and there are plenty of the libraries available for the other ones.

4 years later:

  The choice of JSON was controversial from the start. It did end up being a source of friction, but for surprising reasons.

  For one, JSON in Swift is shockingly slow.

Surprising reasons?!

Ok, I understand what you mean. Thanks for being considerate, I usually don't express my opinion in these discussions, hopefully I didn't come across very rudely.

> For example, redlining may now be illegal in the United States, but middle class white Americans have been benefiting from nearly a hundred years' worth of wealth accumulation through housing that black Americans were locked out of. This is a good example of how the "system" produces racially-biased outcomes without any racist human input in the present day.

I think this is describing how the system includes momentum, and you're saying that the system (momentum) is producing racially-biased outcomes _without_ racist input today. That's true in the strictest, most technical sense, but is this supposed to be a motivation for reparations or something?

It seems like you're saying momentum is racist.

Correct me if I'm wrong, but I don't think the person you're responding to is in opposition to you.

You're welcome, I hope it helps! To preface this, I think Ubuntu 20 comes with good font rendering options by default, so my suggestions are mostly unnecessary. I just wanted to experiment to see if I was missing anything. All the options I'm referencing are explained in detail in this blog post (e.g., subpixel rendering and lcd filtering), they're all just configuration options in the freetype2 font renderer.

I found that the Arch Linux wiki page (https://wiki.archlinux.org/index.php/Font_configuration) is helpful because it applies to other distributions like Ubuntu, and provides example configuration files. (https://wiki.archlinux.org/index.php/Font_configuration/Exam...)

This is a fantastic post, I just bought a 28", 158 dpi monitor recently and spent quite a bit of time figuring out how to maximize the font quality.

Since there weren't any suggestions for linux, this is what I did for Ubuntu 20:

    * 2x scaling
    * Downloaded libfreetype, enabled subpixel rendering option, replaced existing libfreetype.so
      (I think Ubuntu 20 might already have this enabled, but just to be safe I did it manually)
    * Turned off all hinting options in font configuration
    * Turn on lcddefault filtering
      (necessary if you have subpixel rendering enabled)
    * Specifically set 158 dpi in Alacritty terminal config
      (Not entirely sure that's necessary?)

I can relate, maybe this is the paradox of choice?

That said I agree completely, `Option`/`Result` themselves (even if they are just intrinsic language elements, not user-implementable types) are valuable.

I work on network switches too, but we take the C SDK source, reverse engineer it, and write a bunch of C++ software that mostly does the same exact thing. It's already insane, I would not be surprised if some Rust components were added.