That was not an FP invention, though. Delphi already did it - they kept the Apple's Object Pascal constructs from Turbo Pascal, and then bolted a whole new object system in parallel. FP inherited that mess and has to maintain it for backwards compatibility reasons. That said, given that the two systems are completely orthogonal, you can simply ignore the older one.
The biggest thing going in favor of FP is that it has been around for almost 30 years now, so it's very mature.
The compiler is insanely large and complex, more than the sum of the implemented languages would suggest. I can't imagine that anyone still has a complete understanding of it. See e.g. https://github.com/rochus-keller/FreePascal/blob/master/Read....
If you are OK with less popular languages you can check any of these: Nim, Hylo (formely Val), Vale, D, or Zig.
I haven't tried any of these yet, but they all have piqued my interest. Nim is probably the easiest one.
Unsafe C# is the most unsafe language I've ever worked with. Really terrifying stuff.
There's an interesting comparison of these C# features with Rust: https://em-tg.github.io/csborrow/
Manipulating bits with c# was very pleasant. Building the UI was incredibly quick and easy.
Can recommend.
The only downside is the documentation. Listing the parameters of a function and not explaining the purpose of the function, or what those parameters actually mean, is not proper documentation.
Borland set a fairly high bar with the Turbo Pascal 3 manual.
I've also been using Oxygene, which is a different Object Pascal dialect. (This started because I have begun working with RemObjects - I have to admit, I have wondered why I never used it earlier.) It had design decisions to evolve it more like newer languages (eg it has inbuilt async/await and did on .Net before C#, tuples, nullables etc) and sanitised the syntax somewhat. I like it a lot. https://www.remobjects.com/elements/oxygene/language
If I were you, if you like fpc, I’d actually look into Ada ( the OO part is a bit odd granted but works ). You’ll get extremely high control over low level stuff ( it’s used in the embedded world ) along with high expressivity and excellent performance.
Why do you say that?
Back in the 80s and early 90s it was the primary competitor to C, and in an alternate universe we might have ended up using Pascal decedents instead of C decedents.
For example the original Mac Toolbox was first written in Pascal: https://apple.fandom.com/wiki/Macintosh_Toolbox
The original Mac API were all native Pascal: https://wiki.freepascal.org/Basic_Pascal_Tutorial/History
With Free Pascal, though, you get a TUI IDE working basically everywhere, plus Lazarus across all major desktop platforms.
While it may look reasonably clean in the link below, I’ve always found it integrates badly with an existing codebase, the primary problem being that the ‘boundaries’ of the objects are not clearly visible.
https://learn.adacore.com/courses/Ada_For_The_CPP_Java_Devel...
I will add that the existing non oo features are excellent and I would even argue that in many cases you don’t need OO.
There’s zero technical reasons to not use pascal. Popularity, library availability, programmer availability and LLM quality of responses may be, but the technical foundation is there and has been for at least a decade (if not since turbo pascal from early nineties.)
I love it so much, it has a great balance between: readability, fast write/compile/debug cycle and great performance.
On tip: LLM is God send for it. So many times I find what I was looking for written in some other language and the LLM does the conversion.
I think Object Pascal is quite a nice language, it feels like OO without a whole bunch of messy package protected Java nonsense.
Sticking to very basic, procedural, non-OO, Pascal though. At its core Free Pascal, like early Turbo Pascal, is very small and simple, even compared to C, and there is value in that, especially since it is also a whole lot safer than C (but still has things like pointers and inline ASM when you need that).
At the same time, even modern Pascal dialects seem niche and the communities and libraries aren't quite there, especially when it comes to the ease of doing something like webdev: mORMot exists but will never be as popular and deeply integrated with everything like something like Spring Boot https://github.com/synopse/mORMot2
That said, there are also some cool projects out there, for example, a whole game engine: https://castle-engine.io/
I'm especially mentioning that, because the dev actually did a nice writeup on Pascal: https://castle-engine.io/modern_pascal
There's also a list of some software using Pascal: https://wiki.freepascal.org/Projects_using_Free_Pascal and sometimes it's packages that you might not immediately think of, like PeaZip which is a nice little program: https://github.com/peazip/PeaZip
I will also say that the idea of having a community Wiki for the programming language and the projects around it seems really nice: https://wiki.freepascal.org/ Maybe not possible for super widespread languages, but for someone taking a look around this is really, really nice.
Tooling it a bit lacking, but the language is simple enough you can get away with using a semi-broken LSP.
The language feels light and expressive, and has generally gotten out of my way - the only thing I've been really craving is closures.
You might not like it because it has errors as return values like Rust/Go, however there are some directives/macros/keywords such as `or_return` which work a lot like `?` in Rust.
For some tasks FreePascal is quite clunky, but the lower level the task, the quicker it is to write a solution.
> The cache coherency protocol is one of the hardest parts of a modern CPU to make both fast and correct. Most of the complexity involved comes from supporting a language in which data is expected to be both shared and mutable as a matter of course.
I feel like we live in a world where everyone works very hard to pretend that C is our best low-level language, when in reality an APL-like purely functional array language would be a better candidate.
Why does that relate to your post? Because if you're going lower level for performance you may actually find your assumptions to not hold true unless a good compiler optimization phase is involved.
Write in C, write in C
Pascal won't quite cut it
Write in C
