0.60.6

Add Alpine 3.23 support

We've added support for Alpine 3.23. Builds will be available for both arm64 and amd64.

Fix crash when ephemeral type used in parameter with default argument

We've fixed an error where attempting to assign an ephemeral type to a variable caused an assertion failure in the compiler.

The following code will now cause the pony compiler to emit a helpful error message:

class Foo

actor Main
  fun apply(x: Foo iso^ = Foo) => None

  new create(env: Env) => None

Error:
main.pony:4:16: invalid parameter type for a parameter with a default argument: Foo iso^
  fun apply(x: Foo iso^ = Foo) => None
               ^

Update Docker Image Base to Alpine 3.23

We've updated the base image for our ponyc images from Alpine 3.21 to Alpine 3.23.

Fix incorrect array element type inference for union types

Due to a small bug in the type system implementation, the following correct code would fail to compile. We have fixed this bug so it will now compiler.

type Foo is (Bar box | Baz box | Bool)

class Bar
  embed _items: Array[Foo] = _items.create()

  new create(items: ReadSeq[Foo]) =>
    for item in items.values() do
      _items.push(item)
    end

class Baz

actor Main
  new create(env: Env) =>
    let bar = Bar([
      true
      Bar([ false ])
    ])
    env.out.print("done")

Fix segfault when lambda captures uninitialized field

Previously, the following illegal code would successfully compile, but produce a segfault on execution.

class Foo
  let n: USize

  new create(n': USize) =>
    n = n'

class Bar
  let _foo: Foo
  let lazy: {(): USize} = {() => _foo.n }

  new create() =>
    _foo = Foo(123)

actor Main
  let _bar: Bar = Bar

  new create(env: Env) =>
    env.out.print(_bar.lazy().string())

Now it correctly refuses to compile with an appropriate error message.

Error:
main.pony:9:34: can't use an undefined variable in an expression
  let lazy: {(): USize} = {() => _foo.n }
                                 ^

Fix compiler crash when assigning ephemeral capability types

Assigning ephemeral capability to a variable was causing the compiler to crash. We've updated to provide a descriptive error message.

Where previously code like:

actor Main
  new create(env: Env) => 
    let c: String iso^ = String

caused a segfault, you will now get a helpful error message instead:

Error:
/tmp/main.pony:3:24: Invalid type for field of assignment: String iso^
    let c: String iso^ = String

[0.60.6] - 2026-02-06

Fixed

• Fix crash when ephemeral type used in parameter with default argument (PR #4796)
• Fix incorrect array element type inference for union types (PR #4794)
• Fix segfault when lambda captures uninitialized field (PR #4791)
• Fix compiler crash when assigning to ephemeral capability type (PR #4790)

Added

• Add Alpine 3.23 support (PR #4803)

Changed

• Update Docker Image Base to Alpine 3.23 (PR #4804)

0.60.5

Add Pony Language Server to the Ponyc distribution

We've moved the Pony Language Server that previously was distributed as it's own project to the standard ponyc distribution. This means that the language server will track changes in ponyc. Going forward, the language server that ships with a given ponyc will be fully up-to-date with the compiler and most importantly, it's version of the standard library.

Handle Bool with exhaustive match

Previously, this function would fail to compile, as true and false were not seen as exhaustive, resulting in the match block exiting and the function attempting to return None.

  fun fourty_two(err: Bool): USize =>
    match err
    | true => return 50
    | false => return 42
    end

We have modified the compiler to recognize that if we have clauses for both true and false, that the match is exhaustive.

Consequently, you can expect the following to now fail to compile with unreachable code:

  fun forty_three(err: Bool): USize =>
    match err
    | true => return 50
    | false => return 43
    else
      return 44 // Unreachable
    end

Fix ponyc crash when partially applying constructors

We've fixed a compilation assertion error that would result in a compiler crash when utilizing partial constructors.

Previously, this would fail to compile:

class A
  let n: USize

  new create(n': USize) =>
    n = n'

actor Main
  new create(env: Env) =>
    let ctor = A~create(2)
    let a: A = ctor()

Add support for complex type formatting in LSP hover

The Pony Language Server now properly formats complex types in hover information. Previously, hovering over variables with union types, tuple types, intersection types, or arrow types would display internal token names like TK_UNIONTYPE instead of the actual type signature.

Now, the language server correctly displays formatted types such as:

• Union types: (String | U32 | None)
• Tuple types: (String, U32, Bool)
• Intersection types: (ReadSeq[U8] & Hashable)
• Arrow types: function signatures

Add hover support for generic types in LSP

The LSP server now provides hover information for generic types, including type parameters, type arguments, and capabilities.

Hover displays:

• Type parameters on classes and traits (e.g., class Container[T: Any val])
• Type parameters on methods (e.g., fun map[U: Any val](f: {(T): U} val): U)
• Type arguments in instantiated types (e.g., let items: Array[String val] ref)
• Capabilities on all types (val, ref, box, iso, trn, tag)
• Nested generic types (e.g., Array[Array[String val] ref] ref)
• Viewpoint adaptation/arrow types (e.g., fun compare(that: box->T): I32)
• Constructor calls with type arguments (e.g., GenericPair[String, U32](...))

When hovering on variable declarations, the full inferred type is now shown including all generic type arguments and capabilities, making it easier to understand the exact types in your code.

Add extra hover support to LSP

The Pony Language Server Protocol (LSP) implementation now provides improved hover capabilities with the following fixes.

Hover on field usages

When hovering over a field reference like field_name in the expression field_name.size(), the LSP now displays:

let field_name: String val

class Example
  let field_name: String

  fun get_length(): USize =>
    field_name.size()  // Hovering over 'field_name' here shows: let field_name: String val

Previously, hovering over field usages did not show any information.

Hover on local variable usages

When hovering over a local variable reference like count in the expression count + 1, the LSP now displays:

var count: U32 val

fun increment(): U32 =>
  var count: U32 = 0
  count = count + 1  // Hovering over 'count' here shows: var count: U32 val
  count

Previously, hovering over variable usages did not show type information.

Hover on parameter usages

When hovering over a parameter reference like name in the expression name.size(), the LSP now displays:

param name: String val

fun get_name_length(name: String): USize =>
  name.size()  // Hovering over 'name' here shows: param name: String val

Previously, hovering over parameter usages did not show any information.

Hover on parameter declarations

When hovering over a parameter declaration like x: U32 in a function signature, the LSP now displays:

param x: U32 val

fun calculate(x: U32, y: U32): U32 =>
  // Hovering over 'x' in the signature shows: param x: U32 val
  x + y

Previously, hovering over parameter declarations provided no information.

Hover on method calls

When hovering over a method name in a call expression like my_object.get_value(42), the LSP now correctly highlights only the method name and displays:

fun get_value(x: U32): String val

class MyObject
  fun get_value(x: U32): String val =>
    x.string()

actor Main
  new create(env: Env) =>
    let my_object = MyObject
    let result = my_object.get_value(42)  // Hovering over 'get_value' highlights only the method name

Previously, both the method name and receiver name were highlighted.

Fix crash when using bare integer literals in array match patterns

Array does not implement the Equatable interface, which queries for structural equality. Previous to this fix, an error in the type inference logic resulted in the code below resulting in a compiler crash instead of the expected helpful error message:

actor Main
  new create(env: Env) =>
    let arr: Array[U8 val] = [4; 5]
    match arr
    | [2; 3] => None
    else
      None
    end

Now, the correct helpful error message is provided:

Error:
main.pony:5:7: couldn't find 'eq' in 'Array'
    | [2; 3] => None
      ^
Error:
main.pony:5:7: this pattern element doesn't support structural equality
    | [2; 3] => None
      ^

Add support for go to definition for arrow types in LSP

The LSP server now correctly handles "go to definition" for method calls on arrow types (viewpoint-adapted types like this->Type).

Previously, go-to-definition would fail on method calls where the receiver had an arrow type, such as calling methods on this (which has type this->MyClass rather than just MyClass).

Add hover support for receiver capability to LSP

The Language Server Protocol (LSP) hover feature now displays receiver capabilities in method signatures.

When hovering over a method reference, the hover information will now show the receiver capability (e.g., box, val, ref, iso, trn, tag) in the method signature. This provides more complete type information at a glance.

Examples

Previously, hovering over a method would show:

fun boxed_method(): String

Now, it correctly displays:

fun box boxed_method(): String

This applies to all receiver capabilities:

• fun box method() - read-only access
• fun ref method() - mutable reference access
• fun val method() - immutable value access
• fun iso method() - isolated reference access
• fun trn method() - transition reference access
• fun tag method() - opaque reference access

[0.60.5] - 2026-01-31

Fixed

• Fix crash when partially applying constructors (PR #4783)
• Fix crash when using bare integer literals in array match patterns (PR #4797)

Added

• Add Pony Language Server to the ponyc distribution (PR #4777)
• Handle Bool with exhaustive match (PR #4782)
• Add support for complex type formatting in LSP hover (PR #4785)
• Add hover support for generic types in LSP (PR #4793)
• Add extra hover support to LSP (PR #4795)
• Add hover support for receiver capability to LSP (PR #4798)
• Add support for go to definition for arrow types in LSP (PR #4792)

0.60.4

Add Alpine 3.22 as a supported platform

We've added arm64 and amd64 builds for Alpine Linux 3.22. We'll be building ponyc releases for it until it stops receiving security updates in 2027. At that point, we'll stop building releases for it.

Stop creating Fedora 41 builds

We are no longer creating Fedora 41 builds of Pony. Fedora 41 is about to reach its end of life. If you need Pony support on Fedora 41, you will need to build from source.

[0.60.4] - 2025-10-31

Added

• Add Alpine 3.22 as a supported platform (PR #4760)

Changed

• Stop creating Fedora 41 builds (PR #4763)

0.60.3

Stop building versioned "-alpine" images

We used to release images for ponyc like ponyc:0.38.0-alpine that were based on Alpine Linux.However, we now just have those as ponyc:0.38.0 as we don't have any glibc based images anymore.

Stop Creating Generic musl Builds

We previously created releases for a generic "musl" build of ponyc. This was done to provide a build that would run on any Linux distribution that used musl as its C standard library. However, these could easily break if the OS they were built on changed.

We now provide specific Alpine version builds instead.

Stop Creating "alpine" Docker Image

We previously were creating Docker images with a musl C standard library Ponyc under the tag alpine. We are no longer creating those images. You should switch to our new equivalent images tagged nightly.

Add Multiplatform Versioned Release Docker Images

We've added multiplatform versioned release Docker images for Ponyc. These images are built for both amd64 and arm64 architectures and are tagged with the current Ponyc version. For example, ponyc:0.60.3.

Previously, the versioned release images were only available for the amd64 architecture.

nightly and release tags were already avaialble as multiplatform images. This update extends that support to versioned images as well. With this change, we now provide consistent multiplatform support across all our Docker image tags.

[0.60.3] - 2025-10-20

Added

• Add Multiplatform Versioned Release Docker Images (PR #4754)

Changed

• Stop building -alpine versioned container images (PR #4751)
• Stop Creating Generic musl Builds (PR #4752)
• Stop Creating "Alpine" Docker Images (PR #4753)

0.60.2

Add Multiplatform Release Docker Images

We've added new release images with support multiple architectures. The images support both arm64 and amd64. The images will be available with the tag release. They will be available for GitHub Container Registry the same as our other ponyc images.

The images are based on Alpine 3.21. Every few months, we will be updating the base image to a newer version of Alpine Linux. At the moment, we generally add support for new Alpine version about 2 times a year.

Note, at this time, the release images that are tagged with the release version like 0.60.2 are still only amd64. Multiplatform images tagged with the version will be coming soon.

[0.60.2] - 2025-10-18

Changed

• Add Multiplatform Release Docker Images (PR #4749)

0.60.1

Fix Arm64 Linux Releases

Our configuration for releasing on Arm64 Linux was incorrect, leading to failed releases. This has been fixed, and we will now be able to successfully release on Arm64 Linux.

[0.60.1] - 2025-10-15

Fixed

• Fix Arm64 Linux Releases ([#4748])(#4748)

0.60.0

Drop Ubuntu 20.04 support

Ubuntu 20.04 has reached its end of life date. We've dropped it as a supported platform. That means, we no longer test against it when doing CI and we no longer create prebuilt binaries for installation via ponyup for Ubuntu 20.04.

We will maintain best effort to keep Ubuntu 20.04 continuing to work for anyone who wants to use it and builds ponyc from source.

Don't set ld.gold as the default Linux linker

Previously, we were setting ld.gold as our default linker on Linux. If you wanted to use a different linker, you had to override it using the ponyc option --link-ldcmd.

ld.gold was contributed to the GNU project many years ago by Google. Over the years, Google has moved away from supporting it and to investing in LLVM and other tools. ld.gold has no active maintainers at this point in time and has been removed from the most recent version of binutils.

It is no longer reasonable going forward to set gold as the default Linux linker as many Linux distributions will not have it easily available. We have switched to using the default Linux linker on the given system. On most systems, that is ld.bfd unless it has been configured otherwise. If you would like to use a different linker you can do the following as part of ponyc command line:

Use gold:

• ponyc --link-ldcmd=gold

Use mold:

• ponyc --link-ldcmd=mold

Alpine 3.20 added as a supported platform

We've added Alpine 3.20 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2026. At that point, we'll stop building releases for it.

Alpine 3.21 added as a supported platform

We've added Alpine 3.21 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2026. At that point, we'll stop building releases for it.

Ubuntu 24.04 on arm64 added as a supported platform

We've added Ubuntu 24.04 on arm64 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2029. At that point, we'll stop building releases for it.

Alpine 3.21 on arm64 added as a supported platform

We've added Alpine 3.21 on arm64 as a supported platform. We'll be building ponyc releases for it until it stops receiving security updates in 2026. At that point, we'll stop building releases for it.

Update to LLVM 18.1.8

We've updated the LLVM version used to build Pony to 18.1.8.

Support building ponyc natively on arm64 Windows

We've added support for building Pony for arm64 Windows.

Arm64 Windows added as a supported platform

We've added arm64 Windows as a supported platform. Builds for it are available in Cloudsmith. Corral and ponyup support will be coming soon.

Make finding Visual Studio more robust

Ponyc will now ignore applications other than Visual Studio itself which use the Visual Studio installation system (e.g. SQL Server Management Studio) when looking for link.exe.

Fix linking on Linux arm64 when using musl libc

On arm64-based Linux systems using musl libc, program linking could fail due to missing libgcc symbols. We've now added linking against libgcc on all arm-based Linux systems to resolve this issue.

Update nightly Pony musl Docker image to Alpine 3.21

We've updated our ponylang/ponyc:alpine image to be based on Alpine 3.21. Previously, we were using Alpine 3.20 as the base. The release images are still based on Alpine 3.20 for now.

Stop building Windows container images

We've stopped building Windows container images as of Pony 0.60.0. As far as we know, the Windows images were not being used. We've simplified our CI by removing them.

Stop building glibc based ponyc images

We have stopped building nightly and release ponyc Docker images that are based on glibc. The glibc based images that we were building were based on an ever changing version of Ubuntu (most recent LTS release). These images had minimal utility.

They could only be used to link for Linux distros that had the same libraries installed as the build environment. Whereas the musl images could be used to statically link using musl and create binaries that could be used on any Linux.

Given the lack of utility for a wide variety of people, we have stopped building the glibc based images and will only have a single nightly and release image going forward. Those images will be using musl via Alpine Linux.

If you were using the glibc based images, we can point you to the Dockerfiles we were using as they are quite straightfoward and should be easy for anyone to incorporate the creation of into their own CI process. You can find the Dockerfiles in the pull request that removed them.

Add Multiplatform Nightly Docker Images

We've added new nightly images with support multiple architectures. The images support both arm64 and amd64. The images will be available with the tag nightly. They will be available for GitHub Container Registry the same as our other ponyc images.

The images are based on Alpine 3.21. Every few months, we will be updating the base image to a newer version of Alpine Linux. At the moment, we generally add support for new Alpine version about 2 times a year.

We will be dropping the alpine tag in favor of the new nightly tag. However, that isn't happening now but will in the not so distant future. You should switch any usage you have of those tags to nightly now to avoid disruption later.

[0.60.0] - 2025-10-15

Fixed

• Make the check for Visual Studio more robust (PR #4722)
• Fix linking on Linux arm64 when using musl libc (PR #4726)

Added

• Add Alpine 3.20 as a supported platform (PR #4709)
• Add Alpine 3.21 as a supported platform (PR #4710)
• Add Ubuntu 24.04 on arm64 as a supported platform (PR #4714)
• Add Alpine 3.21 on arm64 as a supported platform (PR #4716)
• Support building ponyc natively on arm64 Windows machines (PR #4689)
• Add arm64 Windows as a supported platform (PR #4721)
• Add Multiplatform Nightly Docker Image (PR #4731)

Changed

• Drop Ubuntu 20.04 Support (PR #4693)
• Don't set gold as the default ponyc linker on Linux (PR #4704)
• Update to LLVM 18.1.8 (PR #4701)
• Update Pony nightly musl Docker image to Alpine 3.21 (PR #4745)
• Stop building Windows container images (PR #4746)
• Stop building glibc based ponyc images (PR #4747)

0.59.0

Add ability to trace runtime events in chromium json format #4649

We have added the ability to trace runtime events for pony applications. Runtime tracing is helpful in understanding how the runtime works and for debugging issues with the runtime.

The tracing can either write to file in the background or work in a "flight recorder" mode where events are stored into in memory circular buffers and written to stderr in case of abnormal program behavior (SIGILL, SIGSEGV, SIGBUS, etc).

Traces are written in chromium json format and trace files can be viewed with the perfetto trace viewer.

Links:
Chromium json format
perfetto trace viewer

Prevent memory explosion when using ponynoblock in some programs

We have enhanced the runtime to prevent memory explosion in some programs when --ponynnoblock is used.

The following is an example of such a program:

use "collections"
use "random"
use "time"

class Notify is TimerNotify
  let _a: A
  var _m: Main

  new iso create(a: A, m: Main) =>
    _a = a
    _m = m

  fun ref apply(timer: Timer, count: U64): Bool =>
    _a.done(_m)

    // returning false from apply in a TimerNotify
    // instructs the runtime that the timer should be
    // cancelled which allows for the owning Timers
    // actor to potentially be reaped if there are no
    // references to it and/or if the cycle detector
    // decides it is safe to be reaped
    false

actor A
  // acquires a reference to the Main actor via an ORCA
  // message to prevent the Main actor from being reaped
  // until after this actor is done with the reference to
  // it. This reference will be released the next time GC
  // runs for this actor since this actor doesn't keep a
  // reference to it
  new create(m: Main, n: USize) =>
    // acquires a reference to the Timers actor implicitly
    // because this actor creates it. The reference will
    // be freed after the next GC of this actor since this
    // actor doesn't keep a reference to it
    let timers = Timers

    // passing a reference to the Main and A actors via the
    // Notify class delays/prevents them from being reaped
    // until after the references are no longer used either
    // because the Notify object is destroyed or the Timers
    // actor is reaped
    let timer = Timer(Notify(this, m), n.u64() * 1_000_000)
    timers(consume timer)

  // acquires a reference to the Main actor via an ORCA
  // message (if the previous reference has already been
  // released) to prevent the Main actor from being reaped
  // until after this actor is done with the reference to
  // it. This reference will be released the next time GC
  // runs for this actor since this actor doesn't keep a
  // reference to it
  // After this behavior completes, this actor can
  // potentially be reaped if there are no references to it
  // and/or if the cycle detector decides it is safe to be
  // reaped
  be done(m: Main) =>
    m.done(this)

actor Main
  let n: USize = 100000
  var e: USize = 0
  let max_num_oustanding: USize = 13
  var num_outstanding: USize = 0
  let s: SetIs[A] = s.create()
  let rand: Random

  new create(env: Env) =>
    let t = Time.seconds()
    rand = Rand(t.u64())
    spawn()

  be spawn() =>
    if e < n then
      while num_outstanding < max_num_oustanding do
        let i = rand.int[USize](2)

        // passing a reference to the Main actor
        // delays/prevents it from being reaped
        // until after the reference is no longer
        // used
        let a = A(this, i)

        // saving references to A actors in the set
        // delays/prevents them from being reaped
        // until after the reference has been deleted
        s.set(a)
        e = e + 1
        num_outstanding = num_outstanding + 1
      end
    end

  be done(a: A) =>
    // deletes a reference to an A actor but the actor
    // can only be reaped after GC is run for the Main
    // actor as that is when the ORCA message releasing
    // the reference is sent
    s.unset(a)
    num_outstanding = num_outstanding - 1
    spawn()

before:

root@5babe01f566f:/workspaces/ponyc# /usr/bin/time ./before --ponynoblock
35.91user 7.08system 0:05.91elapsed 727%CPU (0avgtext+0avgdata 1716480maxresident)k
0inputs+0outputs (3major+428831minor)pagefaults 0swaps

after:

root@5babe01f566f:/workspaces/ponyc# /usr/bin/time ./after --ponynoblock
41.16user 2.73system 0:05.89elapsed 744%CPU (0avgtext+0avgdata 13440maxresident)k
0inputs+0outputs (3major+3137minor)pagefaults 0swaps

Make GC for an actor more aggressive if an actor GC frees many actor references

We have enhanced the runtime to make actor GC more aggressive if an actor GC cycle deleted many references to other actors (> 100). This could be due to a program design where an actor creates many other actors and keeps references to them for a bit before replacing those references with ones for other newly created actors. This change will make GC for these actors more aggressive in order to try and limit memory explosion that could potentially occur otherwise.

Update to LLVM 17.0.1

We've updated the LLVM version used to build Pony to 17.0.1.

[0.59.0] - 2025-04-26

Fixed

• Prevent memory explosion when using ponynoblock in some programs (PR #4666)
• Make GC for an actor more aggressive if an actor GC frees many refs (PR #4662)

Added

• Add ability to trace runtime events in chromium json format (PR #4649)

Changed

• Make pony programs exit on an unrecognized pony runtime option (PR #4622)
• Update to LLVM 17.0.1 (PR #4680)

0.58.13

Make sure systematic testing doesn't switch to suspended thread

Previously, the systematic testing next thread logic would consider switching to the pinned actor thread even if it was suspended. This was very wasteful since the suspended pinned actor thread would not do any meaningful work and almost immediately re-suspend itself.

We have changed things so that the next thread logic properly takes into account whether the pinned actor thread is suspended or not when selecting the next thread to activate.

Fix race condition in epoll ASIO system

We've fixed a race condition in the epoll ASIO subsystem that could result in "unexpected behavior" when using one-shot epoll events. At the time the bug was fixed, this means that only the TCPConnection actor was impacted part of the standard library.

[0.58.13] - 2025-03-09

Fixed

• Make sure systematic testing doesn't switch to suspended thread (PR #4647)
• Fix race condition in epoll ASIO system (PR #4658)

0.58.12

Don't duplicate match checks for inherited trait bodies

Due to how we were doing match checks, some usages of match in default method bodies of traits and interfaces could end up failing checking once they were "inherited" by the implementing class.

For example, the following failed to compile:

primitive Prim
  fun ignore() => None

trait A
  fun union(): (Prim | None)

  fun match_it(): Bool =>
    match union()
    | let p: Prim =>
      p.ignore()
      true
    | None =>
      false
    end

class B is A
  fun union(): Prim =>
    Prim

We've updated to only do the match checks checking the trait's default method bodies.

Don't duplicate visibility tests for inherited trait bodies

Due to how we were implementing name lookups, some usages of calling private methods on a trait from within the body of a default method on the same trait would fail if a class from outside the package tried to implement the trait.

For example, if you defined the following trait:

trait T
  fun _override(): (T | None)

  fun _with_default() =>
    """
    Will compile if #4613 remains fixed. Otherwise, this will fail to
    compiled IFF a class from outside this package implements this trait
    and inherits this default method
    """
    match _override()
    | let t: T =>
      t._with_default()
    | None =>
      None
    end

And then in another package tried to create a class that implemented the trait and inherited the method body for _with_default, you would get a compilation error stating that you can't lookup the private method _with_default from outside the package. This error happened because the call to t._with_default() in the trait was "losing the context of the call". This simple class was all that was needed to trigger the bug:

class C is T
  fun _override(): (T | None) =>
    None

We've updated the compiler to only check name visibility at the time the trait is not type checked, not each time a class that has inherited a default method body from a trait is checked.

[0.58.12] - 2025-03-01

Fixed

• Don't duplicate match checks for inherited trait bodies (PR #4628)
• Don't duplicate visibility tests for inherited trait bodies (PR #4640)