It’s silly that these threads instantly devolve into weirdly personal socio-ideological debates about the merits of the designer, his personality, the community, and his unorthodox approach to the language rather than even a technical discussion. It seems like cloutchasing all the way down.
I also recognize that I am participating in said dynamic.
I think that the only purely technical level complaint I have about the language, something that I haven't seen discussed in the docs but bit me because it worked differently than I expected is that return types are not part of a function's typing. Ie, when doing function polymorphism, functions "a :: (b: s32) -> bool" (a function called "a" that accepts a signed 4byte int and returns a boolean) and "a :: (b: s32) -> s32" (a function called "a" that accepts a signed 4byte int and returns a signed 4byte int) trigger a compilation error when you call one of them even if the type of the lvalue is known (either bool or s32).
How is criticizing the creator of a project a form of clout chasing? It seems important to know the philosophy of the creator of a project, especially when that project is not yet finished.
I don't know (and really don't want to know) the philosophies of any of the people who've made most of the things I really like. The artist is different from the product.
I’m not talking about that kind of philosophy, I mean their development philosophies, the kind of things that would directly impact the directions they take the product in.
This is meant as more of a general comment than to critisize this editor: I fail to see the selling point of an editor that "can't do much", but is performant - there is an abundance of these already. If you made an editor that does "everything" and is "fast", I may be interested.
Regarding Jai: the idea about a "language for good programmers" is just about the worst thing ever to say about a language and it's community in my opinion (and I'm being paid as a C and C++ programmer for 20 years now, so I guess I'm at least not totally bad at it).
GO was named a language for bad (not experienced) programmers by its creator.
I don't see why doing the reverse of that automatically egregious
I mean sure, people are in general hesitant when someone calls himself good, and for a decent reason.
But pushing it to extreme and defaulting to reverse JUST BECAUSE someone dared to call himself good is also a pretty childish reaction.
At the end of the day it is a fact that there are differences in skill between programmers and different languages expect from you different levels of understanding. Pretending it's only valid to acknowledge these differences in others but not in oneself is irrational.
Ok, so let me be a bit more concrete: I do _not_ want to work with or have to maintain or use the software of people who claim of themself to be "good programmers" who are "able to handle manual memory management" (and similar) any more. Yes, of course there are exceptions and I'm not saying that John Blow isn't one of them and I also don't know if the formulation is his or of somebody else (as I don't know anything about him or his games). But the problem is that now people are drawn to the language to "proof" that they are "good programmers".
> Pretending it's only valid to acknowledge these differences in others but not in oneself is irrational.
I do hope that we can agree that people are way better at assessing others than themselves - in both ways, under- and overestimation of their own capabilities.
I think the original point was misunderstood/twisted over time.
TL;DR Inexperienced != Bad
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
What Pike meant is that a company (e.g. google) cannot hire only people who have deep understanding in subtleties of advanced programming language theory and had the time to go through a long learning curve to actually reap the benefits of these advanced programming languages.
These young engineers are not bad, quite the opposite they are usually bright and brilliant young engineers
The problem with that kind of people is that they will use their cleverness to build complicated and beautiful stuff, but when combined with a lack of true and deep experience due to them being still young, this can become counterproductive.
Sure, 'good' and 'bad' are inherently (too) simplistic descriptions.
But imo, if we take the context in which J. Blow calls himself (and user of his language) "good" programmers in good faith, then it would be natural to call those fresh googlers 'bad' (again, in the same context of meaning for 'good' and 'bad').
Not because they are inherently worse people and aren't talented - but simply because the reason you state yourself - they just don't have the experience to tread the fine line of using a super powerful language "properly" (YET).
I disagree. The context that Jon uses is bad = careless, good = careful in the sense that I will make sure I deallocate my pointers.
Pike's argument is not about new hires being careless or incapable of writing tests or understanding dangling pointers and all that stuff.
The whole thing about memory safety is an external requirement to the whole discussion that Pike was starting. At the time it was already well understood that most security vulnerabilities at Google were caused by bugs around memory accesses and that even the most experienced engineers weren't immune to those.
What Pike was talking about was: among the solution space of programming languages that can address those issues, some require a lot of training, whole others are simpler to pick up and yet "good enough".
Rust is an example of a language that is solving the problem in a way that doesn't give up performance, but it does require a steeper learning curve. Pike argued that Google would benefit from a language that would require such a learning curve.
The tradeoff will change with time. Now that rust exists an argument can be made that there is sufficient learning already spent
I always interpreted Jon Blow “good programmer” = “cares about the craft”. Someone that knows deeply the tech stack and understands the tradeoffs made for each decision as opposed to those that just follow fashions and dogmas without evaluation (Object oriented, garbage collection, web framework du jour…). That’s my interpretation after following Jon for a while. could be wrong.
That's true. The modern day obsession with the terminál (emulátors) is something I don't get either. But I actually did use Unix back than (mostly Irix, which was the MacOS of it s day).
Jai is an amazing language to work with, I highly recommend checking it out once it becomes publicly released. It's elegant, simple, performant, takes all the best parts of Zig minus the annoying parts (like errors on unused local variables) and adds a bunch of super useful game development libraries as well as a built-in string type (which I really missed in Zig).
Oh, and the compile times are just a joy, almost no other language even comes close to the speed of iteration that's possible with Jai, which is another great reason to use it for games and prototyping in general.
I'd have preferred a `fun` (or `fn, if you insist on 2 characters) instead of the Haskell-esque double colon `::` in function definitions to make parsing them easier. And the semicolon after `case` is irritating for me too.
But `foo := bar` for a type-less `foo: TYPE = bar` is too much parser-friendly syntax and inconsistent with using a double colon `::` for function types and struct definitions. And inconsistent with using just the colon in `foo: TYPE`.
How do nested for-loops work, if `it` names the current iterator?
for particles {
// Inside for loops the "it" object is the iterator for the current object.
particle_left := view_left \* it.particle_size;
}
> Just like every language that implicitly names the current value of the iterator
Oh, i didn't know that there are any.
It would be a good idea to add the naming explicitly to the Wiki entry of loops: https://jai.community/t/loops/147, I've just found it buried in the `remove` section.
Btw. in for-loops the colon `:` is used inconsistently again, this time for naming the iterator (`foo` in this example:) `for foo: VALUES { ... }`.
Plenty! Although, it's not limited to iterators: most languages that have first class lambdas/closures behave this way. Kotlin has `it` as the default parameter of any lambda (but only accepts it for single parameter lambdas, two parameters and you need to name them:
>Btw. in for-loops the colon `:` is used inconsistently again, this time for naming the iterator (`foo` in this example:) `for foo: VALUES { ... }`.
Sorry, Jonathan Blow doesn't believe in such silly things as "compiler research" nor "programming language research". Jai gets built by piling up crap on top of crap.
Talking about closures, I also don't know why Jai needs explicit capture lists. In C++ and Rust I understand the need for them, because you have various ways to pass them into the lambda, but Jai doesn't seem to care, at least in the examples at https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md....
To be honest, I also don't see how this is different from just writing the function definition by hand, just in more than one step and you have to throw away the intermediate versions?
Btw. I just replied to say that I really like your username, I have noticed it just now :)
Yeesh, that's good to know. With the dev response basically doubling down on ideology and ignoring reasonable protest, that's definitely an ecosystem to not sink time into.
Blow is a smart guy who thinks he's far smarter and far more interesting than he really is. Smart people who don't seek out feedback, and especially those who haven't worked in a team environment, tend to be pretty bad at estimating the limit of their capabilities.
Does Blow have a mentor? Friends who call his BS out?
He does seek feedback, that is why there is a closed beta. I would say he is quick to flip the bozo bit, and easily irritable, but that is also a consequence of having an audience that is large enough to be annoying but too small to just ignore.
A good number of your bullet points are factually incorrect and inflammatory. But to reply in the style of Blow: what have _you_ released in the past ten years to talk all this smack?
I'd say my work has gone in the hands of a few million people and made their lives (mostly) better, along with what all of my coworkers did.
But most importantly, I'm not out there telling people that they suck, they're bad programmers. I'm not the one out there telling people that GC bad, memory ownership bad but also you're stupid if you can't free() memory properly. I'm not the one out there rejecting decades of PL theory, calling academics "believers" and "wrong" [0], I'm not the one throwing shade at every other language, and when criticized on my language, fall back to "uuuuh I make Jai for myself you don't have to use it"
Anyways, if you want a real systems language that's available today and that actually works, Odin exists.
Don't they get tired of being wrong, too? I've used software from these types of people and their stuff crashes and segfaults as much or more than their equivalents, certainly than the rust equivalents I use.
Please don't adopt this line of reasoning. Anyone's argument doesn't have to stand on their personal achievements and public works. Just because you're not a chef doesn't mean you can't call one out if they put rat poison in your food.
I didn't ask for evidence because I know for a fact that he is lying or misinterpreting things to an extent to be considered lying.
Getting into the beta has nothing to do with being a good or bad programmer. It's not about Blow's ego or criticizing the language, it's about keeping a modicum of respect about a decade's worth of work and not being an ass.
If the ad-homimem's didn't disqualify his whole post, the smell of his butt-hurt would.
PS. As a factual contradiction, documentation is provided with every compiler version and it currently stands at ~32K lines of very well commented example code touching almost every feature of the language.
No you can not apply via twitch chat, and again, there's no genuflecting. Stop listening the assholes with axes to grind. You can ask about it in twitch chat and probably get an answer, but I think you must show an interest more than "I heard about this thing on HN, I want to try it NOW".
Can you clarify? How is showing interest "genuflecting"?
I understand how open-source has lowered the general threshold for having access to other people's work, but the entitlement your post exudes is a bit sickening.
These aren't the kinds of things where evidence is readily available. If you have a reputation to stake on certain claims, that makes me more inclined to give you the benefit of the doubt.
Why is it that you want to tone police me (when I was actually trying to be facetiously funny) instead of parent with his virulent ad-hominem's towards two industry veterans which probably have done more for the field of computer science than most of us commenting in this thread combined (at least until Walter drops in).
Given that the compiler for this language is not publicly available, is this still open source, considering that you cannot easily modify and rebuild it to your liking, despite being GPL?
GPL (I'm not talking about AGPL) only forces you to publish the sources if the binary would be published. If you don't have the program you don't have a right to the source.
The source code to the program is available, but the compiler with which to compile that code isn't.
To the OP I would say this is opensource.
If you received an open source recipe, despite not having a kitchen you could still modify the recipe, pass it on etc.
You still have the right to modify this code and pass it on, which is what the opensource licenses generally guarantee, opensource software for the latest supercomputer doesn't guarantee you access to that supercomputer.
This is my first exposure to Jai code, did not know it was now available to play with! Congrats on building this! Really appreciate your comments in the source.
It's interesting to look at the source code. However, I have yet to find a clear unique selling point that justifies the development of a new language and infrastructure, or clearly shows me why I shouldn't just use D, for example. Any hints?
Jai has a few unique features that are quite interesting. You can think of it as C with extremelly powerful metaprogramming, compile-time codegen and reflection, and strong template systems, plus a few extra niceties like native bump allocator support or things like easily creating custom iterators. There is nothing quite like it.
Thanks. I guess the "extremelly powerful metaprogramming", "compile-time codegen" and "strong template systems" are essentially the same thing. So the unique selling point of Jai from your perspective would be "C with generic metaprogramming, iterators and reflection"? Besides reflection, which is quite limited in C++, this would essentially be a subset of C++, isn't it?
Cpp goes nowhere to this level.
Jai templates execute normal code (any code) at compile time, so there is no need for sfinae tricks or others, you just write code that directly deals with types.
You can do things like having structs remove or add members by just putting the member behind an if branch. You can also fully inspect any type and iterate members through reflection. There is a macro system that lets you manipulate and insert "code" objects, the iterator system works this way. you create a for loop operator overload where the for loop code is sent to the function as a parameter.
It also lets you convert a string (calculated compile time) into code. Either by adding it into the macro system, or just inserting it somewhere.
Some of the experiments ive done were implementing a full marc-sweep GC by generating reflection code that would implement the GC sweep logic, having a database system where it directly converts structs into table rows and codegens all the code relating to queries, automatic inspection of game objects by having a templated "inspect<T>" type thing where it exposes the object into imgui or debug log output, fully automatic json serialization for everything, and an ECS engine where it directly codegens the optimal gather code and prepares the object model storage from whatever loops you use in the code.
All of those werent real projects, just experiments to play around with it, but they were done in just a few dozens/hundreds lines of code each. While in theory you could do those in Cpp, it would need serious levels of template abominations to write it. In jai you write your compile time templates as normal jai. And it all compiles quickly with optimal codegen (its not bloating your PDB like a million type definitions would do in cpp template metaprogramming).
The big downside of the language is that its still a closed private beta, so tooling leaves much to be desired. There is a syntax color system, but things like correct IDE autocomplete or a native debugger arent there. I use remedybg to debug things and vscode as text editor for it. Its also on relatively early stages even if its been a thing for years, so some of the features are still in flux between updates.
That sounds interesting; seems to be even more flexible than comptime in Zig, almost as powerful as Lisp and the MOP. How about compiler and runtime performance of these features?
EDIT: can you point to source locations in the referenced projects which demonstrate such features?
https://pastebin.com/VPypiitk This is a very small experiment i did to learn the metaprogramming features. its an ECS library using the same model as entt (https://github.com/skypjack/entt). In 200 lines or so it does the equivalent of a few thousand lines of template heavy Cpp while compiling instantly and generating good debug code.
Some walkthrough:
Line 8 declares a SparseSet type as a fairly typical template. its just a struct with arrays of type T inside. Next lines implement getters/setters for this data structure.
Note how std::vector style dynamic array is just a part of the lang, with the [..] syntax to declare a dynamically sized array.
Line 46 Base_Registry things get interesting. This is a struct that holds a bunch of SparseSet of different types, and providers getters/setters for them by type. It uses code generation to do this. The initial #insert at the start of the class injects codegen that creates structure members from the type list the struct gets on its declaration. Note also how type-lists are a native structure in the lang, no need for variadics.
Line 99 i decide to do variadic style tail templates anyway for fun. I implement a function that takes a typelist and returns the tail, and the struct is created through recursion as one would do in cpp. Getters and setters for the View struct are also implemented through recursion
Line 143 has the for expansion. This is how you overload the for loop functionality to create custom iterators.
The rest of the code is just some basic test code that runs the thing.
Last line does #import basic to essentially do #import stl type thing. Jai doesnt care about the order of any declarations, so having the includes at the bottom is fairly common.
Dunno about runtime performance, but compiling speed is something that's regularly mentioned as an important aspect of Jai and I think it's not an exaggeration to name it as one of the fastest languages when it comes down to comp speed.
So, it is like Nim?
Templates, metaprogramming, custom iterators, Nim's comp-time is also powerful, but I heard that 100% of Jai is available at compile time?
How good is interop with other languages?
Does Jai's syntax have some nice features?
Syntax sugar like Nim's UFCS or list comprehension (collect macro in nim)? effects system?
Functional paradigm support?
Yup if I would pick a language that’s closest to Jai I would choose Nim. Both have a bytecode-VM interpreter to run comp-time code (unlike with Zig where it still tree-walks the AST), have similar template codegen systems (though Nim also has AST macros), and has good interop with existing C/C++ code.
The one issue with Nim I had while trying it out is that there is an incredibly rich amount of features but many of them seem half-baked and it’s constantly being changed, so you’re always a bit unsure what’s a feature stable and safe to use or is “experimental”. But at least it’s been public for quite some time and you can actually use it right away…
Personal preferences should be enough to choose a different language or create a new language (e.g. it can be as simple as "I don't like D"), in the end that's how progress happens, individuals not being happy with the status quo, and building something they like. If others like that thing too, it might even become popular (and if this happens without a big company behind it then that thing might even be objectively good).
(I'm not a fan of Jai's closed development model though, but to each their own)
Maybe when it comes to learning compiler construction. But otherwise, what's the point of all this effort if the result is hardly different from anything existing? Some innovation or other special feature justifying all the effort to implement the language and toolchain and for the interested parties to adopt it should at least be present. I would still be interested to know where this can be found on Jay. Any hints?
In the end it comes down to healthy competition, it doesn't matter much why one thing is better than another, it just has to be preferred by enough people. And all those people may have different opinions on why they would choose one language over another. Traditionally, there has been a real lack of "better C" languages. Now since a few years we suddenly have a number of promising options but still not enough: Odin, Zig, Jai, and a few lesser known like C2 and C3, that's about it - I count Rust and D as attempts to a "better C++", not a "better C" (I'm aware of D's "das better C" subset though).
Apparently Jai is specifically tailored to game development problems and frustration with C++ for game dev (or at least it tries to fix rough edges that a typical game developer encounters in existing languages used for game dev) - whether that is actually true I can't tell though since I haven't used Jai yet.
> Now since a few years we suddenly have a number of promising options but still not enough
Well, but how do you recognize that there are still not enough options? I assume it should be a bit more specific than just a feeling or "personal preference", isn't it?
> Rust and D as attempts to a "better C++"
Rust has at least one big unique selling point which was not present so far in any other language (at least I'm not aware of any one): compile time automatic memory management. The unique selling point of D in contrast is not that obvious, at least not to me.
> whether that is actually true I can't tell though since I haven't used Jai yet.
> how do you recognize that there are still not enough options
One language that's still missing is a simple C-like language that offers Rust-style memory safety but without Rust's design philosophy of repeating every C++ mistake (that's not about memory safety) and high level type system wankery (or generally too much influence from functional languages).
There are also many more areas still to explore when it comes to memory safety that are less extreme than Rust's approach (I completely forgot about Vale which tries out some really interesting things in that direction: https://vale.dev/)
It would most likely need to 'break' C in a way that it wouldn't be recognisable as C anymore or at least break compatibility with existing C code (e.g. removing pointers, or at least pointer arithmetics, and the way pointers and arrays interact).
Not necessarily; the compiler has to trace ownership anyway and could also detect "legal" use of pointers and reject certain uses for objects under the "borrow checker regime", as Rust does it. But of course one could take a subset of C and augment it with the new features, as it was e.g. done in C++ in the eighties or Simula (with Algol) in the sixties; the obvious advantage is the similarity to the original language and (potential) reusability of a large existing code base.
> Traditionally, there has been a real lack of "better C" languages.
There never has been. There has been a lack of really successfull C alternatives for some time (after everything that wasn't unixish or Windows died, except for MacOS and Objective-C) - and still is. Rust is still less used than Pascal has been 30 years ago.
No language is perfect. There is nothing wrong with making your own that works the way you want a language to work. I don't get people who complain about new languages. Variety is good. Let people have fun.
I think it's not up to us, the peanut gallery, to judge what any particular developer spends their time on. It's worthwhile to Blow, and he is very vocal that he is developing the language for his own use, not for anyone else. If you keep that in mind, maybe some of the choices around how it's being developed will make more sense.
I'm a language implementor myself and just asked for a clear unique selling point of Jai, and guess what, there was indeed one fellow here who didn't question the question, but has personal experience and was able to give me the information I was interested in (see https://news.ycombinator.com/item?id=37369342), without me having to read or listen through dozens of outdated blog posts and presentations. I still think a language specification would be worthwhile, even during early development.
From what I understood from Blow, a specification at this point would only serve to have other people bike shed about syntax, features, etc.
Looking at the explanation you linked, I would say that the author uses the language in a very unidiomatic way (if idiomatic Jai would be a thing :D). It takes a very template focused mindset and uses the features of the language to bastardize and complicate things needlessly (IMHO, as a not game developer). I think my main take away from the language is that it focuses on the way memory is mapped (similarly to how C does it) and less on behaviour associated with that memory.
So for that example, instead of trying to overthink a container that uses a generic behaviour through templated types, it would implement different overloaded functions for each type as needed.
> a specification at this point would only serve to have other people bike shed about syntax, features, etc.
It makes little sense to announce a language with a lot of details over so many years without providing a decent specification. Either the author is interested in feedback, then a specification or language report is the established vehicle among language designers, or he is not interested in feedback, which raises the question why he publishes any details at all.
> It takes a very template focused mindset and uses the features of the language
But as it seems that's a focus point of the language; why otherwise the author would take the effort to even modify structure declarations with compile time expressions.
> that it focuses on the way memory is mapped (similarly to how C does it)
What do you mean by that? And is this really a unique selling point if it is similar to C?
I offered a very bird's eye view of what a newbie understood from the language, not a "unique selling point" because, like I keep failing to make you see, Blow is not trying to "sell it" to anyone.
I think there is a very clear open spot where Jai fits in otherwise why would google be doing the same thing with their carbon language. People want a better c++. It should compile fast, have all the low level stuff of C. Have Metaprogramming and introspection and including a decent library for basic stuff would be nice too.
What this really reads to me is why not just use Rust. Rust is useful for the things Rust was designed for. Some people love it and think its the greatest language out there and that's fine but a lot of people have used it and they either do not like it or they like it but they wouldn't want to use it for the type of work they like to do.
Having more languages and each influencing another is the only way we can get better and better languages.
To answer specifically about D, I think Blow considered it and couldn't get past the garbage collection (this is mostly inferred). As a matter of fact I heard of Jai through a presentation of Walter Bright's, so I'm pretty sure was definitely some back and forth between the two.
Either ask very politely for years, or be in denial like half the Jai community that writes Jai but is never able to compile it.
Yes, there is a whole Jai community wiki made from half cobbled together knowledge (https://github.com/Jai-Community/Jai-Community-Library/wiki), and a super secret discord made for the super elite, non-compiler-having plebs are banned.
I also recognize that I am participating in said dynamic.