software development trends

In this episode of Elixir Wizards, hosts Owen and Dan are joined by René Föhring, creator of Credo for Elixir, and Marc-André LaFortune, head maintainer of the RuboCop AST library for Ruby. They compare static code analysis in Ruby versus Elixir. The conversation explores the intricacies and challenges inherent in static code analysis across object-oriented and functional programming paradigms, highlighting the unique characteristics of both Ruby and Elixir. Key topics of discussion include the ways these tools can enhance coding styles and empower developers, the delicate balance between providing guidance and enforcing rules, and the evolving future of code analysis in these languages. Topics discussed in this episode: The differences and applications between static and dynamic analysis How Credo aims to offer flexible and educational guidance for Elixir developers The complexities of method identification in Ruby and its impact on static analysis Challenges posed by macros and dynamic code modification during compilation in Elixir Reducing false positives in code analysis tools to minimize developer frustration Promoting uniform coding practices through analysis tools The significance of using analysis tools with clear, specific objectives How coding standards can refine and improve coding styles over time Building analysis tools and checks through an understanding of Abstract Syntax Trees (ASTs) Potential advancements in the analysis of Phoenix templates and HTML in Elixir Contrasting approaches to managing code and comments in Elixir and Ruby ASTs The fine line between providing helpful guidance and imposing stylistic preferences Heuristics in static analysis highlight inconsistencies without mandating style The potential for more straightforward pattern matching in ASTs with future updates The importance of a gradual implementation of tool updates to maintain backward compatibility Creating tools that support and empower developers, rather than hinder them How static analysis contributes to cleaner, more maintainable codebases Potential future developments in the field of static code analysis Practical applications of using linters like Credo and RuboCop in software development Links mentioned in this episode: Credo https://github.com/rrrene/credo https://hexdocs.pm/credo/overview.html Dogma: A code style linter for Elixir https://github.com/lpil/dogma https://github.com/rubocop/rubocop RuboCop's AST extensions and NodePattern functionality https://github.com/rubocop/rubocop-ast https://github.com/whitequark/parser https://hex.pm/packages?search=credo&sort=recentdownloads https://github.com/doorgan/sourceror https://github.com/rrrene/credo/blob/master/lib/credo/check/readability/largenumbers.ex Special Guests: Marc-André Lafortune and René Föhring.

Today on Elixir Wizards, Manuel Rubio, author of Erlang/OTP: A Concurrent World and Dan Plyukhin, creator of the UIGC Actor Garbage Collector for Akka, join host Dan Ivovich to compare notes on garbage collection in actor models. The discussion digs into the similarities and differences of actor-based garbage collection in Erlang and Akka and introduces Dan's research on how to perform garbage collection in a distributed actor system. Topics discussed: Akka is akin to Erlang actors for the JVM using Scala, with similar principles like supervision trees, messages, and clustering Erlang uses generational garbage collection and periodically copies live data to the old heap for long-lived elements Actor GC aims to determine when an actor's memory can be reclaimed automatically rather than manually killing actors Distributed actor GC is more challenging than object GC due to the distributed nature and relationships between actors across nodes Challenges include reasoning about failures like dropped messages and crashed nodes GC balance requires optimization of resource release and CPU load management Immutability helps Erlang GC, but copying data for messages impacts performance Research into distributed actor GC is still ongoing, with opportunities for improvement Fault tolerance in Erlang relies on user implementation rather than low-level guarantees Asynchronous messages in Erlang/Elixir mean references may become invalid which is similar to the distributed GC approaches in Dan's research Idempotent messaging is recommended to handle possible duplicates from failures Help your local researcher! Researchers encourage communication from practitioners on challenges and use cases Links mentioned: Erlang/OTP Volume 1: A Concurrent World by Manuel Rubio https://altenwald.com/en/book/en-erlang-i  Scala https://www.scala-lang.org/  Akka Framework https://github.com/akka  JVM (Java Virtual Machine) https://www.java.com/en/download/  The BEAM VM https://www.erlang.org/blog/a-brief-beam-primer/ Hadoop Framework https://hadoop.apache.org/   Pony Programming Language https://www.ponylang.io/  SLSA Programming Language https://wcl.cs.rpi.edu/salsa/#:~:text=SALSA%20 Paxos Algorithm https://en.wikipedia.org/wiki/Paxos(computerscience)  Raft library for maintaining a replicated state machine https://github.com/etcd-io/raft  Dan's Website https://dplyukhin.github.io/  Dan Plyukhin on Twitter: https://twitter.com/dplyukhin  Dan Plyukhin’s YouTube channel: https://m.youtube.com/@dplyukhin UIGC on GitHub https://github.com/dplyukhin/UIGC  Manuel's Website https://altenwald.com/  Manuel Rubio on Twitter: https://twitter.com/MRonErlang Special Guests: Dan Plyukhin and Manuel Rubio.