Recently I have been on the market for a decent application language. I love C, and it will probably remain my goto "systems language", whatever that means. But there are times where you do not want to worry yourself with memory management, and other times you may actually want the strong typing provided by a higher-level language. When I am writing an application I need a language that helps me, not a language that takes me on a wild road trip.
As a first step, I put together a short list of requirements that must be satisfied to qualify for my "application language" role. The list varies from quantifiable metrics to personal preference, and is as follows:
As a first step to this hunt, I began designing my own programming language that would theoretically fill this role. However, on top of that design work I also spent effort researching other programming languages that may fill such a role. I did not try every programming language listed, but I at least read into their operation.
I want to make sure this is known up front: I absolutely detest Go. Both because of the philosophy behind its creation and because of its lack of any real innovation or merit. Go manages to be the worst of all worlds: Automatic memory management with explicit allocations and pointers, a horrible mix of syntax ideas that amalgamate into what I can only describe as "sloppy", and a terrible package management scheme that I am amazed hasn't resulted in an explosion of malicious packages.
That said, I remarked it as the "obvious choice" for a reason. It fulfills a decent amount of my requirements and if I could get past my own personal vindiction against it, it would probably serve me fairly well. Go was one of the languages I actually installed—again—and attempted to use. I lasted 10 minutes.
I cannot fathom why this language has the traction it does. I could ramble onward here unto forever about it, but I'll leave it there. Go is not the language I seek.
You may hear all I have to say about Go and assume I feel the same with Java, and this assumption would be incorrect. I like Java quite a lot; Its verbose syntax effectively helping to self-document classes, methods, and code, not to mention its very decent type system. While the runtime is far too large for my needs (the JRE is 60MB, not to mention the runtime memory costs), I use it professionally and happily use it personally for some befitting projects.
Of course, anybody who knows Java will look at my requirements and correctly state that it is a terrible fit. Java is far too large, and does not support native executables without pulling in GraalVM as a crutch. Java is a fantastic language for a variety of application-like tasks, it is not a language that fulfills my requirements for an application language.
I stumbled upon Eiffel on my research and was intrigued by it. I had up until now not looked at it very closely, and had only heard of it in passing when reading some technical documents. That said, on paper it appeared to fulfill a few of my requirements.
It does look very interesting, and to the right person likely a good choice. My time with it, however, was not so great. I find the Pascal-family of syntax particularly frustrating to read and interpret, and as such I did not last long in this language.
Scala was the programming language that finally got me to not only understand functional programming principles, but also to apply them effectively. I have a lot of respect for Scala as a programming language and as such I wanted to ensure it was mentioned here, but it is also a non-starter akin to Java.
There are a couple reasons for discounting Scala—besides the JVM reliance—and I think they are worth mentioning. First of all, while Scala Native does exist and works very well, most libraries do not support its version 0.5.x. As that version is what adds system threading support, that is a big deal to me.
Another issue is its syntax. And by "syntax", I should clarify "syntaxes". It feels as though you can write any expression in Scala in a minimum of 4 different ways. This is not a good thing. It adds so much mental overhead to Scala as you are trying to understand what is a block, what is a function, and even whether or not whitespace is significant! You can mix and match insignificant and significant whitespace in the same file, let alone project! Sure, you can enforce that people not do that, but come on. This is an absurd amount of flexibility, and it leads to code that borders on Perl's level of write-only. Learning a new Scala library is akin to learning an entirely new syntax.
Lastly, SBT is just terribly, horribly, unbelievably slow. The fact that the tooling in Scala lags so desperately far behind in performance to Java is a serious issue. I love SBT itself, as writing Scala code to compile Scala code is very convenient. But it just becomes unusable once you approach a reasonably large project size.
That leaves us with the programming language that has not only won this contest, but also my heart. I decided to pickup OCaml after a fair bit of indecisiveness due to its functional nature, and I could not be happier that I have.
I was concerned that since it was a functional programming language first, it would be difficult to be productive in it. I faced this issue heavily when attempting to learn Scheme, Lisps, and Haskell in previous language ventures. I even began to face this in Scala, where attempting to be functional first caused programming paralysis as I struggled to represent arbitrary concepts in ways that were ergonomic to use.
However, OCaml would not be further from this experience. It took me a few days to familiarize myself with its syntax, and the way it wants you to do things. But once I picked it up and started programming in it, I was hooked. I wrote my Gemini client "geml" in an afternoon, with a programming language I had just started using. If that isn't a testiment to the power of this language, I don't know what is.
OCaml manages to be almost always immediately readable, and pleasantly so. I find that an OCaml file reads like a well written book, as you go down the file you turn the page and more context and knowledge is immediately presented to you. This has helped immensely when dealing with some of the warts of the language, namely around libraries and documentation.
While the library ecosystem around OCaml is healthy from my perspective, the documentation across it assumes you know a lot more than I believe they should. More often than not I find it far more effective to just pull up the ".mli" files directly and to read their module interface definitions.
Another huge benefit it has, is the build system "dune". It integrates very well with their package manager "opam", which is also fantastic. Dune is also very fast, and easy to configure through their s-expression based configuration language.
All of this said, and OCaml isn't even purely functional, only functional first! You have access to limited imperative, mutation, and object oriented systems for when you encounter tasks that are more ergonomic in those approaches. OCaml feels explicitly designed to be productive, ergonomic, and pleasant. It shows.
We'll see how this honeymoon phase with OCaml ends. There was a time when I thought I would be replacing my Java work with Scala, and that absolutely did not come to be. That said, I have never been able to hit the ground sprinting like I have with OCaml, and the fact that the trio of OCaml + Dune + OPAM almost entirely my satisfies specified requirements while being extremely productive to use and work in makes me feel like I will be using this language for a long time.
Some applications I normally would've written in C may even be implemented in OCaml instead going forward (see: the server this capsule is hosted on). I cannot believe I looked past this language for as long as I did, but I am grateful to have finally landed snuggly inside of its ecosystem.
As for the programming language idea I had started designing, I think it will remain dormant for now. While it will probably be scraped in favor of continued use of OCaml, who knows.
=> Back to Index This content has been proxied by September (ba2dc).Proxy Information
text/gemini