- 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.
Regardless, we do know that a massive industry-wide switch could never be a momentary event. And yes "never" is actually apt in this case. The industry could literally not do it within even a ten or fifteen year timeframe.
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 a high priority focus 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. Instead of other languages getting translated only into CPU-compatible assembly, Mojo is supposed to provide compiler and programmatic access to:
CPUs - APUs - GPUs - TPUs - ASICs
I am not sure how similar this will be to the type of low level access that C or Zig has to the hardware.
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 the AI agents also use. This is a more typical kind of access to hardware that compares to what developers can access for the CPU. It focuses on accessibility from one language instead of disparate, vendor-specific tools.
There is a big difference between these two approaches, and hopeful Mojo can follow through in practice. To me, it means that the AI giants are not so exclusively a wizard behind the curtain. Rather than their tools having the only access to the hardware, a general language can provide that deeper access to developers from one single language.
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 of Mojo has been about getting standard language features in place.
Mojo's Weird Mojo
In particular, this "weirdness" is about looking at Mojo from a more singular FLOSS or even FOSS perspective, hence its own section here. Mojo is not weird from a normal business perspective.
Yes Mojo has a LOT of development left. And, it has just changed ownership. There is generally more uncertainty in the context of these kinds of circumstances.
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 (to be honest, it does not look like MAX will be fully open sourced.) 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.
Generally, it's additionally a simple matter of priority to FLOSS and FOSS values. Orgs have no particular ethical obligation to these values, except for matters of stated goals and purposes. But generally, if an org lacks a focus on FLOSS and FOSS, then there will most likely be other clashes that arise with these values as a matter of the circumstance. In short, there's weirdness.
But of course with something this close, you never really know. 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 is not supposed to be a raw systems language. It is an efficient and concise application language, with automatic memory management in the form of garbage collection.
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.
Comparison to the Go Language
My theory is that Go has weirdness with its relationship to FLOSS and FOSS for the same reasons I was describing about Mojo. Go has a BSD license, not a GPL or Apache license, or MIT.
Crystal is comparable to Go according to its features and its niche, but Crystal is more likely to be compatible in values with FLOSS and FOSS.
Crystal is Enhancing AI Usability
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 from a distance - perhaps not that meaningful.
I think maybe AI compatibility has to do with how the actual code syntax can be tracked and reverse engineered linguistically by AI systems. Just guessing, but this might possibly have something to do with how explicit the function and value passing structures and type system of the language are explicitly expressed in the language syntax.
So depending on the paradigms used, it might be that half the battle of increasing AI compatibility is done by simply using the paradigms that happen to be more syntactically expressive. And thus, as long as these paradigms have already been used in human-friendly ways in various other languages, it would not be a real disadvantage to simply use those paradigms to get the best of both human and AI usability.
No comments:
Post a Comment