As one commentor pointed out, in Arch it's the user's responsibility to review any AUR packages BEFORE installing them (and I say this as an Arch user and AUR package maintainer).
This particular issue is with a binary (i.e. pre-built) package, normally in Arch it's expected from an AUR package that you will build it yourself and most if not all packagers prompt you to review and or edit the PKGBUILD before it does anything.
Basically you could spot something suspicious in a source package, not so much in a binary package.
I think the most exciting part is the new documentation format, as someone who primarily works in elixir, I do reference the erlang standard library every now and then so an easier and familiar documentation format is welcomed.
I just hope that "h :ets" works in iex later (for those who don't know, it shows the help/module/function documentation of the value specified)
For the email validation I would have used an ecto schema, since most cases you won't just be validating an email address in isolation:
defmodule EmailSchema do
use Ecto.Schema
import Ecto.Changeset
@primary_key false
embedded_schema do
# here is your type validation right off the bat
field :email, :string
end
def validate(email) do
%__MODULE__{}
|> cast(params, [
:email,
])
|> validate_required([
:email,
])
|> validate_change(:email, fn :email, value ->
cond do
not is_email_address?(value) ->
[email: {"invalid email address", [validation: :email]}]
not EmailAddresses.is_available?(value) ->
[email: {"is unavailable", [validation: :email]}]
true ->
[]
end
end)
|> apply_action(:insert)
end
end
case EmailSchema.validate(email) do
{:ok, %{email: email}} ->
{:error, %Ecto.Changeset{} = changeset} ->
changeset.errors[:email]
# Can be all of these in the same list, or be any one depending on the validations
#=> [{"is required", [validation: :required]}]
#=> [{"invalid email address", [validation: :email]}]
#=> [{"is unavailable", [validation: :email]}]
end
For work?
Elixir!
I particularly enjoy writing tests in elixir compared to any other language so far.
Most code is transparent so you can always peek under the hood to see what it's doing, maybe copy a few ideas for your own use.
Package management is rather straight forward.
The console access in production has been a godsend to execute one off scripts or running export tasks, diagnostics or other bits.
For personal projects?
Ruby and Elixir, though ruby's documentation has fallen off of shape as of late, that or Elixir's has spoiled me by setting higher bar
I see you mentioned RoR, you can try Phoenix in its place for Elixir.
+1 phoenix/elixir is such a joy to use. A big emphasis on developer happiness, extremely powerful (with a broader set of strengths than Rails imo), and the actor model is much easier for me to reason/think about because it cleanly separates logic and is designed to fail and recover cleanly.
What are those, in your experience? The BEAM platform is certainly better for concurrent work where you might be holding open something like a web socket. But other stuff...? I'm a pretty happy Erlang programmer and feel like I 'get' the functional programming aspect of things, but to me ActiveRecord just feels like such a great fit for DB work in that it makes the simple things really easy and intuitive, lets you do some more complex stuff, and gets out of your way if you just want to go to SQL. I don't have too much experience with Ecto. It feels like it "does the job", but is maybe not quite so quick and intuitive for basic/simple stuff like AR.
Having worked with both ActiveRecord and Ecto, Ecto is consistently easier to reason about and change than AR. It feels closer to the DB without compromising composability, and better avoids surprises. Ecto is IMO one of the killer features of the Elixir ecosystem that is undercelebrated compared to the neat things that are rarely used.
Do you have any concrete examples that you're thinking of?
In particular, I found that having to include all the fields is kind of a PITA compared to AR. I also just find the mental model of an AR object to be really easy to think about in terms of the simple cases. Before save, after save, accessors, and just having methods available on the object all seem really intuitive compared to changesets. Not that I didn't figure those out in short order, they just seemed a bit clumsier. But I am not super deep into Ecto, either, so maybe I'm missing some places where it shines.
It's hard to beat Rails for "need to make a CRUD app in front of a DB". Phoenix is pretty close, though.
Where it really shines is anything beyond CRUD. I want to make my CRUD apps more dynamic, and build collaboration features into otherwise boring apps. LiveView makes it wickedly simple to do things like typeahead find: https://twitter.com/mrkurt/status/1434969788275691522
And Elixir + BEAM gives me reasonable plumbing for collaboration features. Even something as simple as presence makes CRUD apps more powerful.
So the broader set of Phoenix strengths aren't ActiveRecord vs Ecto. Phoenix helps me build a more powerful app because it has a broader set of strengths. And it's almost as good at Rails for just CRUD, so I don't give up much to get those features.
This particular issue is with a binary (i.e. pre-built) package, normally in Arch it's expected from an AUR package that you will build it yourself and most if not all packagers prompt you to review and or edit the PKGBUILD before it does anything.
Basically you could spot something suspicious in a source package, not so much in a binary package.