Professional software engineer, musician, gamer, amateur historian, stoic, democratic socialist

  • 1 Post
Joined 1 year ago
Cake day: July 2nd, 2023

  • Well I guess I can give my opinion as a former VSCode and Vim user that migrated to Helix. @[email protected] was curious too.

    Way back when, I used Sublime Text and got proficient with those keyboard shortcuts. Then VSCode eclipsed (pun unintended) Sublime, so I switched and I was thankfully able to keep using Sublime key bindings. I was also productive with VSCode, except it wasn’t popular at the company I was working at, where most people used Vim. I ended up learning a bit of Vim for pair programming, but I still clinged to VSCode, even though it lacked proper support for connecting to a VM via SSH (which was a very common workflow).

    At some point I realized that it was important to have a totally keyboard-centric workflow to level up my productivity and ergonomics, and being able to use a mouse in VSCode was hindering my progress. So I tried NeoVim, and it was kind of a nightmare. I know many people enjoy tinkering with Lua to get NeoVim working as they want, but I found it more of a barrier to productivity than anything else.

    So then I learned about Helix, and it seemed like a love letter to devs that just want a modal in-terminal editor that works out of the box and has modern features like LSP support, DAP, etc. Also it’s written in Rust by good maintainers. I haven’t looked back, because the Helix + Tmux combo is incredibly versatile.

  • Gleam is cool. I wrote some services with it to see if I wanted to use it for more projects. It seemed like a good option because it would be easy to teach.

    Things I like:

    • fast build times (I only tested small apps though, under 2000 LOC)
    • strong static types
    • runs on the BEAM
    • easy to learn
    • pattern matching
    • immutable + structural sharing
    • currying (with parameter holes)

    Things I don’t like:

    • no re-exports
    • it’s possible to have name collisions between packages; authors have a gentleman’s agreement to always create a top-level module with the same name as the package
    • some standard library APIs seem missing or immature (it’s still pre-1.0)
    • it can be hard to get good performance out of idiomatic code for specific tasks (see immutability)
    • no format strings; best you can do is "Hello, " <> name. It starts to get cumbersome
    • parsing/serialization is all quite manual boilerplate; there’s nothing quite like serde
    • no field/argument punning
    • no method syntax; you just have to scan the docs to figure out what functions can be used with a given type
    • you can’t define the same variant name twice in the same module; I believe this is a limitation in how the types are translated to Erlang records
    • you can’t call functions in pattern matching if guards
    • you can’t have dependency cycles between modules in the same package
    • hard to write FFI correctly; you lose all the comfort of types