What are the benefits of Rebar3?

Questions / Help
1

Hello, I can see that rebar3 is everywhere in the erlang community but I can’t see what’s the real benefits from ?
I means if I have a standalone application why not just doing application:start instead ?

2 Likes
2

To me, the main benefit of rebar3 is exactly the fact that it’s everywhere.
That means that if I want to contribute to an open-source Erlang repository… or if I change jobs in the future to a different company that also works with Erlang projects… I don’t need to learn how to manage the project(s). It’s just rebar3.

That’s not a minimal thing at all and it has some collateral benefits:

  • I can use a shared CI infra/config/etc. for all my projects.
  • Once a new plugin comes along (say rebar3_hank to delete dead code), I know I can use it for all my projects.
  • If there are improvements on rebar3, they automatically improve all my projects :slight_smile:
8 Likes
3

Yeah I think there are a few things that come with rebar3 that are now part of the landscape but weren’t before:

Non-circular dependencies, being able to work with repeatable fetches and upgrades, better dependency hygiene around tests, a more standard project structure depending on what OTP demands, clearer declaration of runtime dependencies, etc.

There are a few things that came as an indirect consequence of rebar3 using hex as a package manager (which has no public namespacing), such as better versioning, and a consolidation of multiple public forks or common libraries into a single package.

In general I think one of the good subtle things rebar3 did is slowly impose this sort of structure on the open source community. If someone were to build a new tool now, they’d likely have a cleaner state to work from than rebar3 had, though we also brought in new challenges (eg depending on plugins makes it hard to replace things) because people do rely a lot on specific semantics of the tool.

2 Likes
4

On rebar3.org you’ll also find:

  • Develop: Write, test, and maintain projects the Erlang way
  • Package: Use, build, and publish packages on Hex
  • Release and Run: Package software and roll it out in production
    (there’s loads of useful information on the site)

For me, it started being about dependency management, packaging, and consistency across several projects, but with plugins, especially, it’s all about what @elbrujohalcon referred. At the same time, as @MononcQc hints, it becomes increasingly hard to work without it (or a similar tool) when your project grows and you have multiple dependencies with multiple dependencies.

3 Likes