why not language X

why is there no carbon , no haxe , no pony language on freebsd

The absence of official or stable support for Carbon, Haxe, and Pony on FreeBSD as of late 2025 is primarily due to their early developmental status, upstream compatibility issues, or a lack of active maintainers within the FreeBSD community.



1. Carbon Language

As of December 2025, Carbon is not available on FreeBSD because it is still an experimental project that lacks a production-ready compiler for any platform.

  • Experimental Status: Carbon's official roadmap indicates that an MVP (version 0.1) is not expected until late 2026, with a production version (1.0) likely delayed until after 2028.
  • Limited Toolchain: The current toolchain is incomplete and primarily focused on Linux nightly builds and a web-based Compiler Explorer.
  • Incomplete Features: Key features like C++ interoperability and memory safety design are still being finalized in 2025.

2. Haxe

Haxe is currently not in the official FreeBSD ports because it lacks a dedicated maintainer and faces compatibility issues with modern build tools.

  • Upstream Incompatibility: Recent versions of Haxe use the dune build system, which has versions incompatible with FreeBSD’s directory structure (specifically /usr/local/lib) without manual patches.
  • Dependency Issues: Several required OCaml packages fail to build on BSD systems because they lack upstream support, necessitating complex workarounds for manual compilation.
  • Manual Installation: While not in the ports tree, it is possible to compile Haxe manually on FreeBSD 14+ by following specific community-developed steps.

3. Pony Language

Pony is absent from FreeBSD due to a lack of platform-specific maintenance and shifting infrastructure priorities within the Pony project.

  • Focus on Other Platforms: In 2025, the Pony team has focused on migrating to musl-based container images and expanding support for ARM64 on Windows and Linux.
  • Resource Constraints: The project has recently ended support for other platforms, such as Intel-based macOS, due to the loss of CI infrastructure, indicating a prioritization of limited resources away from less-populated ecosystems like BSD.
  • No Active Port: Like Haxe, Pony currently lacks an active maintainer to ensure it meets the requirements for the FreeBSD Ports Collection.
 
IMHO, It's all about prioritization of limited engineering hours (there are only 24h /day). FreeBSD is about stability and coherency. The community picks up trends when they become mature enough, everything else is a personal playground. There is too much going on around the world that is fun, great, fresh.

That being said, if someone decides to bring one of the new things into FreeBSD ecosystem, be mindful of the future support.
 
So many languages, so little time.
To me languages are about what problem do they solve, how much real support/usage there is.
By this I mean "outside the language fan community".
Does this new language have interfaces to existing libraries or do you need a whole new ecosystem?

Should every OS have support for every language? How many does Windows support?
 
That being said, if someone decides to bring one of the new things into FreeBSD ecosystem, be mindful of the future support.

Well, Carbon is a Google project, and they are generally not friendly to OSes and architectures they don't target as primary users.

So even if you port it to FreeBSD you probably have large amounts of diffs you have to maintain on your own forever (because Goggle probably doesn't accept them upstream).
 
Even on Linux Carbon is yet not usable.
If a language is not ported to FreeBSD don't waste your time.
One exception is haxe. Don't know why vendors can't make make/gmake for all.
 
I never found a better C++. There is however better C i.e. , C3 , dlang/d , zig , odin
One can argue that C3, dlang/d, zig, odin are not a "better C" but languages that try to fill the same role as C with different paradigms.

Languages are only as good as the libraries they can use/integrate with.
Longevity of a language is a good thing: current C standard (not sure what that is) is different than the original language spec from circa 1972. Arguments can be made for and against "is current standard better".
Languages can/should evolve over time as they get more and more use. Widespread use, especially outside the original imagined space helps find problems.
 
I go with mer, and like to add:
If you look at the list of which programming languages there are, it's a lot. I think, I once saw one on wikipedia, but cannot tell if it's complete [probably not], there are a lot of languages (>300? - a lot.)
To me nobody can learn them all, nor is it useful.
To me you need to divide programming languages into two categories: the ones you want to learn, and the ones useful for real projects.

The first category contains a lot of languages either started by good intensions, and with lots of good ideas, but never reached a maturity level made them practically useful. Or there are fun languages, like e.g. brain fuck. And several dialects. (I always wonder: So many people complaining about C, and yet so many "new" languages look so very C-like.) Most of those (IMO) are for academical purposes, or just for fun. But personally I don't spend time learning one of those.

For the second category in theory the language has to be picked best suitable for a certain job. And for this it's good to know as many languages as possible. But that's only useful, when you are in charge of a project at its start. And pure technical points are not the whole truth. You also need to anticipate the size and duration of a project, and respect the number of people capable of or willing to learn a certain language. If for example you want to start an open source project which needs 200k man hours coding, you better think of deciding for some more popular language, even if by pure technical reasons it was best done in SECLANK (some exotic complicated language almost nobody knows), simply because it's highly propable you will not find enough people to realize it then.
But in most real cases you simply have to use the language the project is already done in, doesn't matter if the choice was best, or not. You simply don't enter a running project with hundred thousands lines of code, and start with: "Guys, doing this in GNARCK was completely nuts. This thing must be done in CRANGK! Let's rewrite all code first before we continue!"

After all, there are not so many languages really worth to learn them deeply. Maybe two, or three dozen?
I also think it's more valuable trying to master some of those, than to spend too much time for learning a hundred languages shallow, getting lost on the quest "search for the perfect language" while sooner, or later you will realize: there is no holy grail. That's exactly the point why there are so many languages today: Every language was developed to solve a problem better, or at all, which existing ones can't, or do worse - always with other drawbacks again: Either the new language lacks of certain things, others can do better, or it become too complex, too complicated, too incomprehensibly, too slow, or too whatever to be practically useful at the end.

Additionally, when I read some articles about AI that sound reasonable to me, there will be a third category soon:
Languages AI can deal best with. So, there seems to come a future soon, when humans don't learn programming languages, but to learn to deal with AI which does the coding instead.
If this is true, Rust is already outdated, and not worth to learn. 😁:cool::beer:

Anyway, point is: Personally this slows me down on my personal programming improvement, because I wonder if it's worth, is it still senseful to spend any time on improve my programming, or learning any programming languages at all, besides for fun?
 
  • Thanks
Reactions: mer
Anyway, point is: Personally this slows me down on my personal programming improvement, because I wonder if it's worth, is it still senseful to spend any time on improve my programming, or learning any programming languages at all, besides for fun?
"Do I learn enough of language A to pad my resume or do I really learn languge XYZ because it looks to be actually useful for real world scenarios?"

You have a problem to solve with software.
You have to understand the problem so you can define the requirements.
Once you define the requirements you can start thinking about design
Once you have the design you can start to implement.
You need to pick a language to implement; the choice can either help or hinder.

But one can have all the requirements have the best design have the "best" language and it can still be
implemented poorly.

My opinion only a lot of languages that emphasize type safety and things "that are better than C" wind up simply
being crutches. The tools (compiler/linker) are preventing you from making some basic mistakes, but you can get
close to that with C and other C related tools ("-Werror").
Garbage Collection? Good but may raise issues under certain use cases. But it does remove the need for the coder
to track memory allocation/deallocation.

Toss in AI and does the language actually matter? AI is going to write the code so it understands it and make it easy for AI malware to take advantage.

So use whatever language tickles your fancy and advances your career. But keep in mind, around the "Y2K" times there was an
increase in demand for FORTRAN and COBOL people.
 
AI is just another tool imho. Use it or don't, but it can be pretty useful whether you ask it questions (how can I... is it possible to...), like a junior assistant or like a fancy macro library.
 
  • Like
Reactions: mer
The "problem" isn't the tool itself, the problem is all the people buying into the advertising that this particular tool can do advanced work unsupervised, that you (the welder of the tool) don't need technical and domain knowledge to use it.
And thus, the "turn internet into shit" cycle continues.
 
A.I. is very good when you ask very simple questions , like give me a C program showing "Hello World".
But this does not mean it can answer difficult questions like ,
give me a dlang program using gtk toolkit drawing the most simple square on screen.
The answer is A.I. hallucination thinking itself is always right but not one answer from it will compile.
 
Back
Top