- automatic safety (garbage collection or other method)
- does not use a web engine
- high efficiency
- good for desktop applications
- forward looking features
Previous Posts
There were two or three posts from almost a year ago about my thoughts on:
- Zig
- Nim
- Swift
Systems Languages
My take on what makes a great systems language wavers from time to time, and I am not a systems developer. Specifically where Zig is concerned, I just do not have full confidence.
The question of a systems language like Zig comes down to the right people asking the right questions. Some experts have said there are reasons why Zig could realistically replace C. I would be very curious if they had any further ideas beyond those of Zig's.
The main idea of any prospective successor of C would be that it truly sought to make the language's creation and investment very worth the effort and worth the switch individually and in groups. It would make the very best of the opportunity to solve as many problems as possible for those features and characteristics of a low level systems language.
We know that such a switch could never be a momentary event. And yes "never" is actually apt in this case. The industry could literally not do it.
Rust is being treated as a fully satisfactory systems language, enough for kernel development. That might be true enough when it is used alongside C, but I wonder if it would really excel as a standalone systems language. Rust should have had Zig's simple and liberal low level access, or Zig should have had a compiler option for a borrow checker to be implemented. It seems too late. But there's no actual known apocalyptic deadline. Time still spans into the abyss of the future indefinitely.
Not Ideal Situation
My personal wish was that all this language fever of the last fifteen years had never really taken hold, except for one or two very well planned out languages, or even a kind of new compiler and an unprecedented matching set of highly compatible languages to go with that compiler.
This would put the necessity of a compiler-based borrow checker as a much more optional feature, along with a very capable set of low systems features that were comparable to those of C or Zig, meaning that they are "close to the hardware", and they are designed with prominent usability in mind.
If I would have had my way, Rust, Zig, Nim, and [of all things] GDScript, would have been one language, or they would all be compatible with the same compiler. We also have had efforts poured into many other languages that are focused on more momentary preferences rather than overwhelming focused on wide reaching features.
The Mojo Langauge
Mojo has some compatibility with Python, but it is not one-for-one with Python libraries. Linux GUI ecosystem for Mojo is likely very sparse.
Mojo has just made news for surpassing version 1.0, and being given more open licensing. Mojo is specifically attempting to be a meticulously designed one-solution language. This is an understatement though. What they have set out to do is unprecedented, and it makes a lot of sense.
If I am not mistaken, the idea that the Mojo creators have had behind not opening it up so far, has been that they are very concerned with a specific approach to professional development for working out the hard problems.
If Mojo really fulfills on its intended path of development, then it could become a truly revolutionary language.
Mojo's Important AI Approach
This is where I actually really like Mojo, at least in how I interpret its stated intentions. (They could change, or go a different direction.)
Mojo is not solely about just designing the language to be used by AI agents.
Rather, Mojo is being designed to work across the hardware and infrastructure that AI uses in a much more generic sense that focuses on a deeper and more thorough approach for accessibility from one language.
There is a big difference between these things, especially if Mojo follows through in practice. To me, it means that the AI giants are not so exclusively a wizard behind the curtain. This is more than just a glass-half-full look at it. It's a mature approach to the wider array of hardware, which btw, actually has more things to offer than just AI, AI, AI.
But it is not done yet. Actually, that massive portion of Mojo's development work has yet to be started.
This version 1.0 of Mojo has been about getting standard language features in place.
Mojo's Weird Mojo
Mojo has a LOT of development left, and it has just changed ownership. There is some uncertainty about what will happen with Mojo as a language. Mojo's open licensing just took hold. I think it has been in the works for a while, waiting on when core development was completed.
Mojo has an Apache 2.0 license, and a Github. But the company that is developing Mojo also has a unique kind of model, where the Mojo language is developed closely alongside an AI product called MAX.
MAX may or may not be fully open sourced eventually, but probably not fully. Being unconventional is not bad by itself, but it is true that most officially supported FLOSS or FOSS languages are not associated with companies where the languages future of licensing is uncertain. And the future of Mojo's licensing still seems uncertain to me.
Generally languages that have official support from FLOSS and FOSS communities have always had that licensing, and their governing orgs carry little-to-no risk of ever altering the licensing at any point. These orgs typically have independence, and even to their detriment. Mojo has a strong tie to financial incentives and precarious executive decision making.
Still Mojo has solid language designers, and the organization has made a clear statement about Mojo as a language, existing for the sake of a language. They also have made a clear point of making MAX a separate, distinct entity . . . to this point in time.
The Crystal Language
Like Mojo, Crystal has also reached a new point in development in the last few months. Specifically Crystal has matured its parallelism functionalities, and Fedora has been considering official Crystal support in Fedora version 46, which comes out in April/May 2027.
Crystal for some reason has not had very much news or community buzz, but it is a very mature language that is also much more community oriented than Mojo, and more recently Rust.
Crystal has the right feature list, and it is mature. Crystal seems specifically designed to get the job done, which I think is just what the doctor ordered. Fast operation, garbage collection, great C interop, high-level scripting, concise language, concurrency, parallelism, self-hosting compiler.
People apparently love the near-ruby syntax.
Crystal also has high quality bindings for GTK (which is written in C) and good documentation on using GTK.
Object Oriented Paradigm Main Deterrent?
Crystal is object-oriented, but also said to be multi-paradigm. I haven't seen anything about how that plays out in the real world. I think this aspect of being object oriented is why I have overlooked it up to this point.
OOP is said to have some realworld shortcomings in code duplication, security concerns, and requisite verbosity. Ultimately the paradigm and its initially highly sensical concepts can play out in coding that turns into drudgery.
Crystal is Enhancing AI Usability
Now perhaps this is the real reason it is being taken more seriously for support in Fedora.
From a distance, it seems that you could say that a language that is altering its design to serve a dual purpose of being well built for both AI and human use would mean that the human use is being compromised. But that is merely common sense, from a distance - perhaps not that meaningful.
In terms of AI, this is what is different between Crystal and Mojo.
No comments:
Post a Comment