in terms of industry programming languages that any programmer can hit the ground running with little to no ramp up, #elixir does the best job imo. I never used ruby, but its all so obvious you can just get to work. and for distributed systems that need to scale in a flexible way, the #beam eliminates nearly everything that makes webapp development horrible. it's hard to make a good argument for any other industrial virtual machine. #commonlisp implementations being the exception.
Howdy, I’m not an Elixir dev, and I’m not here to tear down anyone’s favorite stack. There are lots of good reasons to choose any different toolset. But, I wouldn’t use developer startup time as a core metric in choosing a technology. A bike can out accelerate a car for the first 20 yards, and I bet the car will out-accelerate an airplane off the starting line. But their initial speed, final speed, and distance traveled are all wildly different. @rml
@benpate I wouldn't consider myself an Elixir dev either, I'm only using it at work atm and have on some short term contract work as well, but I do all my personal work in Scheme. but employers seem to think its very important, and it seems to be a major factor in python's massive success.
but the major attraction of elixir is of course the BEAM, which is an excellent technology that is the only production VM designed for fault-tolerance, and of course Phoenix Liveview and the rest of it's ecosystem.
what would be your choice for large commercial web app that needs to be flexible and scale instead?
I did a big survey a few years ago, narrowed it down to #Golang and Rust, and ultimately chose Go. The focus on “building at scale” was especially appealing for me, because many aspects of the language encourage high quality code that others can pick up and maintain in the future. It limits new developers who are used to typical OOP environments, but the missing features in Go help prevent newbie mistakes that come back to bite you on the future. @rml
@benpate
what would you use on the front end? thats one area where I think elixir makes a hard to beat case, using a single language for the whole stack with few dependencies is ideal, and folks who haven't worked in a holistic programming environment are really at a loss for what their missing.
but in terms of maintainability, and scalability, Go seems to me a poor choice. that it's not object oriented is of course good. but it's not functional, which drastically reduces composability, which I believe is essential to scalable software. go's CSP is good, but I'd argue that #clojure's is better (especially at the code maintainability level), and better than CSP outright is concurrentML, for example #guile's fibers. the addition of generics is of course good, but focusing on type parameterization and not providing generic dispatch leaves a lot to be desired in regards to designing flexible systems. that it doesn't provide pattern matching is a major bummer, not only for the sake of composability and maintainability, but also because Go is an "internet language"; being able to rapidly implement packet parsers as binary pattern matchers such as with #beam languages and many lisps is a massively underrated feature that shines in protocol programming, but also anywhere you need to get into the weeds.
for nearly anything that doesn't require a fancy modern-browser front end, if I could I would choose a scheme implementation, usually Chez smaller, which compiles faster & usually to smaller static binaries, is more extensible, and is a top choice whether you're writing a compiler, an operating system, daily scripting ala bash, or just about anything else where a fancy GUI system isn't a primary concern.
All great points 😀 For the front end, I’ve fallen in love with #HTMX, which lets me use plain old HTML templates as a “SPA” alternative. I’ve used Go to make JSON/REST APIs for Angular but the duplication of work seemed like a giant waste of time So now I let web servers be web servers, and browsers be browsers. Letting go of (most) front-end JS was a huge leap forward in all the important metrics — productivity, scalability, and sanity. @rml
@benpate yeah totally. if you ever have an idea for a weekend web app that you want to be slick & throw together quickly without much hassell (something like an activity pub textboard), I'd recommend giving Phoenix Liveview a try to check out its capabilities. More going on than HTMX, but it also makes things that are such a pain in the ass everywhere else simple, and you'll write probably less than half the code than if you did the same in HTMX + Go
of course, #LFE is the ideal distributed programming language, it just needs a major framework for people to deliver web apps with. if someone has a lot of time or some money that they want to turn into more money, investing in a framework that fully supports #phoenix + #liveview[1] in LFE could be the beginning of a #clojure-scale enterprise
@askonomm@dsp clojure is definitely a nice #lisp, but I personally prefer LFE, which sticks closer to the lisp tradition. but in terms of value, it's really JVM vs. BEAM ecosystems imo. if you haven't checked out Phoenix Liveview, it's a really impressive Model-View-Controller framework that allows you to create beautiful SPAs without any #js and is famous for providing Figma-style "multiplayer" out of the box, because it can handle millions of websocket connects at once, diffing the DOM and only updating the diffed regions, which practically eliminates the most common issues of jank in contemporary responsive webapps. fun features fall out of the bottom of this model, like being able to run your server's shell as a website and use it anywhere.
also there is nerves, the embedded #elixir project, where they are doing stuff like this: https://farm.bot/
and tons of other cool projects and frameworks as well
@rml@dsp I personally prefer HTMx and server-side Clojure these days for building most tools unless I have to work on a SPA (such as at work), but the big value-add in Clojure for me is that I can do C#, Java, JS, Node.js, Shell scripting (Babashka) and even Flutter (ClojureDart) with the same language.
In any case, I don't work on anything near as performance critical to need millions of websockets, but I've meaning to check out Elixir for a while, so will learn of BEAM then!
@askonomm@dsp yeah, once the Flutter support has matured a bit I look forward to digging in, because I can't think of another lisp that offers modern gui support.
but I think maybe "a million websocket connections" was the wrong way to put it. its more that the way erlang is treats processes as in a sense its fundamental datatype (like a cons cell), along with the "let it crash" approach to fault-tolerant programming, means that you're able to program proper browser UI without all the jank caused by javascript frameworks like React. It just seems like you can keep building continuously and everything works, if you throw it at the beam the beam just handles it.
@askonomm@rml i suppose having BEAM (the erlang runtime) gives you all the goodies of erlang. Namely allowing you to write on the happy path of the code and deal with problems in the actors via well defined operations (restart via supervisors etc). I had found this article to be useful : https://medium.com/@vamsimokari/erlang-let-it-crash-philosophy-53486d2a6da
@dsp@askonomm also the BEAM is just cool. I personally don't find the JVM very interesting as a subject matter to study, but #BEAM + #OTP is infinitely interesting, it's a proper spaceship
@rml Technically, you could just write your frontend nodes in Phoenix/Elixir and have your backend nodes in LFE. Alternatively you could also just boot your LFE backend into your Phoenix frontend node as a dependency.
I agree however that writing native frontend nodes in LFE has advantages.
Add comment