stefanchrobot's comments

Why not both? I want the language to provide an iterable/enumerable interface with the usual generic workhorses (map, reduce, etc.) and allow me to implement that interface as a free function for any type. If I'm authoring a type, I'll add specialized functions as needed.

Very satisfied with Elixir! I think it just fits my way of thinking. I love the terse, but explicit code, the VM, OTP, pattern matching, working with immutable data, integrated tooling, documentation support. The community is great, too.

The popular packages are top-notch, but as others have said - there might be issues finding what you need. My personal experience seems to be the opposite though - when going from Elixir to Ruby, it turned out that some of the gems were really, really far from perfect.

In terms of deployment, my take is that the community has finally figured it out. Elixir is a compiled language, so there is a build-time configuration and runtime configuration and I think it's best to keep the two separate, which is now well supported by the new runtime config (Elixir >= 1.11). Mix releases + runtime.exs + Docker works for me perfectly.

If you're coming from RoR, you'll be able to pick up Phoenix really quickly. It draws a pretty clear line between your web layer and your business/app layer though. Writing controllers and views should be similar, but I'd suggest spending some time on Ecto - it's quite different from ActiveRecord (in a good way, IMO).

One thing I'm missing in Elixir is optional static typing akin of TypeScript, but that's not coming anywhere soon. Other than that, no regrets.

I got introduced to Elixir in 2015 and was trying to work with it full-time since then. I was able to get a full-time Elixir job and I'm really happy about that. If you're looking for opportunities, I'd suggest attending ElixirConf or ElixirConf EU - last year I got 5 interesting job opportunities from ElixirConf EU alone (it was a virtual event, so the ticket was cheap).

Oh, wow. The language was complex already and this makes me avoid C++ unless it's constrained to a narrow subset (something like Google C++ Style Guide). No wonder languages like Go and Rust gain so much traction.

Erlang's VM comes to mind. It has great APIs for inspecting a running system and quite a few options for consuming that data: build-in observer [0], CLI version [1], web live dashboard [3] and more.

[0] https://erlang.org/doc/apps/observer/observer_ug.html

[1] https://github.com/zhongwencool/observer_cli

[2] https://github.com/phoenixframework/phoenix_live_dashboard

...or pattern matching in case of dynamically-typed languages:

  case some_operation() do
    {:ok, result} -> # do something with result
    {:error, error} -> # handle the error
  end

Similar tool that I currently use: https://github.com/watchexec/watchexec

I started to write the engine for my favourite game in my favourite programming language and the experience was addictive and enjoyable beyond compare. Sadly I just couldn't justify to myself the amount of hours that I would need to spend to complete this project.

I'm categorical only in terms of my personal preferences. Threading model is just hard, so in general, I'd suggest looking for alternatives. But that's not a universal advice as there are cases where it does not apply or the developers are up to the task of handling multiple threads.

A much better suggestion would be to look for a language/VM that supports a better concurrency primitives, like Elixir/Erlang. Obviously you can't run that everywhere, so sometimes you'd have to deal with threads. But after giving Ruby an honest shot at writing a backend system and hitting concurrency bugs (in an external gem), I'd rather avoid threaded programming model altogether.

Quite surprising take on the languages.

> When to use Python or Ruby

> Python and Ruby seem to me to be pretty similar in that they’re scripting languages and dynamically typed and seemed like the greatest thing in the 00’s. You use them when speed is more important than legibility or debugging.

I'd say you pick them when productivity and time to market is important. I personally find dynamic languages far more legible (unless you're doing metaprogramming-heavy stuff).

> Haskell or Erlang maybe I would use if I were doing something that required a very elegant or mathematical functional approach without a lot of business logic.

I think it's a mistake to throw these two into the same bag. I'd say Haskell is functional and comes from academia. Erlang is concurrent (with functional aspects) and comes from engineering background. You'd want to pick Erlang if you want to build scalable backend systems.

> my guidelines for JS are:

> Try to push as much logic as possible to the server. If the front end weren’t super complex, I would consider something like Phoenix instead which actually pushes everything to the server.

Phoenix is a web framework for Elixir and Elixir is a Ruby-like syntax on top of the amazing Erlang VM, so this kind of contradicts the suggestion above. Either way, Phoenix LiveView might be a game changer when it's applicable and for people who don't find the whole JS thing very exciting.

Well, you can't make everyone happy. Personally, I've started with the C family of languages (C, C++, C#, bit of Java), but after going through Python, Ruby and Elixir I never want to go back to curly braces. The other thing that puts me off is mixing types into the declarations - I treat types as comments and only reach for them if I need to dig deeper; in most of the cases the names of the arguments are self explanatory and types make it really hard for me to parse the function declaration. So instead of this:

  pub fn any(tree: Tree(a), check: fn(a) -> Bool) -> Bool

I'd really prefer something like this (preferably with a syntax highlighter that would grey out the types):

  fn(Tree(a), fn(a) -> Bool) -> Bool
  pub fn any(tree, check)

For some people, including myself, type annotations in Python are killing the spirit of the language. For me, there's no way to format those declarations to look reasonable, except for doing it like in Haskell or Elixir (@type).

Last year I did "Advent of Elixir" at my company with the puzzles from AoC. It was slow paced but I got some people excited about Elixir! I also followed José Valim on Twitch to see how he tackled those.

If you want to stay competitive, you've got to invest some time right before Christmas, so I gave up on that pretty quickly. Instead I did the puzzles at my on pace and spent some extra time playing with the puzzles that I found especially fun:

https://twitter.com/StefanChrobot/status/1080574491535781899

https://twitter.com/StefanChrobot/status/1078448111041892352

As a bonus, you get something to show whenever you're asked to share some code when applying for a job!

And then there's the learning factor - the puzzles are progressively more difficult, but I guess still doable for the average programmer. At some point some of them start to feel repetitive, but that's great if you get a good hold on processing data in your language of choice.

Somebody in our team put this on production. I guess this solution has some merits if you need something quick, but in the long run it turned out to be painful. It's basically SQL over REST. Additionally, your DB schema becomes your API schema and that either means you force one for the purposes of the other or you build DB views to fix that.

I'd love to see this implemented, especially that I already enjoy this feature a lot in Elixir/Erlang/BEAM.

I'd add one thing: avoid multiple classes on a single element; use mixins to avoid duplication. I tend to do so even for classes that have some toggle state, i.e. .some-class-active.

Thanks! Uninstalled straight away. I think the TOS issue is more important than the security one.

The job offers are not that often, so I guess you've beat everybody, myself included, with production experience.

Congrats on the new release! While this is all great news, it's still quite hard to get a full-time Elixir job outside of US. Kind of like staring at the candy shop display while it's closed. I'm wondering how to make this happen. I'm in a place where Elixir is just not going to happen and seems unreasonable to expect that I'll be able to convince people to switch to it right after joining a new place. Seems like the only option is to find spare time for playing with Elixir, but that proved to be difficult when I need to invested time in a different stack that actually helps me pay the bills.