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

  • 8 Posts
  • 314 Comments
Joined 1 year ago
cake
Cake day: July 2nd, 2023

help-circle







  • 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





  • How exactly do you debug code when your build process is separate from your code editor? Having to compile my code, run it until I find a bug, then open it up in a debugger and start it all over sounds extremely inefficient.

    There’s a lot of incorrect assumptions baked into this. While you may choose to invoke your debugger separately from your editor, many modern editors support the Debug Adapter Protocol (DAP). This is a protocol developed by Microsoft for VSCode, and the VSCode debugger is quite powerful. I’ve only used Visual Studio many years ago, but from what I recall, the VSCode DAP is essentially just as powerful. And if you’re not interested in VSCode, the Helix editor and probably NeoVim also support DAP.

    how to make the transition from a Visual Studio user to a Linux programmer

    You are also coming in with the constraint of programming in C++. For this specific language, I think I agree with others here that either CLion or VSCode+CodeLLDB are your best options today. Maybe after you get comfortable in the Linux environment, if you want to try something more keyboard-centric, install a Vim emulation plugin or even jump right into Helix or NeoVim.