About Pony

How’d Pony come to be?

Check out “An Early History of Pony”.

Why’s it called “Pony”?

Interesting question. We hear that a lot. If you read enough of “An Early History of Pony”, you’ll get your answer.

What makes Pony different?

See the “What makes Pony different” section of “Discover”.

Why would I use Pony instead of language X?

That’s a hard question to answer. Language X is probably very compelling for some problems. It’s probably less compelling for others. Such is computers. In the end, the best we can do is tell you what Pony is good at and you can make the decision for yourself. To learn more about Pony, we suggest checking out the “Discover” section of the website. There’s a portion of that section called “Why Pony” that might answer your question.

Where can I find the Pony roadmap?

There is no official roadmap. Pony is a volunteer driven project. Unlike many programming languages, we don’t have corporate backing. Our users add features and fix issues based on their needs. Pony users solve the problems that matter to them, and we all benefit.

Many of us who are regular contributors share some general goals as we move towards an official 1.0 release. We are working towards making a Pony a stable, rock-solid platform for writing high-performance, concurrent applications.

We invite you to join our small but growing community and help push Pony forward. We’re still at an early stage, and new community members can have a huge influence on the language. Join us!


What does Foo() do if my Foo class has both create() and apply() methods? Does it call both?

Yes, it calls both. However perhaps not in the way you imagine.

  • Foo creates a new object instance using create()
  • () is the apply call on the newly created Foo instance

This example program demonstrates what is going on:

use "debug"

class Foo
  new create() =>
    Debug("create called")
  fun apply() =>
    Debug("apply called")
actor Main
  new create(env: Env) =>
    Debug("call Foo()")
    Debug("call Foo")
    let foo = Foo
    Debug("call foo()")

Check out [the example program in the Pony Playground.

For more information see the Sugar section of the the tutorial.


I get a “requires dynamic” error when compiling, how do I solve it?

/usr/bin/ld.gold: error: ./fb.o: requires dynamic R_X86_64_32 
  reloc against 'Array_String_val_Trace' which may 
  overflow at runtime; recompile with -fPIC

try running ponyc with the --pic flag.

For example:

ponyc --pic examples/helloworld

As of Pony 0.17.0, if you are building ponyc from source, you can have --pic automatically set for you. When building ponyc, run the following make command and your generated ponyc binary will always supply --pic without you having to set it.

make default_pic=true


Does Pony have a package manager?

That would be yes and no. Package manager means different things to different people. What we have is a simple dependency manager called pony-stable that we are planning on growing into a full featured tool. Whether that is a more full featured “dependency manager” or more full featured “package manager” depends on how you define the two terms.


How can I supply custom linker parameters?

So, you need to link your program to a custom library or otherwise pass a particular linker option? You can accomplish your goal using the ponyc --linker option.

You’ll need to know what your current linker is. To get it, compile a pony program and pass --verbose 3.

On Linux, MacOS or other Unix-like

Then examine the output. You should see something like:

ld -execute -no_pie -dead_strip -arch x86_64 -macosx_version_min 10.8
  -o ./timer ./timer.o -L"/usr/local/lib/pony/0.9.0-e64bff88c/bin/"
  -L"/usr/local/lib" -lponyrt -lSystem

The ld is the linker command that is usually used on MacOS or Linux. If I wanted to link in the library Foo and needed to pass -lFoo then I would compile my program as:

ponyc --linker="ld -lFoo"

That would change the linker command that ponyc runs to:

ld -lFoo -execute -no_pie -dead_strip -arch x86_64 -macosx_version_min 10.8
  -o ./timer ./timer.o -L"/usr/local/lib/pony/0.9.0-e64bff88c/bin/"
  -L"/usr/local/lib" -lponyrt -lSystem

On Windows

Compiling a pony program with --verbose 3 will produce something like:

cmd /C ""C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64\link.exe"
  /DEBUG /NOLOGO /MACHINE:X64 /OUT:.\helloworld.exe .\helloworld.obj
  /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.15063.0\ucrt\x64"
  /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\Lib\10.0.15063.0\um\x64"
  /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\lib\x64"
  kernel32.lib msvcrt.lib Ws2_32.lib advapi32.lib vcruntime.lib legacy_stdio_definitions.lib dbghelp.lib ucrt.lib libponyrt.lib "

The path ending in link.exe is the linker that the pony compiler is currently using.

To add options to the link command, I would compile my program as something like:

ponyc --linker="C:\OtherPath\link.exe /LIBPATH:C:\Foo"


Does Pony have green threads?

The short answer is no. Pony doesn’t have green threads. By default, the Pony scheduler starts 1 “actor thread” per available CPU. These threads are used to schedule actors. Each of these threads is a kernel thread.

The longer answer is “it depends”. Actors are Pony’s unit of concurrency and many people when asking if Pony has green threads really are asking about how concurrency is modeled. You, as a Pony programmer, never interact with scheduler threads directly, you never interact with any sort of thread. You worry about actors and sending messages between them.