>Basically, what "designed for game development" means?
I've been doing a lot of work in Haxe, but have struggled with performance issues due to GC and memory churn. I wanted a lower level language with more control, but without sacrificing the ergonomics and abstractions I'm used to. Term rewriting and implicits are examples of features that let me layer abstractions onto a language but still maintain complete control.
>What was the original language and why made the change?
It's not up on GitHub, but the prototype was begun in Rust. Ultimately I found I'm much more productive in Haskell and made the switch.
This looks like it takes influences variously from Haxe, Rust, and Haskell, which are all great in my book. But the first thing that crossed my mind was, "could it compile to other languages besides C?"
The reason being that I think the way to really move up the baseline is to take another page from Haxe and aim for cross-compatibility between different systems languages, becoming a "language that unites them all". So that could mean relatively new and hip ones like Rust, D or Zig, or older ones like Pascal(Delphi), Fortran, Cobol...
And those are niches relative to C, but they're nearly unserved niches AFAIK.
AFAIK languages "compile to C" mainly because they use C as an intermediate representation and the C compiler as the last stage of the compile/link process, so kitlang itself doesn't need to support code generation for various CPUs, and also doesn't need to implement an LLVM frontend. Instead it uses the target platform's C compiler, which is a lot less work but has basically no downsides.
Also the C IR code might make it easier to interop with other languages, since C is basically the 'lingua franca' that all other languages can talk to in some form.
> Instead it uses the target platform's C compiler, which is a lot less work but has basically no downsides.
The downsides of leveraging a platform's given C compiler as your backend is that now you'll be spending a large chunk of time learning the hard way about all the various incompatibilities in C compilers, and adding workarounds in your frontend for the otherwise-unpatchable behavior encountered in every old version of every major compiler on every platform you wish to support.
Conversely, the advantage of using a single known backend is that you can automatically know what code your users are running when they submit a bug report, and you can fork and ship the patch yourself rather than trying to convince an upstream C compiler to accept the patch, then convince the upstream distro to ship the new version of the compiler, then convincing all your users to update their platform C compiler.
Kit may have an easier time of it if it's intended only for games, since that narrows down its supported target platforms substantially. The harsh truth is that most game devs only care about one platform (Windows) and one toolchain (MSVC), so at least it can tailor its output to appease MSVC specifically.
I've used Haxe a lot and at this point I see its wide array of targets as not only a strength but at times a major weakness. I used the C++ target most often, but didn't have access to all of C++ features because they had no analog on other targets like Lua or Python - essentially Haxe becomes a least common denominator of all its targets. Focusing entirely on C lets me have a great interop story, and C is highly portable already.
I'm planning to get a more detailed comparison with languages in the same space. Kit and Zig overlap quite a bit; the main difference I see is philosophical. A major goal in Kit is to be concise, expressive and eliminate boilerplate; Zig perfers to be straightforward and readable, where a function call at runtime always looks like a function call in your code. Term rewriting and implicits are examples of features in Kit that probably wouldn't be implemented in Zig. Also, Zig aims to replace and compete with C, Kit just wants to leverage it, so the scopes are quite different.
Zig is awesome - I've used it and would use it again, I'm funding the creator on Patreon, and I see these two languages as filling slightly different niches and having different pros and cons.
it's a bit of an overstatement to call jai popular, seeing as how it hasn't benen released yet. but yes, it's a very interesting looking language, and the development notes are great.
I've written about c2 before. It has some things that might be nice to have in c (header files, remove ->), and some things that make Zero sense to have in a language that aspires to be c (dynamic arrays as a language feature). Ultimately, it doesn't provide anything nearly compelling enough to leave the wide support of the c world.
Ben, could you go a little into detail on what you had in mind with the term rewriting system? The sin/cos example seems a little underwhelming, since these should be evaluated at compile-time in the first place.
They seem like a variant on C macros, but without the restriction on function syntax. Maybe one could implement Python's with statement in userland, which is very nice.
It also seems to me that you could replace C++ templates, yet you do have generics. How come? What's the difference?
My intuition is that ambiguities are at least possible, so what about precedence, which AST term is evaluated first? I'm thinking of some situation where two subtrees match the rule, but you end up with different results depending on which is transformed first. E. g. if you were to define a cross product rule, and apply it to a × b × c.
What about infinite loops in rule sets? What about recursion?
What about a situation where multiple rules could be applied? Is there any way to debug the transformations? Is that what the `using` scopes are for? If the compiler was to detect ambiguities, that seems pretty expensive, because it would need to match every rule to every subtree, right?
This thing seems very, very powerful, I just find it a bit hard to grasp what you can do with it in practice, and what the limitations are. I would be very interested to hear what you ran into so far.
>My intuition is that ambiguities are at least possible, so what about precedence, which AST term is evaluated first? I'm thinking of some situation where two subtrees match the rule, but you end up with different results depending on which is transformed first. E. g. if you were to define a cross product rule, and apply it to a × b × c.
This is absolutely a potential issue, and the examples I have up now are quite bad. This is why it's important for rules to be strictly scoped. The only rules that can affect an expression are the ones you've explicitly brought in with a "using" block, or those that are defined for the types you're directly working with. Given the scoping, I think overlapping rule applications will be uncommon in practice.
>What about infinite loops in rule sets? What about recursion?
There's a sanity limit on the number of times an expression can be rewritten, and it'll show an error in that case which displays the transformations that triggered the limit (including the first, last, and any non-repeating transformations going backward from the last - so it should be very clear.)
>Is there any way to debug the transformations?
This is definitely an area for improvement. I'm planning to (1) add enforced "rewrite this" metadata that will fail to compile if the expression isn't rewritten, and (2) enable dumping not only the final AST but also all of the transformations that occurred.
It seems you've independently rediscovered extensible programming which had seen much research in the past and again a few years back. There have been a number of languages that did same thing as in your tweet (e.g. [1]) but most aren't developed anymore.
Neat, another one for my list. Seed7 allows the extension of the grammar [1]. The compiler understands a simple EBNF which doesn't distinguish between different non-terminals. The semantic checks and the transformation into a known AST are deferred to another stage.
Does the compiler build the initial AST based on a grammar, before the transformations happen? That would mean you can't expand the grammar with user-defined rules. The reason you can "implement for loops in user land" is because they're already part of the grammar, is that correct?
How abstract is that initial AST? Can you use these rewriting transformations to expand the grammar?
That is correct. I think there are tradeoffs in making the language too extensible; in this case it's changing some of the details but not the high-level semantics of how the language works. If every library looked completely different lexically, it would be a nightmare to reuse code. Users of Rust macros may already start to feel this; many libraries are implemented as essentially DSLs.
With that said, down the line I plan to add procedural macros, and those will likely be lexical (they take a series of tokens as input, which doesn't need to parse into valid AST.) If I do go that route, such macros would have to be invoked explicitly.
Well designed language! I particularly like that you took great features from Haxe such as Abstracts. So far i didn't see any WTF!?'s in the language syntax, which is rare these days. People these days can get too inventive when designing new languages. I like that you kept things readable (looking at you Rust :) . Nice work!
If it is truly embeddable in a C program (there was some note about using this as a library in a C program), then this would be a fantastic way to augment development of software in C -- it seems to improve on the C programming language. I like the support for generics and type inference and have always wished C had that. The C interop story looks very good too.
I commented on Zig elsewhere in this thread. Since Jai is unreleased I don't know a lot about it, but their AoS/SoA convertibility was an interesting feature (you can do this in user space in Kit via term rewriting) and I wanted to make it similarly ergonomic to pass around custom allocators.
Interesting language! I saw a "throw" in an example, but I don't see exeptions mentioned anywhere? Woulb be interesting to know why a language with performance focus has exceptions (or are they implemented differently?).
Good "catch" ;) "throw" in Kit is vestigial; there's no error handling mechanism implemented yet, and I've gone back to the design phase to consider some alternatives.
This is the first language posted on HN I like. Really nice. How is utf8 supported. What about graphical apps? Android? Web server? How's the performance?
Another "too many programming languages" comment. God! I have no idea - what's happening to the world?
Are people not skilled enough to evaluate new languages?
There are new type systems and static checks, integrated build systems and package managers, backwards-compatibility features, debugging tools...
What is the primary reason to complain about new programming languages?
C++ had a purpose though, to create object oriented C. A lot of these modern languages seem to be mainly made because someone could.
With so many there is also a very low chance of any of them actually picking up because the useless ones drown out the C++es.
I think people should do what they want though. If you want to make a programming language you should, just don’t expect everyone to view your endeavors as useful.
As far as your fifth point goes, new languages aren’t a good way to influence programming in general. Stuff like lambdas weren’t born in some hipster language, they came from JavaScript. Because if you want to influence, you have to make sure people actually see your stuff.
That being said. Making a PL language is a much better use of your time than whining on HN.
> Stuff like lambdas weren’t born in some hipster language, they came from JavaScript.
They did not come from JS. JS took them from Scheme. Scheme took them from ... lambda calculus? Anyways, not knocking on JS, but they did not invent lambdas by any stretch of the imagination. I do agree with the rest of your comment btw.
>Stuff like lambdas weren’t born in some hipster language, they came from JavaScript.
Lambdas predate JavaScript by decades. Basically according to your reasoning JS shouldn't exist. It was created by Netscape to compete in the web browser market with Microsoft script language the moment you had Python, Ruby, Pike etc. There were no afaik novel concepts to be found in JS.
Before JavaScript embraces lambdas, everyone thought they were a bad idea. You could say something similar about jit.
I know JS gets a lot of hate on hn, but if you look at the history of a lot of modern pl paradigms, many of them got traction after years of ridicule because JavaScript brought them to the masses.
JS didn’t invent lambdas, it made them popular. Or is it just a coincidence that every major language that didn’t have them, adopted them after they got real use in JS?
As far as I know, Lisp was the first language to actually implement the idea. I actually struggle to think of any language concepts that were introduced by Javascript.
I also tend to disagree with the overall sentiment that new languages aren't a good way to influence programming. Haskell, for example, is quite a departure from a language like C. I don't think we would've ended up with the great, proven options we have today if everything was just incremental changes on some base. Sometimes you need to rethink things from scratch. It's part of the reason we don't have one language that fits perfectly for all problem sets.
C++ initial purpose was for Bjarne never to write plain C code, after his experience rewriting his nice Simula code into BCPL, he swore never to use such low level languages again.
There are plenty of interviews where he tells how C with Classes came to be.
Suspect that in the majority of cases it's a bit like people inventing their own (human) constructed language - it's an interesting intellectual exercise in its own right and allows the inventor to indulge in a bit of wish fulfilment by emphasising features that they personally value.
As in the human conlang case, it would be alarming or bizarre if the inventor genuinely expected others to start coding in their language, especially if it has no compelling features that are not found elsewhere: although Perl, C++, Rust and others came primarily from motivated individuals "scratching an itch", those langs were able to flourish because they fill(ed) an empty evolutionary niche.
What I do find peculiar is other people then piling in with all sorts of suggestions for enhancements and tweaks that imply that the particular hobby language in question does have a legit future out in the field.
Rust, Go, Swift, etc... are like super-tankers compared to those small "better-C" languages. IMHO, having a number of small languages that can be learned in an afternoon is much better than yet another super-tanker designed by huge consensus-driven committees/communities that try to do everything for everybody.
Rust has safety and zero-cost abstractions at it's core, they provide a by now quite stable interface. You can't just move fast and break things. You need to stabilize at some point or it's impossible to use it in real world projects that are also commitments of a certain kind. And for that stability you need some kind of consensus of what to work on and what not to do.
I think the primary value of these new toy languages is they can explore aspects freely that can't just be explored in a more mature language. Sometimes after a concept has proven useful a mature language might be willing to incorporate it.
But I wouldn't use them on a serious project, because there will probably be few libraries and maybe no long term support for it.
These are valid concerns, particularly stability and long term support. Availability of libraries applies less to Kit or Zig thanks to first-class interoperability with C. I think this is the way forward for small new languages; you can avoid the challenge of creating an entire ecosystem for your language, and just fit it into an existing one.
I'm surprised that you would lump Go in as a "super-tanker" language. I find it incredibly small and simplistic when compared to something like Rust. I think it actually has fewer keywords than C.
>Are people not skilled enough to propose or send commits to an existing or alternative programming language?
I'll just comment on this part. I'm a contributor to Haxe (not so mainstream perhaps but more so than Kit.) Kit was a chance to try out some features that don't fit in well to Haxe (and in fact I did propose several of these features as additions to Haxe, and they were explicitly rejected.) Sometimes the answer really is to write a new language, because language simplicity is still important and one language can't be everything to everyone.
And of course, Haxe wouldn't exist if its creator hadn't been unsatisfied with existing languages at the time...
I also find the march of new languages a little exhausting. But I handle that by just taking a glance at them and moving on. Kit never has to trouble me again and I'll have already forgotten it by the time I hit reply here. And my life will go on.
> What is the primary reason to create a new programming language?
The reason is that creating a new programming language is easier than learning C++.
For this same reason none of these languages will ever amount to anything useful. If you have the patience and foresight to bring a new programming language to fruition, then you have the patience and foresight to learn C++. You grow up and start programming in a real language.
What design decision and features were made according to that? Basically, what "designed for game development" means?
Also checking the commit history, first commit [1] says that it is after a rewrite in Haskell. What was the original language and why made the change?
[1]: https://github.com/kitlang/kit/commit/4d3de98f218f2427529ac4...