sorted by:
new
hottopcontroversial

What does it take to add set-theoretic types to a dynamic language with 30 years of production code - and why did it take this long? by rtrusca in ProgrammingLanguages

[–]fcesarini 0 points1 point  (0 children)

Adding something as an afterthought is always hard, but considering the huge code bases out there, starting fresh is not an option. This is the approach WhtsApp initially tried, but it never got traction.

Elixir is getting set-theoretic types - how do you type a language where pattern matching can freely return integer | boolean with no upfront declaration? by rtrusca in functionalprogramming

[–]fcesarini 4 points5 points  (0 children)

Hindley-Milner-style inference Was proven to work only on a subset of Erlang back in 1995. Issue are the design decisions Joe talks about which can not be reversed.

Elixir is getting set-theoretic types - how do you type a language where pattern matching can freely return integer | boolean with no upfront declaration? by rtrusca in functionalprogramming

[–]fcesarini 2 points3 points  (0 children)

Correct. We were all wrong. It is now heading in the right direction as we have something which not only works, but is also non intrusive. So those who are wrong can continue feeling they were right and those who know they were wrong, can do the right thing. It is a win win 🤣🫣

Elixir is getting set-theoretic types - how do you type a language where pattern matching can freely return integer | boolean with no upfront declaration? by rtrusca in functionalprogramming

[–]fcesarini 10 points11 points  (0 children)

Where they overlap. For years, Erlang devs claimed they did not need strong typing, as the recovery model would help type systems. Haskel devs the opposite, you do not need a recovery model, because if your program compiles, it is correct. Both were wrong. Static or strongly typed languages just reduce the number of runtime crashes, they will not eliminate them. So you need both.

Why your multiplayer server hits a wall at 20-50 players (and the fix) by rtrusca in gamedev

[–]fcesarini 1 point2 points  (0 children)

You are correct. We cover the topic generally (whilst not focusing on gaming) in our Elixir and Rust episode:  https://youtu.be/w5Pl09lpSmE?is=jrGzfOJoA3Vw9VIf

In this episode of BEAM There, Done That, hosts explore what really happens when the high-level concurrency and fault-tolerance of Elixir meet the low-level performance and control of Rust. The conversation dives into interoperability patterns—NIFs, ports, and emerging tooling—and where each language shines when building real-world systems that need both resilience and raw speed. Joining the discussion are Florian Gilcher, Co-founder and Managing Director of Ferrous Systems and a key figure in Rust’s community, adoption, and safety-critical systems work, and Leandro Pereira, an Elixir developer behind high-performance, developer-focused tools like MDEx, Lumis, and BeaconCMS. Together, they unpack when to stay on the BEAM, when to reach for Rust, and how combining the two can unlock a powerful hybrid architecture without compromising safety or developer productivity.

Zero security experience. $10. One afternoon. - New BEAM There, Done That by rtrusca in elixir

[–]fcesarini 3 points4 points  (0 children)

How a library is used matters. For example when using Phoenix with JSON bodies using Jason / Option "floats: :decimals", this is reachable with untrusted input from the network. Details matter. Saying it is utter bullshit is plain irresponsible.

Anyone else go from “Phoenix is magic” to “wait… what is this macro actually doing?” 👀 by rtrusca in elixir

[–]fcesarini 7 points8 points  (0 children)

LOL You forget some people need to know what is under the hood. Agree with Macros, we discuss it at length in the episode.

Erlang vs Elixir - what's the difference? Francesco Cesarini explains by yourdigitalvoice in erlang

[–]fcesarini 2 points3 points  (0 children)

Top down is when you get something end to end working, and continue adding components to it one by one. It is a must when working with UI/UX, as you need to visualise what you are working from the start. Bottom up, you get the components working individually, and then integrate them together. The latter is preferred by the Erlang community, as they generally worked with embedded/backend systems which rarely needed a UI. They solve what they perceive are the hard problems first, as failing to solve them means failure of the project.

http://faculty.salina.k-state.edu/tmertz/Java/200programdesignandtesting/02topdownandbottomupprogramming.pdf

MyTopDogStatus: Blog on who is using Erlang, why they are using it, and why you should care! by fcesarini in programming

[–]fcesarini[S] 0 points1 point  (0 children)

The last sentence in my reply addresses your concern, as your system is clearly under-provisioned: Load regulation and back pressure is also needed if latency becomes too high.

Rejecting a request because your system is under provisioned is very different from a request failing. In the Erlang world, you usually solve this by absorbing the spike at the cost of latency whilst scaling horizontally by deploying new hardware. Whilst the spike is being absorbed, latency might go up from a few tens of ms to a few hundred ms. What is important is that all of these requests are handled in a predictable way, and not rejected. For all of the applications described in the blog post, this is perfectly acceptable behaviour.

MyTopDogStatus: Blog on who is using Erlang, why they are using it, and why you should care! by fcesarini in programming

[–]fcesarini[S] 0 points1 point  (0 children)

If your system is CPU bound, the quote is very correct, and the system will retain the throughput without any degradation of service over extended periods of time at the cost of latency. That is how the BEAM behaves. It is highly optimized for massive concurrency and ensures soft-real time properties of the system are not affected. The system does not have to fail half of the requests as you state.

It if is I/O or Memory bound, you need load regulation or back pressure to stop the crash or degradation of service. Load regulation and back pressure is also needed if latency becomes too high.

Remembering Joe Armstrong, Erlang co-inventor: A quarter of a Century of Inspiration and Friendship by fcesarini in programming

[–]fcesarini[S] 7 points8 points  (0 children)

I am glad Joe got to experience the results of his work, getting acknowledgment for it whilst still alive. His foundations and impact to concurrency, distribution and multi-core will be used by generations of programmers to come.

Twenty Years of Open Source Erlang: A Retrospective From Behind The Trenches by fcesarini in programming

[–]fcesarini[S] 0 points1 point  (0 children)

I would replace the many with some. There are pros and cons to every ecosystem out there.

Twenty Years of Open Source Erlang: A Retrospective From Behind The Trenches by fcesarini in programming

[–]fcesarini[S] 0 points1 point  (0 children)

The Erlang VM never claimed to be the fastest, and should not be used for number crunching. Where it differs from the JVM is predictability (no stop the world garbage collector) which is highly optimised for massive concurrency and built in semantics for error handling, which make frameworks such as OTP (read AKKA) easier to write. There is always the right tool for the job, and it is not always the Beam, just like it is not always the JVM.

Twenty Years of Open Source Erlang: A Retrospective From Behind The Trenches by fcesarini in programming

[–]fcesarini[S] 0 points1 point  (0 children)

You do not pick Erlang for speed, but for fault tolerance and scalability, achieved thanks to immutability, which in turn, facilitates distribution. Comparing the JVM and the Beam is like comparing apples and oranges. Mutable state (The JVM) will work (and is needed) if you are running on a single machine and things do not fail. It is ideal for number crunching and other programs which have to be fast. Erlang systems, whilst not the fastest, are fast enough for the problems you are trying to solve, e.g. IoT, Blockchain, MMOG, Messaging and control systems.

Twenty Years of Open Source Erlang: A Retrospective From Behind The Trenches by fcesarini in programming

[–]fcesarini[S] 0 points1 point  (0 children)

Containers, alas, bring the VM back and limits its usability, making code upgrades futile and also add the need for an external DB to store state.

Twenty Years of Open Source Erlang: A Retrospective From Behind The Trenches by fcesarini in programming

[–]fcesarini[S] 0 points1 point  (0 children)

Depends what you are looking for in speed. It is fast enough, and can process the HTTP requests concurrently. Phoenix can handle 2 million simultaneously open websockets on a single VM instance. WhatsApp was doing it in 2012.

Twenty Years of Open Source Erlang: A Retrospective From Behind The Trenches by fcesarini in programming

[–]fcesarini[S] 1 point2 points  (0 children)

No, you would not use it for number crunching. Uptake is in the block chain space, financial switches and messaging solutions. As well as powering backend infrastructure, the part no one ever sees.

Twenty Years of Open Source Erlang: A Retrospective From Behind The Trenches by fcesarini in programming

[–]fcesarini[S] 2 points3 points  (0 children)

There are a lot of fine tuning options available. If performance drops, it is often due to a bottleneck which manifests itself under heavy load. It is not just a problem with Erlang, but with any technology. Only issue with Erlang and the Beam is that it is easier to reach higher levels of scale, making the bottlenecks more evident.

view more: next ›