191–198 of 198 posts
Earlier quoted context omitted.
Ocaml, F#, probably others.
Thanks!
Earlier quoted context omitted.
I think this article does capture the magic of elixir phoenix live view that is impossible in the async await madness hell in python. I cannot wait to try elixir Phoenix live view, elixir |> pipes, :atom pattern matching and ets pids to send and manage processes across servers none of these AFAIK are currently possible with the GIL and single threaded nature of python As the venerable prof Joe armstrong would say you…
You can pattern match on basically any shape, not just atoms. Imagine you’re parsing a protocol over tcp and want to grab groups of characters between deliverers, you can pattern match that. I rewrote an hl7 parser from Java to Ruby to Elixr some years ago and the elixir implementation performed as well as Java and was more readable by miles.
Earlier quoted context omitted.
I love Django. I just think Python without types makes things hard at scale.
MyPy and friends have made this much, much better. In the long term it's probably not ideal for very large systems in many applications.
Earlier quoted context omitted.
> LiveView can’t handle spotty connections, I thought? LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored. You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot. If you have a very complex client-side need, it's also pretty…
>> LiveView handles it just fine. If the websocket disconnects for some reason it will automatically re-establish itself when the connection is restored. What the parent means is that, because state is kept on the server with LiveView, and events that change that state are processed by the server, if your connection is lost, then you may find that even basic things, such as having a dialog open when you click a butto…
> You can also use the built-in JS module to do client-side things when you don't need backend support. I use Alpine.js (PETAL stack) and I like it a lot.
If you have a very complex client-side need, it's also pretty easy to use React.js for that.
While you could, I never use LiveView to open dialogs (unless the dialog state needs to be distributed across multiple clients, but I haven't had that use case come up yet). As you mention, that would lead to a poor UX.
The best is the best of both worlds. LiveView for data/state changes that need to go to the database, client-side script for state changes that are UI related and don't get persisted.
Earlier quoted context omitted.
This is absolutely not true, because most of the industry uses Python for web services and serving web pages is still the same thing as it was 20 years ago. You scale by bringing in more processes. Multicore concurrency is still a pet use case because high performance is still a minority of applications and async programming is not necessarily faster, per many benchmarks. Most companies will rewrite the high-performa…
>> Most companies will rewrite the high-performance component in the proper manner and continue to do everything else the way they did. they do and when they need it is not in python or asyncio wonder why it is usually in cpp,java,erlang,elixir,haskell ?
Earlier quoted context omitted.
>> Most companies will rewrite the high-performance component in the proper manner and continue to do everything else the way they did. they do and when they need it is not in python or asyncio wonder why it is usually in cpp,java,erlang,elixir,haskell ?
Nobody's writing production Haskell or Erlang for this save maybe a half-dozen companies; it's all C++ or Java, and it represents a very small minority of the code as critical paths are usually tiny slivers of a codebase.
Earlier quoted context omitted.
I absolutely feel you have grounds for being self-congratulatory. But the linked article, and much of the discussion here, is really about persuading more people to adopt Elixir. Essentially people are being asked to tie a period of their professional career to the fortunes of a technology. Most of us code for money ... we have families to support etc. This is where a language becoming a "major player" becomes releva…
> Niche technologies can leave you somewhat trapped in your current job ... and the people negotiating salaries and raises for employers will inevitably exploit this. I don't think the relationship is that simplistic. On [StackOverflow Survey for 2022][0], the top salaries were for Clojure, Erlang, F#, LISP and Ruby. Elixir comes in 6th and Python comes in 25th. Choosing a niche technology may be a way to increase yo…
Hopefully that project continues to make progress, I'm looking forward to it for Android development.
No offense to TFA author, but I don't think this is doing to sell Elixir to Python people. In fact, I have serious doubts as to whether most Python lovers would be willing to set aside their beliefs and practices to learn the Elixir way. Perhaps Phoenix and LiveView will be the gateway drug, but even to reach that point requires a lot of effort to understand functional programming and Elixir. Python has some function…
I say this to say that it's worth the effort to at least expose people to new languages. It doesn't hurt anyone, and if other's aren't interested, they simply will not move to the new language. Others though might be pleasantly surprised to find out what other languages have to offer.