It's one of the best talks I've ever watched! The first 10 minutes resonate so strongly with what I've been exploring recently. This guy just Gets It™️ (has quite the technical background too 😉).
Everything about this was so engaging and exciting. Really has me itching to look into it, years later.
The technical architecture is fascinating too! Seeing the supervision tree in action was really neat.
I was particularly happy to see him want to emulate some aspects of web development (and HTML), but gave himself room to innovate under well-defined constraints and goals.
And yet another reminder of the following wisdom: never bet against the BEAM 😁
Do you wish #Erlang had more #typesafety? Give #Gleam a try! A statically typed functional language, using the #Beam virtual machine, and compiles to either Erlang or JavaScript. Just hit version 1.0 at the start of March, so should be production ready. I don't write Erlang myself, but always interested in a JavaScript replacement.
Love seeing the value of "collapsing" the stack and how it can enable you in a variety of ways. Really reminds me to start looking into using the BEAM family more seriously when more time magically frees up :)
Congrats to the Elixir/BEAM community for making progress on their type system! Elixir was the first language that really gave me the sense I was in a community. In truth, I never built anything meaningful in Elixir, but I submitted my first 1-line open source PR in that community, and it still has a special place in my ♥︎. José leads in a way that brings out talent in everyone around him—it's great to watch.
Lasp-Lang was a project to develop a language for distributed, eventually-consistent computations (by Christopher Meiklejohn). It is an archived project now, but the Partisan sub-project (a membership and distribution layer for the #BEAM) is still active (now mainly supported by Leapsight).
We had looked into Partisan a couple of times for #VerneMQ but are currently not using it. https://github.com/lasp-lang/partisan #Erlang
Often, as engineers, we champion "the right tool for the job," yet we limit our knowledge of tools, intentionally or not. Please learn about Elixir/Erlang and decide if it's the right tool for the problems you face as an engineer--it's absolutely worth it!
@hrefna Are you building an actor system as in #Erlang actors? (If so wow, that sounds amazing!) Or are there actor-based concurrency implementations available in OCaml already?
I'm starting to explore the OCaml ecosystem and I'm fond of the #BEAM concurrency model, hence my curiosity :)
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.
@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
@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.
My bio highlights aspects of the kind of world I believe we should be building, but when I pop on here to post, it's not to organize but more so to be playful either about the finer programming languages (the #Lisp family and those that run on the #BEAM), #Emacs, or the implosion of the reactionary movement in #Brazil
I think something the scheme community could learn from Haskell is to lean-in on it's prestige. I see so many people post about how they were never able to figure out how to use scheme in any practical way, and most schemers I've spoke to said it took them about a year to get really compfortable. But I think the #scheme community has traditionally advertised it as "so easy, you can learn it in an afternoon!", and so people, often times already coming from some other #lisp like #clojure, expect to be able to just pick it up, and when they fail to they think the language is lacking. But nobody comes to #Haskell with such expectations, and the Haskell community never advertised it as super easy and quick to learn. In my experience, Haskell has always been sold as "takes time to learn, but is worth it".
@w96k@akater@ramin_hal9001 it's worth pointing out #LFE, lisp flavored Erlang, which might be the nicest Lisp 2 I've played with. Been meaning to find a project to do with it, been having some ideas for a kind of minimal + extensible #activitypub implementation where every user has a configuration file, but its still fuzzy.
My experiences with elixir have been pretty good. Its like python in the sense that you can figure out everything at the repl and can just jump into code and everything is obvious. And the beam is a great system. I have an old C++ programmer's allergy to the JVM, but the #beam is like a vintage spaceship from a more sophisticated age.