mattste
Joined 13 years ago
Joined 13 years ago
And the pricing scheme is awesome, especially for smaller teams.
While I've been fortunate to have early access to Earthly CI, the cool thing is that the Earthly primitives it uses are available for everyone to see in the latest launched version [2]. The only puzzle piece missing is distributing the compute amongst different machines but that appears to be on the team's mind.
And the zero-margin compute pricing is a breath of fresh air.
We're a <10 person start-up. $40/mo seems too much relative to how often we'd use the tool. I would use this tool if there was a cheaper option ($10/mo/editor) for a team of our size.
After gaining some recent experience in Go, I'd still choose Elixir for any web project. Phoenix/Ecto/Absinthe/LiveView are all extremely productive libraries for web projects. Tooling/infrastructure work may be another discussion.
I think there is room for a framework similar to Phoenix LiveView but also allows compiling certain interactivity to the client. Next.js and Remix are kind-of fulfilling this but they have downsides.
In the BEAM ecosystem, I think there is room for [Gleam](https://gleam.run) to be used to compile to both Javascript and the BEAM.
>Dagger has a wider scope: build, test, deployment, any part of a CI/CD pipeline really
I don't see any reason this can't go into an Earthfile. We have all of these parts in our Earthfiles.
The one common pain point that both Dagger and Earthly haven't solved for me is unifying the machine parallelization with the DAG parallelization. According to this comment[1], it seems like Dagger doesn't have that goal.
For example, we only run our +deploy target if +build, +test and +lint pass. We parallelize each of those targets across workers in Github Actions. I don't know what the solution is to this problem but I know this was annoying to have to handle with Github Action's workflow syntax and horrible to debug locally.
Is there a way to handle the configuration in Terraform?
EDIT: see sibling comment from anurag. It appears they now list the regions they support in their documentation.
Here are a few pain points I've ran into: 1. Typespecs leave something to be desired compared to other type systems 2. Maps vs structs and easily using one in place of the other
Things that my team would like to see: 1. Components in addition to templates as a first-class citizen in Phoenix. My team loves React because of the component model even though we hardly use an insane amount of interactivity.
That being said, I don't have any hands-on experience with Ash so I can't speak for its approach to macros. I do think Zach's work in the community with Ash/Igniter is something to be applauded for. I'm currently working in a Python codebase that lacks conventions and would kill for something like Ash that provides consistent design patterns.