The author seeks a C-like language with modern features like generics, modules, and memory safety, while maintaining C's performance and close-to-the-metal nature. They desire a language suitable for systems programming, potentially as a replacement for C in performance-critical applications, but with the added benefits of contemporary language design. They are exploring if such a language already exists or whether retrofitting C would be a more viable approach. Essentially, they want the power and control of C without its inherent pitfalls and limitations.
The Hacker News post titled "Ask HN: A retrofitted C dialect?" poses a question to the community regarding the potential for and interest in a modernized C dialect. The author expresses a desire for a language that retains the core strengths and philosophies of C, specifically its performance characteristics, low-level control, and predictable behavior. They are seeking a language that would offer improvements in areas where C is known to be deficient or cumbersome, such as memory management. Specifically, the author mentions a desire for automated memory management, possibly through mechanisms like garbage collection or borrow checking, while acknowledging the potential performance impact such features might introduce.
The author emphasizes the importance of maintaining compatibility with existing C codebases, suggesting that this hypothetical dialect should allow seamless integration with C libraries and potentially even allow the gradual migration of existing C projects to the new dialect. They highlight the current landscape of systems programming languages, noting the existence of alternatives like Rust and Go, but express a preference for a language that adheres more closely to the spirit and syntax of C. The post concludes with an open-ended inquiry, inviting discussion and feedback on the feasibility and desirability of such a language, and asking for opinions on existing projects that may already be attempting to address this need. They are particularly interested in approaches that focus on practical application and minimize theoretical complexity.
Summary of Comments ( 16 )
https://news.ycombinator.com/item?id=43137171
The Hacker News comments discuss the practicality and potential benefits of a "retrofitted" C dialect, primarily focusing on memory safety. Some suggest exploring existing options like Zig, Rust, or Odin, which already address many of C's shortcomings. Others express skepticism about the feasibility of such a project, citing the complexity of C's ecosystem and the difficulty of maintaining compatibility while introducing significant changes. A few commenters propose specific improvements, such as optional garbage collection or stricter type checking, but acknowledge the challenges in implementation and adoption. There's a general agreement that memory safety is crucial, but opinions diverge on whether a new dialect or focusing on tooling and better practices within existing C is the best approach. Some also discuss the potential benefits for embedded systems, where C remains dominant.
The Hacker News post "Ask HN: A retrofitted C dialect?" sparked a discussion with several interesting comments. The original poster was inquiring about the feasibility and potential benefits of creating a C dialect that incorporates modern language features while maintaining compatibility with existing C codebases.
Several commenters pointed out existing projects that attempt to address similar goals. One commenter mentioned Zig, highlighting its focus on being a simpler and more predictable systems programming language compared to C. They emphasized Zig's compile-time execution capabilities and how they can be used to generate optimized code. Another commenter brought up Beef, a language that transpiles to C, emphasizing its goal of adding higher-level features to C development. C2 was also mentioned as a language attempting to improve on C while remaining close to its core principles.
A common theme in the discussion revolved around the complexities and potential pitfalls of trying to "fix" C. One commenter argued that many of the perceived problems with C stem from programmers misusing the language rather than inherent flaws in the language itself. They suggested that focusing on better education and tooling might be a more effective approach than creating a new dialect.
Another commenter questioned the practical benefits of a retrofitted C dialect, arguing that the effort required to create and maintain such a language might outweigh the advantages gained. They also pointed out the challenges of ensuring compatibility with the vast existing C ecosystem.
Some commenters discussed specific features they would like to see in a modernized C dialect, such as improved memory management, better error handling, and more robust type safety. The discussion also touched upon the trade-offs between performance and safety, with some arguing that C's performance characteristics are a key reason for its continued relevance.
Overall, the comments reflect a mix of enthusiasm for the potential of a modernized C dialect and skepticism about its practicality. Several existing projects were highlighted as potential solutions, and the discussion explored various technical challenges and design considerations related to creating such a language.