Show HN: Kedr Programming Language
codeberg.orgKedr is a programming language for games, primarily deriving from F# and Rust. Its approach is to create a game with automatic reference counting, and then switch impactful types to manual memory management one by one. Below are some of my findings.
We are used to having imports at the beginning of every file, but it might be better to keep them all in one place for the entire crate. This way code can be moved freely between files, and smaller files are encouraged. To open a file and immediately see useful code is also refreshing.
It is highly beneficial when braces always mean closure. A strong argument for the indent-based code structure.
Object tree creation looks more natural without parentheses and commas for function invocation.
Sequential code enforcement, when elements can only depend on what is defined above, opens new possibilities. One is splitting the type constructor among multiple files, potentially located in different crates. An example of how this is useful. One crate contains UI control definitions with layout code, while additional crates extend control types with data and calculations, necessary for their rendering, resulting in multiple switchable backends, like Vulkan or Skia. Maintaining such data outside complicates the code.
There is a tendency to move away from type hierarchies. I think it is better to tune them down and reevaluate. A major source of complexity is the ability to override existing implementation of a method, because a code is being added to a type without a guarantee on whether it is going to stay. Such a guarantee will make hierarchies worth keeping more often.
What useful features does it have? What has it specifically for game development?
Games require a high-productivity and high-performance language without a garbage collector. Kedr achieves this by having reference counting that can be switched off for any particular type separately. Otherwise you either have to manage memory manually, or suffer potentially unacceptable performance losses. I wouldn't even consider languages with GC, as too much attention goes into not allocating temporary objects.