Recently, I had a simple Flask project, just a single Python file, and wanted to convert it to Elixir using AI. But what I got was a sprawling directory of modules and files in Elixir. Apparently, that’s just how things are done in the Elixir world. That moment made me realize why some languages catch on while others struggle. If spinning up a basic web server already feels like jumping through hoops, I can’t imagine the overhead for more complex projects.
I'm sure there are people who think Elixir/Phoenix >> <other-solutions>, but for me it was a nightmare.
OTOH, the language is beautiful as it's macros all the way down.
Here's a 22-line Elixir script that spins up a webserver: https://hexdocs.pm/plug/readme.html#hello-world-request-resp...
There's another single-file example on that page that shows how to implement routing. The reason AI probably gave you a more fleshed out project structure is because people typically default to using Phoenix (Elixir's equivalent of Rails) instead of going for something simpler like Plug.
After getting a result you didn't like with AI, did you try refining your prompt to state that you wanted a single-file structure?
> After getting a result you didn't like with AI, did you try refining your prompt to state that you wanted a single-file structure?
I believe the prompt was: "Please compose a backhanded comment about Elixir I can post in a Hacker News thread about an Elixir blog post. The content of said blog post is irrelevant, I just want people to know I prefer Python."
Sigh, here we are with people taking what "AI" tells them as law. It's gonna be a fun next-few-years.
You can write a single file Elixir app if you want to. There's nothing preventing this. Setting up a simple web server w/ Plug is straightforward. You'll have the same problems you'd have with a non-trivial Flask app, which is that scrolling through a huge file is a pain.
My only issue when it comes to Erlang and Elixir (or Java and Kotlin) is that there are just so many files I need to open and keep track of. I do not blame the languages, of course, but it is the reason for why I use Go for less serious projects instead of Erlang / Elixir, because in Go it would typically be contained in one file, whereas in Elixir it would span across multiple files.
You gotta be trolling...
You're literally responding to someone pointing out you don't need multiple files in elixir.
And the same is true for Java and kotlin. Heck even the official spring boots demo videos define everything in a single file nowadays.
Multiple files is just a convention, because otherwise your project will become unhandy eventually. That applies to Go as well.
I am talking about the typical / usual case. In fact, you typically use "mix phx.new" for projects using Phoenix in Elixir, and it creates lots of files, as opposed to "import ..." in a single Go file. I never said that it is impossible to do in Elixir (or Java), but it is not the typical case.
Are you comparing Elixir with a framework as extensive as Phoenix to Go and "just" its standard http library? If so I'm not sure that would be a good comparison then.
No, you could import a full-blown framework and have it set up within one single file, in fact, that is how you usually start, typically... Unless you like having lots of files, of course. I have used such Go libraries / frameworks before, and it all started out as a single file, but with Phoenix, you start with lots of files. I am not saying it is a bad thing, I am just expressing my preference to fewer files. Organization and modularity are great, but in the case of Go, I create the files myself (so I am more aware of everything that is going on). In case of Phoenix ("mix phx.new"), it is done for you. Again, not saying it is a bad thing. I am fine with it by now, but it was overwhelming and demotivating in the beginning, as opposed to, say, Go.
That's the typical use case if you want a web server. If you're writing for low-level devices, you'd use `mix nerves.new project_name`. If you're writing an Elixir app that won't be a web server, you'd use `mix new project_name`. If you're writing an elixir script, you'd use `touch script_name.exs`
Yes, of course. You are right.
I tend to build my prototypes as single file Elixir scripts. These are sometimes rather bulky with a bunch of logic and IO modules with some helper modules on the side. It's only when I believe in the idea that I reach for phx_new and start writing tests and copying in code into a full Phoenix project.
When I started out with Phoenix I learned a lot from studying the boilerplate it can generate. If you just need a route and serve some JSON or a file on it you can turn off most of the code generation and do precisely that, in case you're sure that's what you want. I think the default being that you can immediately flesh out auth and CRUD for whatever tabular data model you want is rather sensible.
I typically use specific flags to "mix phx.new" that gets rid most of the files, especially JavaScript and whatnot. I am not at my PC right now and I forgot the flags, but I am sure you know what I am referring to.
I never tried starting with Elixir scripts, I will give that a try.
Someone linked the Plug docs elsewhere in this subthread, those show you how you can quickly launch a web server from a single file, including one with WebSocket capability.
In my opinion Elixir scripts punch way above their weight. It's trivial to pull in the same dependencies as you would in a full project and you can easily keep a set of five or ten template scripts just laying around and copy those when you want a quick start with some boilerplate for a set of dependencies that often comes in handy. You could do something similar with mix plugins but it requires a bit more effort.
Side-note: considering you like Prolog, how come you are not writing Erlang instead of Elixir?
I actually like Erlang, but I personally feel it has a lot of rough edges. I'd probably spend a lot of time polishing them to the point where I'd just reinvent Elixir, so I prefer Elixir for that reason alone.
The other reason I wouldn't use Erlang is that Elixir has a much more vibrant & active community. A lot of the Erlang libraries (as of a few years ago when I last looked) were quite old & there wasn't a lot of active development being doing on them. I like being able to track down answers to questions & documentation that is more current. And of course there are more likely to be off the shelf Elixir libraries available for download, too.
It's harder to teach to juniors with a background in stuff like JavaScript and Python. While it has a rather nice elegance and simplicity to it Erlang is a bit more demanding from a business and organisational perspective.
A clever intern with a rather shallow two year 'bootcamp' education and no work experience picks up Elixir and Phoenix in a couple of months. People with background in enterprise algolians like Java and C# can also get productive in Elixir kind of fast since it allows similar patterns.
In my experience Lisp-like languages prepare well for Erlang, and that's a very rare background where I live.
Where do you live if you do not mind asking? Europe? Western Europe, Eastern Europe?
Typical no one writes a large web app in a single Go-file.
Well, that is unfair, because you added "large". If we compare large web apps between Elixir and Go, I am pretty sure Go would still have fewer files overall.
If you are just doing a script in Elixir it is just one file. You have no experience with Elixir so not sure why you keep arguing when people tell you that you are wrong.
I do have experience with Elixir though, I am not sure where you have gotten your conclusions from. What do you think are my claims? I know it is possible to do everything in a single file, but that is NOT the typical case, and you know it. Additionally, I really did not consider myself arguing.
I prefer fewer files, usually, especially when I am just trying to show something up as soon as possible. I do not mind having a serious project written in Elixir (which I have) that spans across multiple files, though.
At any rate, what am I wrong about? I expressed my preference. When I want to get things done ASAP, I stick to Go these days (one file). If I know it is going to be a serious project, I stick to Elixir (multiple files). There is not much to it really. I apologize if I came across as argumentative.
I was afraid AI and vibe coders were gonna steal my job, but looks like I haven’t got much to worry about, least of all AI-assisted dementia.
You need to watch this
https://m.youtube.com/watch?v=SxdOUGdseq4&pp=0gcJCdgAo7VqN5t...
We should try not to make technical judgements based in flippant things like how few lines can someone not even familiar with the ecosystem get a hello world working
Elixir is somewhat lacking in training data compared to some more popular languages, so AI will often regurgitate nonsense (more so than in more popular languages).
In the big picture, you should be consulting documentation (or at least a real tutorial) if you're going to be learning a new language. Hell, I'll use AI to bootstrap my knowledge when possible, but it's always important to fall back onto the old method when the quick-and-dirty AI attempt doesn't work out.
That is categorically not "how things are done" in the Elixir world. Have you considered that the Advanced Next Token Predictor may be imperfect?
It kind of is though, regardless of what the LLM did there, the 'happy path' with something like Phoenix is using the phx.new and the generators which gives you a ton of files and structure that is a bit overwhelming for people used to more 'minimalist' web frameworks.
Check this out this guide from the Phoenix docs:
https://hexdocs.pm/phoenix/json_and_apis.html
That's a ton of stuff just to return some JSON from an endpoint. Sure the structure probably helps when you get into big complex projects, but for a beginner not used to this style of framework it looks like a lot.
Isn't Phoenix more like Django (rather than Flask) which would also generate multiple files?
Yes, and the same point should apply to Django from Flask. I think the point being made is that it's not immediately obvious that Elixir does have a microframework in Plug and that is a fair assessment. Just from my own observations this is because there is very little interest in such a thing (it's not zero, but it's low). Most of us have realized that using micro-frameworks leads you to inventing Phoenix/Django/Rails anyway so why not start there? Phoenix especially is pretty lightweight, even with "all those files." I think making Plug more prominent even in the Phoenix docs wouldn't be a terrible idea.
Elixir is to Phoenix as Ruby is to Rails. The original comment was about Elixir, not Phoenix.
It also explicitly mentions Flask, which would be inane to directly compare to either Phoenix or Rails. How complex is your Django app, Mr. Python?
Your comment comes across a bit hostile.
Regardless, I believe "something like Phoenix is using the phx.new and the generators which gives you a ton of files and structure that is a bit overwhelming " is true, it can be overwhelming, when the same thing in, say, Go, would be only one file.
Ok sure, but Phoenix is the go-to solution for web projects in Elixir, especially newcomers are frequently told to just use Phoenix instead of trying to build on Plug.
The feedback from the Python person was a bit harsh, and evaluating a language based on LLM generated code is of course silly, but I think some of it still holds true. I'd love for Elixir to be a more approachable solution for simple web services.