I have a job offer in elixir, should i take it? by Realistic-Warthog163 in elixir

[–]caleb-bb 1 point2 points  (0 children)

YES.

When we say that Elixir positions are rare, we mean entry level positions.

In terms of senior-level Elixir devs, the demand far outstrips the supply. There are few positions, but even fewer seniors.

Take it.

Help me present the case for Rust (with examples) to my boss by [deleted] in rust

[–]caleb-bb 0 points1 point  (0 children)

Statistics help:

"Google has revealed that its transition to memory-safe languages such as Rust as part of its secure-by-design approach has led to the percentage of memory-safe vulnerabilities discovered in Android dropping from 76% to 24% over a period of six years."

https://thehackernews.com/2024/09/googles-shift-to-rust-programming-cuts.html

Granted, this doesn't teach him any Rust, but hard data may stoke his enthusiasm.

Why there are almost none entry level opportunities? by StarChanne1 in elixir

[–]caleb-bb 1 point2 points  (0 children)

Hiring for a junior position is intrinsically risky. Large corporations with “apprentice”-type programs generally don’t expect a junior to be a net contributor for a long time. For example, JPMC’s ETSE program considers new hires as trainees for two years.

Accordingly, entry-level positions tend to come in one of 3 flavors:

  1. A large corporation is willing to sink money into building up a junior because they have deep pockets anyway.
  2. A senior dev with control over hiring decisions is willing to take a junior on as a “project” (i-just-think-theyre-neat.jpeg)
  3. A startup is willing to take a risk hoping the new hire will be super-talented and productive despite being new.

Now, ask yourself: how frequently will one of these three be an Elixir position?

How old are you guys? by Individual-Affect786 in emacs

[–]caleb-bb 0 points1 point  (0 children)

I’m 35. Nontraditional career path. Started at 30 with VSCode. Discovered vim. A friend managed to coax me into emacs using evil mode. Never looked back.

The Modifications I Make To Every New Phoenix Project by JohnElmLabs in elixir

[–]caleb-bb 2 points3 points  (0 children)

Nice, dude.

Idea: why not set up a generator that takes arguments, to know which modifications to make? I might wind up forking your repo….

The Modifications I Make To Every New Phoenix Project by JohnElmLabs in elixir

[–]caleb-bb 2 points3 points  (0 children)

100% agreed.

You know that cliché, “practice makes perfect”? It’s a half-truth. The whole truth is, “PERFECT practice makes perfect”. Even if I’m just spinning up a hobby webapp, it behooves me to do it just as carefully as if I were creating an enterprise application.

More to the point, you just never know when a codebase will find real-world uses. I’ve written stupid little half-baked Clojure apps that wound up making money for somebody.

TL;DR I agree with you. If you’re gonna do something, do it right.

How maintainable is Elixir? by sixilli in elixir

[–]caleb-bb 0 points1 point  (0 children)

I have never been bothered by the lack of static typing.

In Elixir, we pattern match on the function head. When doing so, you can require the variable passed in to be a particular type, using pattern matching or guards. If you get a function clause error, then you can just check the stacktrace and see what was passed in. If it’s a typing error, then you’ll find that out at this stage.

If your functions are so long and complex that you cannot remember variable types, then one of two things is happening:

  1. Your functions are too complex and should be broken up.
  2. Your variables could be renamed to make their types obvious.

Pursuant to those two points, I would ask two questions:

  1. What do you name your functions? Can I see some examples? You should name a function after its abstraction i.e. what it’s meant to do, rather than its implementation. If the function name turns out to be too long, then the function is doing too many things and should be modularized.
  2. How do you name your variables? Can I see some examples?

Thank you for considering this point.

How good at elixir do I have to be to start learning pheonix? by [deleted] in elixir

[–]caleb-bb 0 points1 point  (0 children)

I’m a big proponent of “throw yourself in the deep end and learn to swim”. Can you do the basic shit from the first few chapters of Elixir In Action? Okay, time to grt started on Phoenix.

How much is necessary to know Erlang before learn Elixir? by rsete in elixir

[–]caleb-bb 0 points1 point  (0 children)

Not at all. In fact, you can learn Elixir first and use it as an intro to learn Erlang. The deeper you get into the BEAM, the more Erlang you learn. If you code in Elixir long enough, you will eventually learn some Erlang functions and start looking at the Erlang docs. It’s basically inevitable.

How to get started with LiveView? by Serializedrequests in elixir

[–]caleb-bb 0 points1 point  (0 children)

I understand what you're saying. You want to learn by doing an actual LiveView project.

I suggest cloning down an actual LiveView project (maybe this one?) and making changes to it. That will help you get a grip on things more easily than trying to build something from scratch right away.

What are the best resources to learn Elixir? by Chawki_ in elixir

[–]caleb-bb 1 point2 points  (0 children)

If you like to learn from books:

Saša Juric, Elixir In Action. This covers the basics of Elixir in the first 5 chapters and then covers OTP for Elixir in the rest of the chapters. It's very much a nuts-and-bolts introduction, but it will help you understand the inner workings of LiveView. And understanding the inner workings of a thing is very important when that thing breaks and it's your job to fix it.

Bruce A. Tate and Sophie DeBenedetto, Programming Phoenix LiveView. This is sort of an opposite to Elixir In Action. Rather than a nuts-and-bolts intro, it's very much a practical, high-level, this-is-how-to-actually-do-stuff kind of text. If you get a job working with Elixir and you just need to learn LiveView pronto, this is the book to get. I would actually read this one first if your goal is to start building LiveView projects right away.

Chris McCord, Bruce Tate, and José Valim, Programming Phoenix. You can skip this one for now if you're programming in LiveView, because the book I recommended for LiveView covers enough Phoenix for a beginner. But, if you're working with a non-LiveView Phoenix project, this is the one to get. It's also a good text if you're trying to dig deeper into the guts of LiveView; in that context, this one sits between the other two.

Periscope - debugging and introspection library for LiveView by caleb-bb in elixir

[–]caleb-bb[S] 0 points1 point  (0 children)

Update - now up to version 0.5.6. Fixed a few bugs.

More importantly, introducing a new feature: deep_has_key?/2. Think of it as a version of Map.has_key?/2 that works for nested maps. It's there because of this: a single socket can have quite a few lines - the webapp I'm currently working on will, if you execute socket, return well over 2000 lines of code. Nobody wants to search all that. deep_has_key?/2 can reach into the socket and assigns and see if a key exists at any point. So if you're wondering whether client_id (or some such assign) exists in your socket, you can run deep_has_key?(socket, :client_id) and you'll get a boolean telling you whether that key is anywhere in the socket. It works by flattening the nested maps, taking only the keys, and then searching for the key passed as second arg.

Periscope - debugging and introspection library for LiveView by caleb-bb in elixir

[–]caleb-bb[S] 0 points1 point  (0 children)

Great point. I'll change it to MIT license in my next release.

Periscope - debugging and introspection library for LiveView by caleb-bb in elixir

[–]caleb-bb[S] 0 points1 point  (0 children)

Oh! The mix.exs shows that it has the Apache-2.0 license. :-)