changelog.com VS elixir-ls

Another https://dagger.io fan here. Have been using it since late 2021 to continuously deploy a Phoenix app to Fly.io: https://github.com/thechangelog/changelog.com/pull/395. Every commit goes into production.

This is what the GHA workflow currently looks like: https://github.com/thechangelog/changelog.com/blob/c7b8a57b2...

FWIW, you can see how everything fits together in this architecture diagram: https://github.com/thechangelog/changelog.com/blob/master/IN...

I really like the work that you're doing Thomas, this is the right approach. FWIW, https://fly.io/blog/carving-the-scheduler-out-of-our-orchest... is one of my favourite posts on your blog.

For everyone else reading this, we have been running https://changelog.com on Fly.io since April 2022. This is what our architecture currently looks like: https://github.com/thechangelog/changelog.com/blob/master/IN...

After 15 months & more than 100 million requests served by our Phoenix + PostgreSQL app running on Fly.io, I would be hard pressed to find a reason to complain.

Changelog.com

I see this criticism a lot but I don't think it has anything to do with macros specifically and more so to do with lack of familiarity with Elixir. I've felt the same way about Django being magic because I had trouble following the class hierarchy. It makes a lot more sense now because I'm more familiar with Python and Django. But even today I'll be looking deeper at something and ask WTF it's doing. In that respect, Elixir codebases are easier to me. The module depth seems "shallower" and I don't have to disambiguate between what behavior is caused by class inheritance or an imported function.

When I first tried to use Elixir several years ago Ecto.Schema [0] seemed complex and magical, but then I came to realize it's just converting module attributes to runtime code. There is not really that much complex macro logic going on.

>This also leads to cryptic errors where you get an error in non existant lines of code.

When was the last time you used Elixir? This isn't a problem I can recall having in the last 4 years or so of using Elixir.

>following the control flow in Phoenix is like a maze because of all the macro substitutions.

Can you clarify what you mean by this? A specific case as to where this happened for you would help. Phoenix's use of macros is actually pretty light [1] except for some very low level stuff. You can even see how frequently a developer will use macros in Phoenix by searching `__using__` in the codebase [2]. It's not used as much as people think. The majority is for views and controllers and only to provide a very thin layer of support on top of your regular use of code. As an example, the "macro magic" in Phoenix.Controller is just handling some basics for giving a layout and view to Plug and handling fallback actions for exceptions. You could do the plug calls manually and I think it would be safe to not use any macros in your controller code.

Another familiarity issue with the language (and any language really) is understanding what is meaningful in a stack trace and what isn't. And the likely cause of the error in the first place. Is it syntax? Is it mistyping a variable? Is a function just used improperly? (wtf is init_p_do_apply and why does it show up in every stacktrace?) You're juggling all these different issues - learning a new paradigm, a new syntax, not knowing how to extend things. It's obviously going to be a little overwhelming and, if not strictly required, we might just pick a different language that we're more familiar with.

[0]: https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/sch...

[1]: https://github.com/thechangelog/changelog.com/blob/master/li... (not mine, I just go here to show the most frequent use of macros in Phoenix)

[2]: https://github.com/phoenixframework/phoenix/search?q=__using...

changelog.com used to be WordPress, then became a Phoenix app because it needed features that were hacky to implement & then manage in WP. It's more of a podcasting platform these days rather than a CMS.

The code in this repo tells the truth about what it is, and even shows how it works: https://github.com/thechangelog/changelog.com

No. Not even close. But it's getting better.

There are currently two worth mentioning:

ElixirLSP: https://github.com/elixir-lsp/elixir-ls

Elixir tools: https://www.elixir-tools.dev/

ElixirLSP is the older project, and has been around for a while. It does a lot, but has had sporadic issues over the years. Things like the debugger are a dog to get working, and the server itself will occasionally run into issues where it just doesn't want to work. It's always sort of focused on a subset of language server features, so don't expect much in the way of inline corrections. But it's got the essentials, formatting, basic linting, type hinting, on demand documentation, and primitive reference navigation

Elixir tools is a new up and comer, written by Mitchell Hanberg. It's aiming to be a more complete lsp, and has plugins in its "ecosystem" for most editors. Features have been arriving rapidly, starting with things like inline corrections and far more reliable linting, and recently growing autocomplete. One of the main selling points is the elixir-tools backend is a self contained binary, so it can mostly work independent of system Elixir/Erlang version, which was a frequent tripping point for ElixirLSP

Personally I use both at the same time, but plan to move to tools only when it's got all the features I need

I decided I can live without elixir-ls when couching in return for having a usable editor. When the plugin ecosystem and documentation matures I can see myself switching to using Lapce for my primary editor.

Hi! I've compiled gdb from master and installed it. When I run gdb -i dap, I get JSON-RPC, so it looks like it's working, but I'm lost as to where to go from here. Does your change enable me to use a tool like https://github.com/elixir-lsp/elixir-ls with GDB now, right? How might I use them together? What would be required to then have GDB debugging over DAP from inside Emacs?

Elixir-ls provides Language Server Protocol support as well as VS Code Debug Protocol support which gives extra powers to VS Code, NeoVim, Emacs, and the like

https://github.com/elixir-lsp/elixir-ls

BUT, with the news that in the next Emacs version eglot (lsp client) is going to be in the core, I decide to modify alchemist in a different way, enhancing other capabilities and letting eglot do what he best does (which is the functionality of elixir-ls).

I think it's here: https://github.com/elixir-lsp/elixir-ls

elixir-ls powers the VSCode experience, and while it works decently, I've never really clicked with VSCode. In general, for other languages, I tend to use Jetbrain's Products. I would love to give fleet a whirl, and I know in the background it can use the Language Server Protocol to support many of the languages it currently ships with.

Now it doesn't mean that immediately reading this starter guide, you will have everything under the sun set up with Nix Flakes for your development need. But at least, you won't have to worry about setting up asdf, your weird hacks you need for your machine and the other tiny little things to get elixir started with elixir-ls.

I have a minimal lspconfig with coq_nvim with elixirls and tsserver. The problem is that whenever i code on elixir everything becomes slow.

Well I know one extension that runs your code, elixir-ls. I believe it scans your code and runs dialyzer, a static analysis tool, which runs your code and generates types based on it.