Nova: A New Web Framework for Erlang
32 comments
This seems like a tough sell when Phoenix is already so good. I'm struggling to see why I'd use this over that.
Because its not elixir, its erlang. For those of us who dont do elixir, this fits the knowledge I already have.
Nova is also more close to beam so it can be used with elixir and lfe or other beam languages.
Not sure how this hit the front page without linking the actual project.
https://novaframework.org/
https://novaframework.org/
Thank you. I missed to add a new line where the homepage is..
I will check this out. Are you familiar with the Nitrogen framework? I've used it a bit and quite liked it, but not sure it's really an active project anymore.
https://nitrogenproject.com/
Could you compare/contrast Nova to Nitrogen?
https://nitrogenproject.com/
Could you compare/contrast Nova to Nitrogen?
We did a fireside chat about it a couple of years ago.
https://youtu.be/PgBzV1-E00k?si=sULVBvLsVPm2S3zl
https://youtu.be/PgBzV1-E00k?si=sULVBvLsVPm2S3zl
You could add it to this Awesome Erlang list: https://github.com/drobakowski/awesome-erlang?tab=readme-ov-...
Why do you use Erlang instead of Elixir?
No rebinding, better fits the grain of the OTP, no AST macros. Last I checked, the debugging experience with elixir was pretty subpar. Erlang is also a fundamentally nicer syntax that I find a great deal more readable. I'm not really sure what the appeal of Elixir as a language is actually supposed to be, outside of people who have spent a lot of time writing Ruby code.
Full disclosure: I started with Erlang, I get paid to work with Elixir every day, I love Erlang still.
Why someone might like Elixir:
> Last I checked, the debugging experience with elixir was pretty subpar.
Just curious, why is this? All of the Erlang debugging stuff seems to work.
Why someone might like Elixir:
- slightly less crufty stdlib for a lot of the basic stuff (though we still use the Erlang stdlib all the time)
- the Elixir community started off using binaries instead of charlists so everything uses binaries
- great general collections libraries in the stdlib that operate on interfaces/protocols rather than concrete collections (Enum, Stream)
- macros allow for default impls and a good deal less boilerplate, great libraries like Phoenix and Ecto, and the community seems to be pretty judicious with their use
- protocols allow datatype polymorphism in a really nice way (I know about behaviours, they are also good)
- very standard build tool/project layout/generators that have been there from the start (Erlang has caught up here with rebar, it seems)
- a lot of high quality libraries for web stuff, specifically
- convenience stuff around common OTP patterns like Task, Task.Supervisor, Agent, etc.
> Last I checked, the debugging experience with elixir was pretty subpar.
Just curious, why is this? All of the Erlang debugging stuff seems to work.
> Just curious, why is this? All of the Erlang debugging stuff seems to work.
But you'd see a decompiled Erlang-ish code in the (WX-based, graphical) debugger, no? Genuinely curious, I think it was like that last I checked, but that was in 2019.
But you'd see a decompiled Erlang-ish code in the (WX-based, graphical) debugger, no? Genuinely curious, I think it was like that last I checked, but that was in 2019.
> I'm not really sure what the appeal of Elixir as a language is actually supposed to be
Easy:
Easy:
- rebinding
- higher-level OTP abstractions
- AST macros
- nicer, more readable syntax
- (optionally) cleaner stdlib
I'm not trolling, but I'm very serious about language design after going through a long gauntlet. I don't think making mutation easy, and also having the ability to hide code execution, is necessarily a good practice in a system principally designed for safe, robust and efficient concurrency. Don't use a flathead on a phillips screw.
Rebinding is not mutation. This seems pedantic but is an important distinction. None of the semantics of the runtime are changed. The data remains immutable. You probably know this. However, for the benefit of readers who may be less familiar: Erlang does not allow variables to be rebound, so it's somewhat typical for Erlang code like this:
Whereas writing the same thing in Elixir would look like:
The practical effect of this is that if you for example insert a process spawn somewhere in between any of the lines that references `x`, that process gets its own totally immutable version of the data that `x` points to at that point in time. This applies in both Erlang and Elixir, as data in both is completely immutable.
X1 = 8.
X2 = X1 + 1.
X3 = X2 * 302.
X1 = 8.
X1 = X1 + 1.
Whereas writing the same thing in Elixir would look like:
x = 8
x = x + 1
x = x * 302
The practical effect of this is that if you for example insert a process spawn somewhere in between any of the lines that references `x`, that process gets its own totally immutable version of the data that `x` points to at that point in time. This applies in both Erlang and Elixir, as data in both is completely immutable.
It should also be noted that handling state like that is not really idiomatic Erlang. State is updated at a process level, thus traditionally you spawn another process which is trivial to do. On the BEAM that is fast enough for 95% of cases. If you really need mutation on local variables for performance reasons, you should already be writing NIFs anyways.
State variables are what I think corpos call a "code smell". The BEAM/OTP isn't a number cruncher, there are better tools out there if you're doing a lot of that. Erlang is, at it's core, about constraint logic programming. It should be best thought as a tool for granular, scalable, distributable userspace scheduling. If you need something outside of that, NIFs or Ports. Both are quite nice.
State variables are what I think corpos call a "code smell". The BEAM/OTP isn't a number cruncher, there are better tools out there if you're doing a lot of that. Erlang is, at it's core, about constraint logic programming. It should be best thought as a tool for granular, scalable, distributable userspace scheduling. If you need something outside of that, NIFs or Ports. Both are quite nice.
This has nothing to do with math or number crunching on the BEAM. This has nothing to do with mutation. This has nothing to do with performance.
This kind of process and function-local static single-assignment code is all over the place in Erlang codebases. It's incredibly common. The other popular method is tail recursion.
I searched for literally 30 seconds and found these:
This kind of process and function-local static single-assignment code is all over the place in Erlang codebases. It's incredibly common. The other popular method is tail recursion.
I searched for literally 30 seconds and found these:
- https://github.com/ninenines/cowboy/blob/master/src/cowboy_router.erl#L139-L144
- https://github.com/ninenines/cowboy/blob/master/src/cowboy.erl#L201-L205
- https://github.com/ninenines/cowboy/blob/master/src/cowboy_http2.erl#L487-L506> It should also be noted that handling state like that is not really idiomatic Erlang.
It's not about the state but about intermediate results. When you have a value that you pass to one function, and then you need to pass the result to another function, you're not dealing with a "state" as OTP defines it, unless the calls are asynchronous. Often, they're not, and that's where variable rebinding comes in.
Worth noting: `|>` macro operator in Elixir serves a similar purpose, as long as you don't need pattern matching between calls. In that case, you don't have to name intermediate results at all, resulting in cleaner code.
> State variables are what I think corpos call a "code smell".
Having to call multiple functions in a sequence is the most natural thing to do, and Erlang code is littered with "X1 = ..., X2 = ...(X1), X3 = ...(X2)" kind of code everywhere.
It's not about the state but about intermediate results. When you have a value that you pass to one function, and then you need to pass the result to another function, you're not dealing with a "state" as OTP defines it, unless the calls are asynchronous. Often, they're not, and that's where variable rebinding comes in.
Worth noting: `|>` macro operator in Elixir serves a similar purpose, as long as you don't need pattern matching between calls. In that case, you don't have to name intermediate results at all, resulting in cleaner code.
> State variables are what I think corpos call a "code smell".
Having to call multiple functions in a sequence is the most natural thing to do, and Erlang code is littered with "X1 = ..., X2 = ...(X1), X3 = ...(X2)" kind of code everywhere.
There are some libraries (based on parse transforms) that introduce a sort of "do" notation to deal with this issue (erlando and its variations come to mind).
Also, the latest versions of OTP have introduced the `maybe` expression: https://www.erlang.org/eeps/eep-0049
Also, the latest versions of OTP have introduced the `maybe` expression: https://www.erlang.org/eeps/eep-0049
I love it. I didn't know. It's going to take a while to make this a pervasive feature of most Erlang codebases, but it seems like a good feature to introduce.
I know there are monad libraries using parse transforms and/or list comprehensions, but I often found their use is frowned upon in the Erlang community. I kind of assumed the GP in this thread would reject them, given their negative opinion on macros.
I know there are monad libraries using parse transforms and/or list comprehensions, but I often found their use is frowned upon in the Erlang community. I kind of assumed the GP in this thread would reject them, given their negative opinion on macros.
I was in a similar situation, ended up relying on libs that used parse transforms a lot and then found out most of my usage could have been replaced by the new `maybe` expression.
We started with Erlang before Elixir was created and we still use it for everything we do.
This is more to have a smooth web framework similar to Phoenix but for Erlang.
You can also use Nova for elixir.
This is more to have a smooth web framework similar to Phoenix but for Erlang.
You can also use Nova for elixir.
Not to pick on you, but there are always posts like this in every Erlang thread. One is not strictly superior to the other, and the BEAM community benefits from the variety IMO.
It seems he wanted to make an alternative to Elixir..
You've run into the same naming problem GM did with the Vauxhall/Opel Nova: "No Va" literally means some variant of "it doesn't go" in (at least) Italian, Spanish, and French.
While this is a nice story, it's not true [1] [2].
[1]: https://www.snopes.com/fact-check/chevrolet-nova-name-spanis...
[2]: https://en.wikipedia.org/wiki/Chevrolet_Chevy_II_/_Nova
[1]: https://www.snopes.com/fact-check/chevrolet-nova-name-spanis...
[2]: https://en.wikipedia.org/wiki/Chevrolet_Chevy_II_/_Nova
If nothing else, perhaps this persistent myth helps reduce the naming conflicts when someone wants to use Nova.
As a native Spanish speaker, this sounds totally made up. Nova sounds like an astronomy word, like supernova.
“No va” to me means something like “it’s not happening” or “the plans have been cancelled”. But it’s pronounced very differently.
And Uranus (when spoken aloud) means “your butt”. Is this really a big concern?
Future astronomers will rename it to "Urectum" to stop the stupid jokes.
https://www.youtube.com/watch?v=0czFnIvKOJY
https://www.youtube.com/watch?v=0czFnIvKOJY
I'm excited to share Nova, a new web framework built for Erlang, designed to make web development in Erlang simpler, faster, and more approachable. Nova leverages Erlang's concurrency, reliability, and scalability to create a robust yet lightweight framework for building modern web applications.
Key features:
* Lightweight and modular: Easy to integrate with existing Erlang projects.
* Built for concurrency: Harnesses Erlang's actor model for high-performance web apps.
* Developer-friendly: Simplifies routing, middleware, and template handling.
* Extensible: Supports plugins and custom integrations.
Check it out: GitHub: https://github.com/novaframework/nova Homepage: https://novaframework.org Getting Started Guide: https://dev.to/taure/getting-started-with-nova-1ioo/stats
We’re early in development and would love feedback from the community! If you’re an Erlang enthusiast or curious about building web apps with a language known for its reliability (think WhatsApp or RabbitMQ), give Nova a spin and let us know your thoughts.
What do you think about using Erlang for web development? Any features you’d love to see in a framework like this?