Software Disenchantment (2018)

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

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

    An extremely fast bundler for the web

    > And it's not even compiling and optimizing and linking, it's just transpiling typescript to javascript. It's ridiculous. It's ridiculous to think we can't do better.

    I don't do (much) frontend development, so I haven't had a chance to use it, but it looks like esbuild does do better: https://esbuild.github.io/ -- are you guys able to use that?

    I agree with the sentiment, though! And it's part of the reason I like Go: build speeds are fast, especially incremental builds (which is almost all the time, given how it caches compiled packages).

  • utf8

    Fast UTF-8 validation with range algorithm (NEON+SSE4+AVX2) (by cyb70289)

    > Nvm. Those methods use SIMD tricks, which while neat are hard to generalize.

    I've been writing this sort of parser lately and I don't think people's fear of this stuff is at all proportional to the actual level of difficulty.

    Looks like you can use this on ~every CPU someone might plausibly be using as a laptop to write code on: https://github.com/cyb70289/utf8. If you didn't use an off-the-shelf implementation, you would need 2 implementations of your inner loops to you target ~all x86 machines + M1 macs or 3 if you also want to go slightly faster on the vast majority of x86 machines that have AVX2.

    > Also not sure what JSON-RPC is referring to? LSP? Are you arguing that JSON is suboptimal? Like maybe, but it's close enough to rival binary formats. Plus you can parse GB/s of JSON.

    I'm arguing that IPC is suboptimal for use cases that do not need IPC.

    > Even text editors that forgo LSP have speed issues, unrelated to JSON.

    I'm arguing that this is probably not due to the essential complexity of text editors.

  • 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.

  • rust

    Empowering everyone to build reliable and efficient software.

    > - You still need a fallback and to deal with different archs.

    Yes. That's 2->3 implementations or 3->4 implementations to target everything instead of only SSE and NEON.

    > - SIMD is a different way of coding. You can't take algorithm from Wikipedia and just implement it in SIMD.

    I agree, but as I said above I think the level of difficulty is a lot lower than people expect.

    > - Even if you code it to perfectly use SIMD, using those instructions, might result in higher CPU demands.

    This is a common misconception which I think is better addressed by Daniel Lamire here: https://github.com/rust-lang/rust/issues/68455#issuecomment-...

    > - You will still lag behind games, because those use CPU+GPU while this heavily taxes CPU. You would need some GPGPU. Which is like SIMD all over again.

    I don't think so, because games don't usually use GPGPU. They usually do all of their layout stuff and game logic on the CPU and use the GPU for deciding what colors pixels ought to be. This is something a text editor has to use a GPU for too, even if the dev doesn't end up knowing about it.

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