Stories with Tag Erlang

• Gleam, Coming from Erlang

  permalink

  Posted: 2025-02-25 07:54:00

  Verbose tl;dr

  The blog post "Gleam, Coming from Erlang" explores the author's experience transitioning from Erlang to Gleam, a newer language built on the Erlang Virtual Machine (BEAM). It highlights Gleam's similarities to Erlang, such as its functional nature, immutability, and the benefits of the BEAM ecosystem like concurrency and fault tolerance. However, the author emphasizes key differences, primarily Gleam's static typing, more approachable syntax inspired by Rust and Elm, and its focus on clearer error messages. While acknowledging some current limitations in tooling and library availability compared to Erlang's mature ecosystem, the post ultimately presents Gleam as a promising alternative for building robust, concurrent applications, particularly for developers coming from other statically-typed languages who might find Erlang's syntax challenging.

  This blog post, titled "Gleam, Coming from Erlang," explores the author's experience transitioning from Erlang to Gleam, a newer language designed to compile to Erlang. The author begins by highlighting their extensive background with Erlang and Elixir, emphasizing a deep appreciation for the Erlang virtual machine (BEAM) and its robust ecosystem. They praise Erlang's fault tolerance, concurrency model, and tooling, establishing these as key features they sought to retain when exploring alternative languages.

  The post then introduces Gleam, characterizing it as a statically-typed language that offers several advantages over Erlang while maintaining compatibility with the BEAM. The author systematically compares and contrasts Gleam with Erlang, focusing on key differences in syntax, type systems, and tooling.

  One significant difference highlighted is Gleam's static typing. The author explains how this contributes to enhanced code clarity, improved error detection during compilation, and better tooling support, like autocompletion and refactoring, compared to Erlang's dynamic typing. They elaborate on how Gleam's type system helps prevent common runtime errors, leading to more robust and maintainable code. Furthermore, they discuss the benefits of improved tooling afforded by static typing, which streamlines the development process.

  The post also details Gleam's syntax, describing it as being influenced by languages like Rust and Elm, which results in a more familiar and arguably more readable syntax for developers coming from those backgrounds. Specific examples are provided to illustrate how Gleam’s syntax differs from Erlang’s, showcasing its arguably cleaner and more concise nature.

  Crucially, the author underscores the interoperability between Gleam and Erlang. They explain how Gleam code can seamlessly integrate with existing Erlang libraries and projects, allowing developers to leverage the vast Erlang ecosystem. This interoperability is presented as a significant advantage, facilitating a gradual adoption of Gleam within existing Erlang projects. The ability to call Erlang code from Gleam and vice-versa is emphasized, allowing for a smooth transition and mixed codebases.

  Finally, the post concludes with the author's positive overall impression of Gleam. They reiterate the benefits of Gleam's static typing and modern syntax while preserving the advantages of the Erlang ecosystem. The author portrays Gleam as a viable option for both new projects targeting the BEAM and for incrementally modernizing existing Erlang projects. They suggest that Gleam offers a compelling blend of modern language features and the proven reliability of the Erlang VM, making it an attractive choice for developers seeking improved developer experience and code maintainability without sacrificing the benefits of the BEAM.

  • Gleam
  • Erlang
  • Functional Programming
  • Static Typing
  • concurrency
  • BEAM
  • compiler
  • Programming Languages
  • Software Development
  • Type Inference
  • Immutability

  Summary of Comments ( 57 )
  https://news.ycombinator.com/item?id=43169323

  Verbose tl;dr

  Hacker News commenters generally expressed interest in Gleam, praising its friendly syntax and the benefits it inherits from the Erlang ecosystem, like the BEAM VM. Some saw it as a potentially strong competitor to Elixir, appreciating its stricter type system and simpler tooling. A few users familiar with Erlang questioned the necessity of Gleam, suggesting that learning Erlang directly might be more worthwhile. Performance comparisons with Elixir and other BEAM languages were also a topic of discussion, with some expressing hope for benchmarks. A recurring sentiment was curiosity about Gleam's potential to attract a larger community and gain wider adoption. Several commenters also appreciated the author's candid comparison between Gleam and Erlang, finding the article helpful for understanding Gleam's niche.

  The Hacker News post titled "Gleam, Coming from Erlang" (https://news.ycombinator.com/item?id=43169323) has generated several comments discussing various aspects of Gleam and its relationship to Erlang.

  Several commenters discuss the benefits of Gleam's type system and its impact on developer experience. One user highlights how Gleam allows for compile-time verification of data structures, reducing runtime errors and enhancing overall code reliability, something they contrast positively with Erlang. Another commenter specifically appreciates the improvements Gleam offers in terms of error messages compared to Erlang, suggesting that this makes it a more approachable language for newcomers. The ability to refactor with greater confidence due to the type system is also mentioned as a significant advantage.

  The discussion also touches upon Gleam's performance characteristics. One commenter wonders about the performance implications of using Gleam compared to pure Erlang. While acknowledging they haven't benchmarked it themselves, they speculate that the overhead might be negligible, especially given that Gleam compiles to Erlang.

  Another thread in the comments focuses on the tooling and ecosystem surrounding Gleam. Users discuss the availability of a formatter and the integration with the Erlang ecosystem, noting that Gleam seamlessly leverages existing Erlang libraries. The relative nascency of the language and its ecosystem is acknowledged, with one user expressing anticipation for further tooling enhancements as the language matures.

  The choice of immutability as a core principle in Gleam is also a subject of discussion. A commenter notes that immutability simplifies reasoning about code, especially in concurrent scenarios, echoing the benefits often associated with functional programming paradigms.

  Finally, the topic of interoperability between Gleam and JavaScript is brought up. One commenter expresses their desire for improved JavaScript interop to facilitate wider adoption and use cases beyond the backend.

  In summary, the comments on Hacker News generally reflect a positive sentiment toward Gleam, praising its type system, Erlang integration, and the benefits it derives from functional programming principles. While acknowledging its relative youth, commenters express optimism about the future development and broader adoption of the language.

• Agent-Less System Monitoring with Elixir Broadway

  permalink

  Posted: 2025-02-18 14:53:44

  Verbose tl;dr

  This blog post demonstrates how to build an agent-less system monitoring tool using Elixir and Broadway. It leverages SSH to remotely execute commands on target machines, collecting metrics like CPU usage, memory consumption, and disk space. Broadway manages the concurrent execution of these commands across multiple hosts, providing scalability and fault tolerance. The collected data is then processed and displayed, offering a centralized overview of system performance. The author highlights the benefits of this approach, including simplified deployment (no agent installation required) and the inherent robustness of Elixir and its ecosystem. This method offers a lightweight yet powerful solution for monitoring server infrastructure.

  This blog post explores building a system monitoring solution using Elixir and Broadway, specifically focusing on an agent-less approach. The author argues that traditional agent-based monitoring, while offering granular data collection, introduces overhead and complexity through agent deployment and maintenance. Agent-less monitoring, leveraging protocols like SSH, offers a simplified alternative by querying systems directly without requiring resident software.

  The post begins by outlining the conceptual architecture of their solution. It details how Broadway, a concurrent and fault-tolerant processing library in Elixir, acts as the central processing engine. It receives monitoring tasks, distributes them to designated workers, and manages the results. Crucially, the chosen agent-less method utilizes SSH to execute commands remotely on target systems. The post emphasizes Broadway's robustness in handling potentially unreliable network operations inherent in SSH-based communication.

  The author then delves into the implementation specifics. They demonstrate setting up a Broadway pipeline configured to process monitoring tasks. These tasks are structured as messages containing the target hostname and the command to execute. The implementation leverages Erlang's SSH application to establish connections and execute commands remotely. A critical component highlighted is the error handling mechanism built around Broadway's retry and failure handling capabilities. This ensures resilience against transient network issues or temporary unavailability of target systems. The retrieved monitoring data is then processed and formatted, ready for storage or visualization.

  A key advantage emphasized is the flexibility afforded by this approach. The system can be readily extended to support various monitoring commands and metrics. Adding new systems to monitor only requires configuring the necessary connection details, without deploying any agents. The post also touches upon the scalability of the solution. Broadway's concurrent processing model allows for parallel execution of monitoring tasks, improving efficiency and reducing overall monitoring time. The author acknowledges potential security considerations associated with managing SSH credentials and advocates for secure storage and access control mechanisms.

  Finally, the post concludes by reiterating the benefits of the agent-less approach, highlighting its simplicity, scalability, and reduced overhead. It positions this approach as a compelling alternative to traditional agent-based solutions, especially in scenarios where agent deployment is impractical or undesirable. The author suggests potential future enhancements, such as integrating with different data visualization tools and exploring alternative agent-less protocols.

  • Elixir
  • Broadway
  • System Monitoring
  • Agentless Monitoring
  • Observability
  • DevOps
  • distributed systems
  • Erlang
  • OTP
  • concurrency
  • fault tolerance
  • scalability
  • performance monitoring
  • Real-Time Monitoring

  Summary of Comments ( 16 )
  https://news.ycombinator.com/item?id=43090167

  Verbose tl;dr

  Hacker News users discussed the practicality and benefits of the agentless approach to system monitoring described in the linked blog post. Several commenters appreciated the simplicity and reduced overhead of not needing to install agents on monitored machines. Some raised concerns about potential security implications of running commands remotely via SSH and the potential performance bottlenecks of doing so. Others questioned the scalability of this method, particularly for large numbers of monitored systems. The discussion also touched on alternative approaches like using message queues and the potential benefits of Elixir's concurrency features for this type of monitoring system. A compelling comment suggested exploring the use of OSquery for efficient data gathering, which prompted further discussion on its pros and cons. Finally, some commenters expressed interest in the author's open-sourcing of their project.

  The Hacker News post titled "Agent-Less System Monitoring with Elixir Broadway" sparked a small but focused discussion with 5 comments. No single comment overwhelmingly dominated the conversation, but several offered interesting perspectives on the article's topic.

  One commenter questioned the term "agent-less," pointing out that while the system described doesn't require installing dedicated agent software on monitored machines, it still relies on SSH access, which functionally acts like an agent. They argued that this approach trades one set of tradeoffs (agent installation and maintenance) for another (managing SSH keys and potential security concerns).

  Another comment focused on the choice of Erlang/Elixir for this type of task. They acknowledged the platform's strengths in concurrency and distributed systems but expressed concern about the operational overhead and debugging complexity compared to simpler scripting solutions, especially for smaller deployments. They suggested that the benefits of Elixir might become more pronounced with larger and more complex monitoring setups.

  A third commenter praised the article's clear explanation and the elegant approach to building a robust monitoring system with Broadway. They highlighted the benefits of leveraging Elixir's OTP framework for handling failures and ensuring reliability.

  The remaining comments were shorter and less substantive. One simply expressed appreciation for the article, while another briefly mentioned using a similar approach with a different technology.

  Overall, the comments section, while brief, provided some thoughtful critiques and perspectives on the advantages and disadvantages of the proposed agent-less monitoring approach using Elixir and Broadway. The discussion centered on the practical implications of SSH as an "agent" substitute and the suitability of Elixir/OTP for this kind of task in different scales of deployment.