F43 Change Proposal: Hare Programming Language (self-contained)

Project Discussion Change Proposals
,
1

Hare Programming Language

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

Summary

Introduce packages for Hare, a systems programming language designed to be simple, stable, and robust. Hare is still under development, the language, its standard library and its reference tool chain are still subject to breaking changes.

:link: Owner

:link: Detailed Description

Hare is a systems programming language designed to be simple, stable, and robust. Hare uses a static type system, manual memory management, and a minimal runtime. It is well-suited to writing operating systems, system tools, compilers, networking software, and other low-level, high performance tasks.

The Hare tool chain on Fedora will include:

  • hare (build driver)
  • harec (compiler front-end, already available in Fedora)
  • qbe (compiler back-end, already available in Fedora)
  • binutils (for assembly and static linking)
  • gcc (for dynamic linking, it also works with other C compilers)

Leaving binutils and GCC aside, bootstrapping a Hare tool chain only takes a few minutes. The Hare tool chain can target the x86_64, aarch64 and riscv64 architectures, and will be configured to rely by default on gcc-<arch>-linux-gnu and binutils-<arch>-linux-gnu for cross compilation.

The hare source package will produce the following packages:

  • hare (build driver, haredoc utility and manuals)
  • hare-stdlib (standard library)
  • hare-rpm-macros (packaging utilities)

In addition, a hare-update package will be provided to assist Hare developers deal with breaking changes when a new Hare release is available, until the language and its standard library become stable.

:link: Feedback

None.

:link: Benefit to Fedora

Developers can begin using the Hare language in their projects. Package maintainers can ship applications written in Hare.

Unlike other language tool chains, Hare modules are meant to be the responsibility of system package managers like DNF. Packaging Hare modules and applications should result in little friction.

:link: Scope

  • Proposal owners:

    • submit hare and hare-update packages for review
    • create RPM macros for Hare packaging
      • %hare_arches already submitted to redhat-rpm-config
    • handle the hare package bootstrap
    • add dependency generators for Hare modules
    • draft packaging guidelines

  • Other developers: N/A (not needed for this Change)

  • Release engineering: N/A (not needed for this Change)

  • Policies and guidelines:

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy: none

:link: Upgrade/compatibility impact

The Hare specification is still a draft, so the Hare language, tool chain and standard library are still subject to relatively frequent breaking changes. Package updates containing breaking changes should be limited to Fedora releases.

:link: How To Test

Once the hare package is available, the upstream [introduction An introduction to the Hare programming language] to the language walks you through the hello world below before covering language concepts.

Hello world:

$ cat >main.ha <<EOF use fmt; export fn main() void = { fmt::println(“Hello world!”)!; }; EOF $ hare build -o example main.ha 4/4 tasks completed (100%) $ ./example Hello world!

:link: User Experience

:link: Dependencies

None.

:link: Contingency Plan

  • Contingency mechanism: N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change)

:link: Documentation

:link: Release Notes

Last edited by @amoloney 2025-07-24T22:28:46Z

Last edited by @amoloney 2025-07-24T22:28:46Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

I’m concerned about the lack of apparent support for s390x and ppc64 (primary architectures in Fedora). I’m not aware of any other compiled language stack that we have in Fedora that lacks support for all of our primary architectures.

Is there any indication upstream that they intend to support ppc64le and s390x in the future, or are we potentially risking important packages adopting this language (which is apparently designed for very low-level system functionality, like C) and becoming unusable on two important architectures?

4

There’s another language with a similar target audience (compiled, modern, less strict than Rust) - zig - and it has very similar limitations: https://src.fedoraproject.org/rpms/zig/blob/rawhide/f/macros.zig#_1

5

There was mention of ppc64 [1] but to be frank I don’t know about the
progress or lack thereof. Hare is not backed by a huge team, so
compared to other languages ecosystems one could say it’s making slow
but steady progress. The main limiting factor for supported
architectures is the qbe compiler backend [2] and adding support for
the missing primary architectures would by far be the biggest leap
towards Hare support for these architecture. You’d then need to fill
some gaps with assembly in the standard library’s runtime, and
possibly a linker script.

Dridi

[1] Hare's path to a self-hosting toolchain
[2] QBE - Compiler Backend

6

This change proposal has now been submitted to FESCo with ticket #3461 for voting.

To find out more, please visit our Changes Policy documentation.