I feel there is a spot between the performance and control of low-level languages and all the tremendously useful features of high-level languages. What I basically wanted was "C with Lisp macros". I think Rust is the closest language, ideologically, to Hylas.
There is no specification or anything very formal laid out except for a couple .md files in the docs folder. The language has evolved and changed a lot over the past year (Everything from the comments to the type system has changed), and is nowhere near prod-ready, but I want to eventually put it to practical use.
This reminds me a lot of GOAL, the in-house videogame development language that we used to use at Naughty Dog. It had a LISP syntax and feel - complete with awesome metaprogramming and on-the-fly relinking - but the runtime was much closer to a low-level C/C++. In fact, you could even drop into MIPS asm in the middle of a function.
Coming from a mostly C/C++ background, it was an eye-opening experience, and I'm definitely a fan of languages other than C for performant code.
C and later on C++ just got widespread due to UNIX's adoption at the enterprise, before that, there were quite a few systems programming languages around.
Of course, youngsters nowadays tend to think only C and C++ play on that league.
Interesting. Which ones in particular were popular? And what do you consider a "systems programming language"? As I understand it, a systems programming language is a language that can be used to implement an operating system. C was the first high-level language to be used in this way.
I've heard about that and it sounds awesome. Can you say anything more about its design and syntax? For instance, I've heard that you could do manual memory management in GOAL. How was that accomplished?
It's been a while, so my memory's a little fuzzy. If I remember correctly, all the code was s-expressions, piped through a scheme (?) preprocessor, and then into the compiler. Many of the basic language constructs were actually macros.
The lower-level language itself was statically typed, and supported pointers and arrays as native types - identical to their C equivalents. Classes either derived from "structure" (unboxed) or "boxed". The boxed types had a class pointer, much like a C++ vtable ptr, but with some more useful introspective data attached.
Runtime linkage was mostly accomplished by patching types' method slots and/or patching a global symbol table. The compiler talked to a MySQL database which was shared by the whole company, so that symbols wound up having unique and consistent ids across all machines. The "listener" ran on a PS2 devkit, and essentially just accepted object code to link and execute. The REPL worked by having the compiler compile each expression, squirt the MIPS object code over to the PS2, have the PS2 link and execute it, and return a result, which the compiler would then print (possibly peeking into the PS2's memory in order to display more useful information). Similarly, you could place your cursor inside a block of code, hit CTRL+T and have just that function/method updated on the target. (This was back when edit-and-continue was still something of a novelty!)
The ABI was close enough to C that GOAL and C could call each other almost directly (the MIPS GP register had different meanings in GOAL vs C code, and so had to be patched up).
You could also pretty much mix GOAL and assembly, and we frequently did. GOAL's backend was never going to be as efficient as gcc's, but the massive increase in productivity it provided meant that we could devote much more time to optimizing the stuff that really mattered.
I think Andy Gavin's on here somewhere - he should really write an article about it if he hasn't already :)
I've heard of it but never took a hard look at it. The one thing that's interesting about it to me is that it's a Lisp with "normal syntax", which is people's main complaint about Lisp, yet it hasn't exploded in popularity the way one might think it would.
C could have meant a different syntax. Dylan is pretty well known for having macros without having s-expressions. And some pretty low level code can be written in Dylan. There's been some low level networking code by some Germans, as well as large parts of the Dylan runtime, including byte-level layout of method dispatch data. Looking through what he has so far in his repo (a quick look), a lot of it is similar to what we have in subject matter.
There is no specification or anything very formal laid out except for a couple .md files in the docs folder. The language has evolved and changed a lot over the past year (Everything from the comments to the type system has changed), and is nowhere near prod-ready, but I want to eventually put it to practical use.