[HN Gopher] Testing the Swift C compatibility with Raylib (+WASM)
___________________________________________________________________
Testing the Swift C compatibility with Raylib (+WASM)
Author : LucidLynx
Score : 49 points
Date : 2026-03-22 13:47 UTC (2 days ago)
(HTM) web link (carette.xyz)
(TXT) w3m dump (carette.xyz)
| acarette wrote:
| Thanks for sharing it!
|
| I might be interested on how to build the WASM build more easier
| with Swift tools. I guess some tools exist to facilitate the
| final builds, but did not found it...
|
| Do not hesitate to comment if someone experienced this before.
| keldaris wrote:
| Out of curiosity, how does the size and performance of the
| generated WASM compare to just compiling the same Raylib example
| from the equivalent C code via Emscripten? In other words, how
| much overhead does the choice to use Swift add here or in
| general?
| flohofwoe wrote:
| Raylib has a C API though, and this is 'easy-mode' in any
| language (even without integrated bindings generation like Swift
| or Zig have - e.g. it's fairly trivial to write a bindings
| generator that uses Clang's ast-dump json file format as input
| and translates the API declarations into another language.
|
| A more interesting question would be how well the C++
| interoperability works that was added in Swift 5.9, does it work
| with all C++ headers, even headers that make extensive use of
| template code. Also how does Swift extract information needed for
| lifetime tracking, e.g. C++ APIs that return smart pointers and
| object lifetime ends on the caller's side. Does this only work
| for C++ stdlib smart pointer types, or are custom types also
| supported.
| repelsteeltje wrote:
| For sure -- _that 's_ where it gets difficult.
|
| Show me a _real_ C++ interop example. Does function,
| constructor and operator overloading resolve correctly? How
| about C++26 reflection?
| Someone wrote:
| > A more interesting question would be how well the C++
| interoperability works
|
| They're using it in their work on FoundationDB. Looks good, but
| has limitations. Swift can call C++ and vice versa, Swift
| classes can inherit from C++ and vice versa, but not for all
| code, and may need work adding annotations on the C++ side. See
| https://github.com/apple/foundationdb/blob/main/SWIFT_GUIDE....
| .
|
| There's a good video on that work from a few years ago that was
| discussed on HN in
| https://news.ycombinator.com/item?id=38444876.
| enbugger wrote:
| > So, if you want to build games using raylib, why not learn
| learning or use Swift for that?
|
| Never ever worked for me. Imagine, you actually learned basic
| Swift and Raylib, now you want "advanced" features in your game
| like navigation/pathfinding, model loading, ImGui, skeletal
| animation (those are actually vital for gamedev). You realize
| that
|
| - Navigation is only ReCast which is pure C++ library,
|
| - ImGui has C++ API as first-class citizen,
|
| - Decent animation with compression is only open-sourced by
| OzzAnimation which is pure C++ project.
|
| For gamedev interfacing with C is never enough, half of ecosystem
| is built heavily on C++. Even C++ interop is not enough (see
| Dlang). Without all those libraries you are bound to make boring
| 2d platformers.
|
| Same for Zig, Odin, C3 etc.
| flohofwoe wrote:
| > ImGui has C++ API as first-class citizen
|
| Dear ImGui via the C bindings is actually quite nice and not
| much less convenient than the C++ API (the only notable
| difference is that the C API has no overloads and default
| params).
|
| E.g. here's a control panel UI (from the below ozz-animation
| sample) with the 'Dear Bindings' approach (using a custom 'ig'
| prefix)):
|
| https://github.com/floooh/sokol-samples/blob/d8429d701eb7a8c...
|
| Dear ImGui is a bit of an outlier for C++ libraries though,
| since it is essentially a C API wrapped in a namespace.
|
| OzzAnimation is also fairly trivial to wrap in an (abstracted)
| C API, for instance I use this in some of the sokol-samples:
|
| https://github.com/floooh/sokol-samples/blob/master/libs/ozz...
|
| Implementation: https://github.com/floooh/sokol-
| samples/blob/master/libs/ozz...
|
| ...used in this sample:
|
| https://github.com/floooh/sokol-samples/blob/master/sapp/shd...
|
| ...WASM live version:
|
| https://floooh.github.io/sokol-html5/shdfeatures-sapp.html
|
| TL;DR: quite a few C++ libraries out of the game-dev world are
| actually quite easy to access from C or languages that can talk
| to C APIs, mainly because the game-dev world typically uses a
| very 'orthodox' subset of C++ (no or very restricted C++ stdlib
| usage, no rtti, no exceptions, ideally no smart pointers in the
| public API).
| adamrezich wrote:
| > Without all those libraries you are bound to make boring 2d
| platformers.
|
| Perhaps if you're completely devoid of imagination.
|
| It is in fact possible to make video games without deferring to
| open-source libraries for every single aspect of it.
| ux266478 wrote:
| It's also industry standard to do so. I don't think I've ever
| seen a team outsource something like pathfinding. Maybe in
| the Unity/Unreal space, which I'm very unfamiliar with.
| Dependencies are generally speaking not viewed as a good
| thing. They become vanishingly rare outside of certain things
| like physics engines, sound engines, vegetation, etc. And
| usually higher quality proprietary ones are chosen over OSS
| (though this is changing with physics engines in particular,
| mostly thanks to Bullet)
|
| NIH is a cultural pillar. Even scripting layers are
| relatively split on if they're in-house or not. It's not
| uncommon to find both an in-house fork of Lua + a few other
| completely custom scripting engines all serving their own
| purpose.
| enbugger wrote:
| From https://recastnav.com :
|
| > Industry Standard - Recast powers AI navigation features
| in Unity, Unreal, Godot, O3DE and countless AAA and indie
| games and engines
|
| I see the industry is of full double standards :)
| ux266478 wrote:
| https://www.mobygames.com/group/9867/middleware-recast/
|
| It's not a terribly long list, it seems, even if it's
| non-exhaustive.
|
| > I see the industry is of full double standards
|
| Absolutely, and that's why it's so great. No two
| companies are going to look the same. The culture of the
| video games industry is a rather unique one that's kept
| its archipelago syndrome alive against all odds. It'll be
| a sad day if that ever changes.
| flohofwoe wrote:
| Pathfinding middleware has traditionally been a thing
| though, e.g. apart from the mentioned ReCast (which is the
| popular free solution) the commercial counterpart was
| PathEngine (looks like they are even still around:
| https://pathengine.com/overview/).
|
| If you need to do efficient path finding on random triangle
| geometry (as opposed to running A* on simple quad or hex
| grids) it quickly gets tricky.
|
| What _has_ undeniably declined is the traditional "10k
| US-$ commercial middleware". Today the options are either
| free and open source (which can be extremely high quality,
| like Jolt: https://github.com/jrouwe/JoltPhysics) or fully
| featured engines like Godot, Unity or UE - but little
| inbetween those "extremes".
| ux266478 wrote:
| > Today the options are either free and open source
| (which can be extremely high quality, like Jolt:
| https://github.com/jrouwe/JoltPhysics)
|
| I did mention this was changing in particular with
| physics engines. That being said, proprietary
| dependencies still reign supreme in places like audio
| engines. Something like OpenAL isn't really a replacement
| for FMOD or Wwise. I know those off-the-shelf engines
| roll their own replacements, but then they also roll
| their own pathfinding and navmesh generation as far as I
| know.
| adamrezich wrote:
| I've seen people genuinely wonder how one would go about
| making a 2D platformer without a generalized third-party
| physics engine--as though every single classic 2D
| platformer didn't have its own simple, bespoke physics
| simulation!
|
| There are entire classes (even genres) of video games that
| don't require substantial third-party library support, and
| it's frustrating to see that this seems to be more and more
| of a minority view as time goes on.
| leecommamichael wrote:
| > So, if you want to build games using raylib, why not learn
| learning or use Swift for that?
|
| Because Apple won't fix Swift's abysmal compile times, and there
| are languages with similar or better ergonomics without that
| flaw.
| zffr wrote:
| What are the languages with similar or better ergonomics?
| leecommamichael wrote:
| Everyone will have their different take on what Swift is, and
| what a proper alternative looks like. Swift started life as a
| C-family successor, so I'll be looking at languages with
| similar aims (fine-grain control, scaling to large projects.)
|
| The first two I'd mention are D and Nim. I only wrote ~10k
| LoC with these languages (so they weren't really for me) but
| they strike me as similar to Swift. They both optionally
| support an automatic memory management strategy like GC,
| (whereas Swift as ARC) and there is great effort put into
| metaprogramming facilities. Both D and Nim compile much
| faster than Swift, and offer better error messages than the
| Swift compiler in the presence of complex generic
| expressions. In the context of the parent post (games) Nim is
| especially well equipped with a package ecosystem. D seems a
| touch less lively, but has a following.
|
| For myself, I prefer the Odin programming language. Full
| disclosure, I've been donating to Odin for about a year now
| after happily using it for more than 5. After writing
| "Orthodox C++" for a while, I stumbled on Odin and feel as if
| it was made specifically for me. The compiler is fast, and
| the language has been something like a tutor or mentor for
| me, as it applies friction in places where I usually waste
| time. It would take some hand-holding as a first-language
| though, as some error messages relating to
| overloading/generics would seem obtuse to a beginner.
|
| EDIT: I've recently been exposed to the Raku language, and it
| strikes me as sort of a ... dynamic version of Swift? It's
| jammed full of functionality, with an emphasis on being able
| to design syntax a-la DSL.
|
| Also I'd add that Swift is sort of part of this new litter of
| "no-paradigm languages" like Kotlin and C#. I don't think
| Kotlin can actually dip as low-level as C# and Swift can,
| though. At least I think only C# and Swift have some kind of
| safety-wrapped user-level pointer "thing."
___________________________________________________________________
(page generated 2026-03-24 23:01 UTC)