HN user

mattste

90 karma
Posts1
Comments48
View on HN

This is the beauty of Elixir's macros. For a lot of libraries, they are usually just calls to an underlying function with the same name. Because of Elixir's functional style and immutability, it makes it much easier to read through the magic compared to macros in other languages.

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.

It's great to see this publicly launch! Congrats to the team on making a great product. The Earthfile + Earthly CI approach is so much better than GHA or CircleCI. I feel like the only piece missing is distributed builds. Maybe one day?

And the pricing scheme is awesome, especially for smaller teams.

I've been a very happy user of Earthly and this is one of the final pieces of the puzzle that I've been waiting on[1]. I've found Earthly to be the perfect balance between declarative, repeatable, flexible yet easily understandable.

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.

[1] https://news.ycombinator.com/item?id=30869904

[2] https://github.com/earthly/earthly/releases/tag/v0.7.0

As someone in the ecosystem, I've found a noticeable uptick in job postings the past few years. I haven't applied for such jobs so I can't personally attest to it.

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 agree heavily with this assessment.

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.

Flutter 3 4 years ago

I'm curious if anyone can comment on their experience using the HTML renderer.

I recently converted my company's build process to Earthly. I find its syntax to be much easier to grok than CUE. They've also extended/added Docker commands that shore up some of the pain points of working with Dockerfiles.

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.

[1] https://news.ycombinator.com/item?id=30859864

This was wonderfully written. As a Nix beginner, I found it super helpful and wish there was more documentation that explained the major aspects of Nix this clearly.

My team has had success training experienced devs in Elixir that were coming from other backgrounds. I would caveat this with the fact that we just have a Phoenix app with hardly any code that leverages OTP.

This was a pain point for me when I was first evaluating them too. I had to manually email support for them to inform me they run in GCP US West

EDIT: see sibling comment from anurag. It appears they now list the regions they support in their documentation.

I 100% agree about Elixir and its surrounding ecosystem being almost perfect. It's insane how simple the building blocks are and how easy the code is to read and write.

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.

Phoenix + Ecto has been the best web framework experience I've ever encountered. I have experience with Django, Flask, Express and Rails. I'm a huge fan of Elixir as a language and the BEAM runtime. The libraries have been pretty great too.

I agree that templating could use a more forward-looking approach as a first-class concept (something like https://github.com/github/view_component).

I recently started a SwiftUI project and this is a very accurate take based on my experience.

How I spend my time in SwiftUI: 1. Wondering how I can get some conditional logic. Coming from React, this is a major issue that needs to be addressed. 2. Figuring out where and what the error actually is. 3. Restarting Xcode for my view to magically start working again.

The two-way data binding is a blessing and a curse. I like React's method of passing callback functions to keep the state logic separated. This comes up with me when working with sheets.

I see the potential. I like having an all-in-one experience that IDE + framework integration provides but the poor defaults and breaking bugs really make me question the execution.

Now 2.0 8 years ago

NOTE: v1 is fully maintained and supported. We will only announce a deprecation date once we have ensured all our customers workloads are migrated and the tooling is in place for a smooth transition.[0]

Based on that, it seems to me like I will have to migrate to Now 2.0 eventually.

[0] https://zeit.co/docs/v2/platform/upgrade-to-2-0

Now 2.0 8 years ago

One of the major pain-points I've hit with this concept of a "Monorepo" is tooling support since many things are built on the premise of separate repos for each code base. Pain points: Git+Github issues, CircleCI, etc. How do you handle those problems?

Now 2.0 8 years ago

I'm in the same boat. I've spent a lot of time getting my company's deployments set-up on Now's Docker offering (which was awesome). I'm not looking for my app to be serverless. And I'm also not looking for a "Majestic Monorepo".

This is awesome. Is there an email form where I can sign-up to get an alert when a new issue is released?

This is something I wish more effort was being put into. As more and more apps become V8-based, with each shipping completely separated, I wish there was some way to have them share resources. I know there are a lot of issues with this (different Node versions, possibly security, and figuring out inter-app resource sharing), but it would be magnificent for my computer's battery life. Does anyone know of any work being done on this front or a possible implementation?

Just a heads up to the Starfighter team browsing this thread: going to starfighter.io with uBlock Origin results in the job listings being blocked.

EDIT: it appears starfighter.io is different than starfighters.io.