4 ms·

still not easy at the most important thing of all: being approachable, instrumented and intuitive to people less dedicated to programming. I say this as someon

by gv83 3y ago

still not easy at the most important thing of all: being approachable, instrumented and intuitive to people less dedicated to programming. I say this as someone that likes elixir, but after seeing it failing miserably at my org, I'm very skeptical it can be thrown around like a spring or node or django project. It needs real support from the org and requires module design skills that are not present in most random devs from a random org.

pythonaut_16 3y ago
Could you expand on what you mean by this? Module design doesn't seem any harder than class design in JS or Python. Do you mean the language is generally harder for non-developers? Or that Elixir is harder for JS/Python developers to pick up and write good code? Or something else? Writing well designed Elixir code does seem to require a fairly different approach from most common OO languages, at least at a surface level. (Although IMO that's more because you can copy OO patterns you've seen before without thinking much about why they're good patterns than because good design in Elixir is much different from OO)
- catchnear4321 3y ago
  your last paragraph largely answers your questions. it doesn’t take much to yeet some python scripts (and more) at the wall and get something to stick. SO, GPT, pick your poison, it’s painfully easy. solved problems as far as the eye can see, with a little glue or tape to hold it together. elixir demands more of an investment. more than approximately zero is quite a bit if you already have momentum. (elixir can absolutely be yeeted. not arguing otherwise.)
  - throwawaymaths 3y ago
    Honestly long run elixir code by LLMs is going to be better because the llm won't have enough attention or context to be sure that mutable passes to functions don't absolutely wreck your data
- gv83 3y ago
  sure thing! I'll try to make points related to what I observed and experienced in my org, starting with one huge huge huge preamble which is: I work in an average org with average joe devs. an average joe dev to me is someone who "just wants a job" and is not very interested in furthering its own professional development or learning new things unless trained & forced by the job. it's perfectly fine to be an average dev, I understand I'm sounding like a snub but the difference is real, exists, it's tangible as I touch it every day. having said that, designing a proper elixir module (which basically is a bunch of functions that operates on a certain data structure usually represented by map of a certain shape) carries a certain level of fundamental understanding of the operation you're doing, which in my experience is one of the hardest things to get correctly. It also requires a different way of exploring code as you can't do the familiar `.` and see what happens, you can't just do `price.toCentsValue` but need to do `price |> Price.toCentsValue` and so you need to know the existence of the `Price` module, which might not exist and be buried in `Cart` or as an helper in some controller because you did not understand clearly the domain and the modules responsibilities. Attaching behaviour to data is powerful, explorable, and most people are used to it, even if it's the wrong place in principle, with modules this is flipped, it's now data that must thread through operations, and it's not super easy to grasp. Also, tooling is not that good (dialyzer sucks, intellij plugin not that good, vscode lsp good but still not a proper experience from people coming from c#/java, type annotations are not that readable...), pattern matching and destructuring on fn arguments confuses people and it's not super easy to read, and a million other papercuts related to tooling and syntax. We don't have many elixir codebases (let's say around 15-25%) and I've seen incessant whining about "we don't want to maintain elixir" simply because the majority of people cannot be bothered to learn another mountain of quirks and papercuts (every lang has them) plus also losing the familiar way of working they already have, and having to remember that for the spot ticket that appears once in a blue moon on jira for elixir. That's why I think elixir needs extra support from the organization, basically in mandating it to be the primary language, teaching people proper design + proper code navigation and structure techniques, etc. I hope I've been clear in my long winded ramblings; and I still wish a great future for elixir, so it becomes more approachable in average places like mine
  - suryong 3y ago
lvass 3y ago
On the other hand, it may filter less dedicated people from showing up at your door.
- gv83 3y ago
  this has been a point of contention with numerous hr departments that needs to hire fast "cuz investors!!11". this is the reality of life sadly
  - throwawaymaths 3y ago
    This is the real problem. Most orgs that fail on elixir fail due to management.
    - gv83 3y ago
      absolutely, that's what I said when I talked about strong org support. also, if you don't have strong org support, you risk getting onboard people that just want to work with that specific technology that WILL gtfo as soon as they need to change team to one that doesn't use it, or if the technology is sunset, etc., so it's even more risky to have an exotic stack in the middle of more common stacks
      - throwawaymaths 3y ago
        This is a problem, that needs to be fixed in tech management. Tech managers need to trust their dev talent. It's like a self fulfilling prophecy. Elixir is risky, so let's move off of it ==> devs leave. Elixir seems risky. And then the devs/ecosystem gets blamed.
        pythonaut_16 3y ago
        Also a risk of polyglot environments. You can easily end up with teams that lack deep knowledge of the languages and libraries you're using.
thibaut_barrere 3y ago
I do agree with the need to make it more approachable indeed. It is too much a "language of experts" at the moment, although it is not caused by the language itself, more by the topics covered in general.

by gv83 3y ago

pythonaut_16 3y ago

Could you expand on what you mean by this? Module design doesn't seem any harder than class design in JS or Python. Do you mean the language is generally harder for non-developers? Or that Elixir is harder for JS/Python developers to pick up and write good code? Or something else? Writing well designed Elixir code does seem to require a fairly different approach from most common OO languages, at least at a surface level. (Although IMO that's more because you can copy OO patterns you've seen before without thinking much about why they're good patterns than because good design in Elixir is much different from OO)

catchnear4321 3y ago
your last paragraph largely answers your questions. it doesn’t take much to yeet some python scripts (and more) at the wall and get something to stick. SO, GPT, pick your poison, it’s painfully easy. solved problems as far as the eye can see, with a little glue or tape to hold it together. elixir demands more of an investment. more than approximately zero is quite a bit if you already have momentum. (elixir can absolutely be yeeted. not arguing otherwise.)
- throwawaymaths 3y ago
  Honestly long run elixir code by LLMs is going to be better because the llm won't have enough attention or context to be sure that mutable passes to functions don't absolutely wreck your data
gv83 3y ago
sure thing! I'll try to make points related to what I observed and experienced in my org, starting with one huge huge huge preamble which is: I work in an average org with average joe devs. an average joe dev to me is someone who "just wants a job" and is not very interested in furthering its own professional development or learning new things unless trained & forced by the job. it's perfectly fine to be an average dev, I understand I'm sounding like a snub but the difference is real, exists, it's tangible as I touch it every day. having said that, designing a proper elixir module (which basically is a bunch of functions that operates on a certain data structure usually represented by map of a certain shape) carries a certain level of fundamental understanding of the operation you're doing, which in my experience is one of the hardest things to get correctly. It also requires a different way of exploring code as you can't do the familiar `.` and see what happens, you can't just do `price.toCentsValue` but need to do `price |> Price.toCentsValue` and so you need to know the existence of the `Price` module, which might not exist and be buried in `Cart` or as an helper in some controller because you did not understand clearly the domain and the modules responsibilities. Attaching behaviour to data is powerful, explorable, and most people are used to it, even if it's the wrong place in principle, with modules this is flipped, it's now data that must thread through operations, and it's not super easy to grasp. Also, tooling is not that good (dialyzer sucks, intellij plugin not that good, vscode lsp good but still not a proper experience from people coming from c#/java, type annotations are not that readable...), pattern matching and destructuring on fn arguments confuses people and it's not super easy to read, and a million other papercuts related to tooling and syntax. We don't have many elixir codebases (let's say around 15-25%) and I've seen incessant whining about "we don't want to maintain elixir" simply because the majority of people cannot be bothered to learn another mountain of quirks and papercuts (every lang has them) plus also losing the familiar way of working they already have, and having to remember that for the spot ticket that appears once in a blue moon on jira for elixir. That's why I think elixir needs extra support from the organization, basically in mandating it to be the primary language, teaching people proper design + proper code navigation and structure techniques, etc. I hope I've been clear in my long winded ramblings; and I still wish a great future for elixir, so it becomes more approachable in average places like mine
- suryong 3y ago

lvass 3y ago

On the other hand, it may filter less dedicated people from showing up at your door.

gv83 3y ago
this has been a point of contention with numerous hr departments that needs to hire fast "cuz investors!!11". this is the reality of life sadly
- throwawaymaths 3y ago
  This is the real problem. Most orgs that fail on elixir fail due to management.
  - gv83 3y ago
    absolutely, that's what I said when I talked about strong org support. also, if you don't have strong org support, you risk getting onboard people that just want to work with that specific technology that WILL gtfo as soon as they need to change team to one that doesn't use it, or if the technology is sunset, etc., so it's even more risky to have an exotic stack in the middle of more common stacks
    - throwawaymaths 3y ago
      This is a problem, that needs to be fixed in tech management. Tech managers need to trust their dev talent. It's like a self fulfilling prophecy. Elixir is risky, so let's move off of it ==> devs leave. Elixir seems risky. And then the devs/ecosystem gets blamed.
      - pythonaut_16 3y ago
        Also a risk of polyglot environments. You can easily end up with teams that lack deep knowledge of the languages and libraries you're using.

thibaut_barrere 3y ago

I do agree with the need to make it more approachable indeed. It is too much a "language of experts" at the moment, although it is not caused by the language itself, more by the topics covered in general.