I don’t understand how this language is planning on ever seeing adoption when it’s been restricted from open use since it’s inception. Seems like vaporware.
I think Jonathan Blow's main goal is to make his dream game programming language so that he can be happier while developing all of his future games. Widespread adoption by others is only a secondary concern. He also doesn't want to push it out to the general public until he feels it's ready, and wants to take the time to get it right first.
Jonathan Blow is a skilled craftsman with stuff like this and he knows he's going to get a bunch of Opinions About His Language from people who think they have a complete superset of his knowlege, and he is making his language without involving those people in any way.
That’s fair, but if you look at his posts about the language, he also makes a big point about how he doesn’t want any input from people with an academic background in language & type theory. This smells like anti-intellectualism to me.
I’m a bit concerned that some of the decisions that he’s making in the language are leading towards traps that have caught other language designers in the past, but because he’s rejecting that expertise, he has to learn from experience, at greater cost. These concerns are motivated by specific things I’ve seen in Jai code, but I don’t really want to dive into the specifics, since Jai is unavailable.
I think his disdain towards academia isn't really anti-intellectualism (he's not ignorant of compiler theory knowledge, otherwise he wouldn't have been able to write a compiler from scratch in the first place! And his interest in programming languages seems to span decades, from what I remember from one of his streams). I think he's critical of the fact that the primary focus of academia and industry in computer science have diverged so much over the years, such that most academic CS works haven't really helped developers in building better programs and tools. Thinking about the countless hours compiler academics have spent on all sorts of esoteric parser theory in the past, while all the production compilers today are using recursive decent for pragmatic reasons... maybe this kinda makes sense.
I’d have to say that academic research into programming languages has provided immense benefits for actual programmers over the years, it just has such a long lead time that people forget that the research came out of academia in the first place. People also don’t really understand the process of how these ideas come from academia into mainstream programming languages.
It only seems like academic research has diverged because the benefits of current research haven’t materialized as real, usable features in programming languages that people use to get work done. But if you look at features that we use in day-to-day programming right now, you can trace the heritage of these features back to research programming languages (like Self or Haskell) and then farther back to more abstract research into esoteric subjects like category theory and substructural logic.
The esoteric parsers that people invented in the past were, in a sense, necessary because people were ignorant of how to design languages in such a way that they could support a rich syntax without using a complicated parser. It took a lot of academic research for us to figure out that, say, you could probably use an LALR parser for lots of existing languages, and you could stick to LL(1) for new designs.
That's a fair point. Maybe researchers needed to delve into all sorts of weird parser theories, to later figure out that they weren't that needed. Practicioneers mainly know the final result, but aren't usually interested in the full history of how people got to that conclusion.
But I think during the recent decades, there has been a consensus that perverse incentives in academia are degrading research quality and preventing papers from becoming actually usable in real-life applications (mainly with the focus of paper metrics and the constant need to apply for grants). So although I think academia is still important long-term, I understand why some people would think it's becoming less useful.
Actually that's probably under-selling the problem. It's not just that Jon doesn't value the opinions of academics, he doesn't really value the opinions of anyone except Jonathan Blow.
Which is probably a healthy way to attack your first video game project, it's not as though Braid would be more likely to be a success if Blow stopped believing in it himself. But I would be surprised if that's true of a programming language.
> most academic CS works haven't really helped developers in building better programs and tools
It's doubtless possible to measure "most works" and "really helped" in ways which allow you to either draw this conclusion, or not, as you prefer but I don't think that's a useful way to think about it at all.
it isn't anti-intellectualism at all, it's that he gets asked questions by people in college as well as college grads continuously and the questions they ask are indicating that the things being taught in higher education are absolutely not the kinds of things that he sees in his day to day work.
to be fair to Jon, he works in a subset of software development that most do not: video games.
the kinds of problems that Jon sees do encompass the things that we all see, since he uses the same operating systems that we do, the same compilers, and just generally the software available to him is the same as what is available to all of us.
where the experience of a game developer really differs from that of, say, an enterprise software developer is the complexity of the problem being solved and the speed at which the problems in games must be solved. additionally, it is trivial to compare two games of the same genre and determine which looks better and which feels better. so, performance and quality are of prime importance to a game developer.
game performance and playability directly correlate to game sales in many cases, and game sales directly correlate to employment as a game developer. game developers want to create games specifically, so they want to continue working as game developers. so, they want to create successful games, so they want to create games that perform their best and that look their best so that more players purchase the game.
Enterprise and commercial software developers simply do not have the same types of pressure on them. It is perfectly fine for an enterprise software developer to use object oriented code which consumes 8 bytes of network capacity to transfer a single boolean value because the performance and latency of enterprise applications does not impact their use except in extreme circumstances.
game developers will redesign lots of their types to net a 2 byte savings on a data structure if that is what it takes to keep a full multiplayer game update in a single 1492-byte network packet and avoid packet fragmentation. game developers will spend 200 hours changing their data structures so that they fit more efficiently into CPU cache lines and they will change how game logic is processed so that they miss the CPU data cache as little as possible, because CPU cache efficiency directly relates to performance on almost all modern platforms. these are problems that simply do not exist within most enterprise's software development teams.
and because those are problems that do not exist for enterprises, those are problems whose nature and whose solutions are not taught at University.
Jon has been a game developer for almost his entire career, so he sees things differently than people on this website. people who work at startups and seek angel investment so they can scrape by long enough to deliver an MVP and be purchased have wildly different priorities than a game developer who wishes to succeed as a game developer.
in general I think the wider software development community could learn a great deal from game developers. the software written by developers who are not game developers is almost unilaterally unacceptably slow.
Most general purpose software developers simply do not have the experience to understand how egregiously bad most general purpose software is. Jon does. and his complaints regarding academia reflect the reality he sees.
I think I’ve never heard someone romanticize a profession as hard as what you’ve done here. This comment paints a truly distorted and unrealistic picture of game developers.
Game developers are not radically different from other developers. You see game developers leave the game industry and become programmers somewhere else, or you see programmers in another industry become programmers in the game industry. It is not a big deal.
While you could find some game developers who care about saving a couple bytes to fit something in a single network packet, you can equally find developers elsewhere who care about the same thing. Shave some time off your latency numbers and people stay on your website or app, they buy things or watch ads, your company gets money, you put it in your performance review. That’s just the most boring example I could think of. There are more interesting examples. Most programmers are simply not interested in saving a few bytes or a few cycles because they have features to work on. That includes game developers.
We fetishize low-level programming too much. Low-level programming is, in a sense, easy, because you are working with components that are simpler and have better documentation.
never in my 30-year career have I witnessed a single non-game developer give a damn about the latency or responsiveness of any application they've written.
never in my 30-year career have I witnessed a single game or emulator developer STOP caring about these things.
> I think I’ve never heard someone romanticize a profession as hard as what you’ve done here.
Go fuck yourself. it isn't me romanticizing, it's you thinking you know more than others by default, and outright dismissing the viewpoint of others. go away from me and stay away.
I work in telecoms, we do care a lot about latency, HFT guys are the same.
Some parts use FPGAs instead of normal hardware due to the low latency requirements!
OTOH I remember when one man doubled the framerate of a Nintendo game: apparently not all game developers care so much if they leave so much performance unused..
I had been a game developer for last 7 years and I disagree. Most game developers do not have that much expertise to start with, because it has been a long time that low-level optimization makes or breaks your game. They tend to lean to proven techniques to the point that they have consistent aches like your aging grandparents but still keep using them because complaints alone don't break their games. The ratio of game developers capable of optimizing things at that level is roughly same to (or possibly even lower than) the ratio of comparable non-game developers.
Over the past decade, I watched HN's and Reddit's hype waves cycle through server-side JavaScript, Golang, Haskell, and now Rust. With plenty of secondary favorites in the mix like Julia, Nim, Zig, etc.
A lot of these things do find some modest niche to survive in. But none really take over the world as originally forecast by the hype wave.
Ultimately, you either enjoy tinkering with programming languages for personal enrichment, or you do not. Hardly anyone is actually using anything else at our Java/C#/Python/C++ day jobs.
I don’t think Go was ever especially over-hyped, and it has been pretty wildly successful in its “niche” (server side programming, CLI tools, daemons, etc). There was some controversy because someone said it was for “systems programming” by which the author seems to have meant “distributed/networked systems” rather than “operating systems” or whatever most people mean when they use the (very imprecise) term “systems programming”.
And to that extent, Go has been very successful (virtually the entire container ecosystem and a good chunk of the broader cloud ecosystem). It is doing a lot of stuff that would have previously been in Java or C# or Python or Node or Ruby (contrary to your “hardly anyone is actually using anything else…” remark).
Of course, older languages are naturally going to have more jobs because there’s an enormous volume of legacy code that can’t be cheaply translated to a new language, but so you have to look at the distribution of languages among new projects to be able to even begin making reasonable comparisons between languages, and even then a historically Java shop is probably going to give a ton of preference to Java, so here too we see a lot of weight given to older languages irrespective of their merit.
Of course, this is nonsense and people use containers because they deliver real value, not because of Google marketing or name recognition (most don’t even know containers come from Google, but would likely attribute them to Docker). I’m not a container purist—eventually micro VMs and unikernels will eat a lot of their market share (that’s my prediction, anyway), but until we get there containers are invaluable and criticism like yours is devoid of substance.
While I agree with most of your points, I am not sure what this has to do with the parent you're replying to.
The one part I disagree with is:
> A lot of these things do find some modest niche to survive in. But none really take over the world as originally forecast by the hype wave.
One of Blow's critique of C++ is specifically that it's trying to be the everything language. Jai's goal is to be for video game development, and that's it. Not for embedded systems, not kernels, not drivers, not high performance computing, not operating systems. Just video games.
I was surprised to recently learn that embedded isn't on Jai's roadmap. I respect the decision re scope and feature-creep. It was surprising, given that usually languages with the performance, and low-level capabilities of C are also suited for embedded. Ie: The overlap with existing languages is almost 100% when you look at A: Languages that are fast/LL. B: Languages that are suitable for embedded. (The usual suspects of C, C++, Rust, Zig, and ADA)
I imagine that part of that is that he's a video game developer and not an embedded systems developer. I have no experience with embedded systems programming so idk how similar the two are.
But:
1) Lots of things things have high overlap with fast/LL languages.
2) I imagine there are nice returns to focusing the language on a specific use-case, even more so when the core developers are not actively using it for the other use cases (I doubt he or his team will be doing embedded work anytime soon).
I mean this is a little pedantic. It's true he never said that only games are able to use his language as if it were some kind of law, but he did say that his language is being designed to address issues that video game developers face and that was his main, and almost exclusively his only concern.
If other domains benefit from that, he's not going to actively bar them from using his language, but he also won't give them much consideration.
It's just false, i'm in the closed beta and there are a lot of people that use it for other things than games.
When they find a bug or have a suggestion he give them the same consideration as anyone.
Either the word "only" is doing a lot of heavy lifting in your sentence, or you're simply wrong [0].
Yes you could program anything in the language, just like you could programming anything in any language. But he's designing the language for video game development. The whole reason he's making it is specifically for video game development, and he's been very explicit that he believes that a language should not try to be designed for use in every application.
Javascript absolutely took its position. Speaking of those waves, where did Ruby and RoR go? Seems completely dead on HN whereas 'back in the day' it was top most talked thing. LISP would be a guest of honor - always there, never here.
I think Ruby and RoR just didn’t quite survive the transition to much heavier client-side JavaScript apps. Ruby peaked sometime around 2009 and back then, the browser landscape was much more diverse, and it was common to support IE6. It’s easy to forget how much of a burden IE6 was on web developers.
Ruby also suffered from a proliferation of ill-advised programming practices (monkey patching) and there was also some drama in the Ruby community (Rails Is a Ghetto). These were fixable problems and the Ruby community took steps to stop monkey patching everything and maybe address the other problems, but in the end, I think would-be Rails developers started using Node.js, and Ruby fell from the public spotlight.
As far as I can tell, Python survived by virtue of tools like NumPy, SciPy, Pandas, PyTorch, OpenCV, etc. Kind of a universal glue language for people who don’t want to write C or C++. Otherwise, I think of Python and Ruby (as languages) as nearly interchangeable. Python had its own issues to work through (2 -> 3) and its own drama, but it settled in some more stable niches and seemed to have fewer mercurial personalities at the center of it all.
Ruby and Python is not interchangeable, and Ruby is way more powerful than Python, that's a real reason why there is no equivalent of RoR in Python eco-system [1].
Python becomes very popular not by virtue of its tools, but by virtue of its intuitive and beginner friendly syntax. Because of this essential trait the useful tools and libraries are flourishing in the Python eco-system.
You are right that RoR is like a Ghetto and RoR is not considered as Ruby language. On this aspect, I think D has done a good job to ensure that any D based library and framework will still resemble D language. Like they said with great power comes great responsibility, and I'm afraid that Jai will follow Ruby and Lisp becoming untouchable by the mere mortals except only for a selected few domain expert programmers maintaining very niche applications.
I transitioned from Ruby to Python for scripting tasks, with a heavy heart, for the simple reason that linuxes typically have Python installed by default, but not Ruby, which made working with and sharing Ruby code in diverse and often locked-down environments too painful.
Ruby/RoR values form over function. Over the past few (five or so?) years, as teams went through the transition from aggressive feature development to devoting more effort to maintenance and operations, they realized that relying on conventions as a guiding principle has a substantial cost burden that you don't pay when prefer rigor and specification.
The disparity between Rust jobs and C/C++/C#/Java/Golang jobs on Indeed is staggering. Even worse, most of the Rust jobs are blockchain-related and may not survive the coming blockchain downturn.
It may be the case that some people use Rust but without Rust jobs, there will be no pool of experienced developers to later draw on.
I think there is a space for other alternative low-level languages that aren't that strict about compile-time safety though (Zig, Jai, Odin), that Rust cannot capture.
Many proclaim that compile-time safety using type theory is the only way to create reliable low-level software, but I think it can alternatively be done with good data structure design and various compiler tooling that instead catch these errors at runtime (generational indices/references, Address Sanitizer, and recently Zig's safety mode). We need to explore multiple directions to really solve the memory safety problem, and I don't think Rust is the only way (although it is a viable way, proven by some recent successful applications).
You can even get safety using logic without the compiler. I think resource cleanup responsibility tracking as a static analysis tool is likely to happen with some of these languages. I think zig is a good candidate, once they lock down the intermediate representation.
It's already the case that people are using "logic add-ons" for additional rust static analysis, so one wonders exactly why is it generally speaking that borrow checking itself must occur at the compilation step.
Trivially, one could create an annotation layer on top of zig or c that exactly replicates the rust syntax and performance borrow checking in the same way. It wouldn't be exactly the same because there isn't RAII but you can make correct inferences about what is happening in the body of the functions.
Rust will not accomplish this without significant language changes as well as changing cargo into something a lot more cooperative with external ecosystems.
Zig is getting an absolutely enormous boost from the fact that it is a self-contained C ecosystem that can cooperate with others. Zig has tripped into a very powerful niche--a lot of people LOATHE the build systems of the C/C++ world. If Zig gains very much more traction there, it's going to be extremely hard to dislodge.
I suspect that there are FAR more users of "Zig as C build system" than there are of "Zig as a language".
But cargo already isn’t in Rust. There are AFAIK no cargo-specific concepts that have leaked into Rust, the language. It is very straightforward to build Rust code without using cargo, for example with a makefile.
The reason other tools are slow to add support for rust is because cargo is so ubiquitous in the rust ecosystem that there is little point (I’d estimate that >99% of Rust code is built using Cargo), and not because of any technical impossibility.
I think cutting through the hype-train is something every engineer learns with time, but some times there are diamonds to be picked out.
At least for my own anecdotal experience, Rust has lived up to a lot of the hype for the time-critical low-level projects I was formerly performing with C/C++.
Agreed, though I’m sad it isn’t more often used. It’s certainly picking up steam, but it seems to have a ways to go before it’s going to be a serious contender for new projects in the embedded, video game, etc spaces where C/C++ still reign (by which I mean something like “before the majority of new projects are implemented in Rust”).
I’ve also observed these waves, but never about a language that you can’t actually go pick up a compiler or interpreter for. Jai is unique in that sense.
Your links back up the statement.
The first says the compiler is proprietary and unavailable outside of some beta testers, but may be open in the great and nebulous future.
Or Pi, or iOS, or practically all Android hardware… Kind of a non-starter IMO. Maybe this was marginally acceptable when the language started in '14 but it becomes less so every year.
Blow is designing and implementing a language for making video games, and in particular, for making Thekla’s video games (Jon’s game company). Blow does not make mobile games, nor does he make small, retro-style games that would typically be run on a Pi. His concerns are modern Windows gaming PC’s and the big three consoles. While Jai is Turing-complete and is ‘general-purpose’, the implementation serves Blow’s needs first and fioremost, so the chosen targets make sense in light of that.
Given that he and his team are developing a language and a game in that language at the same time it makes sense to focus on the primary platforms they work on, and expect their game to currently run.
Their primary platform is Windows, and the game in its current very early state is also running on Windows.
What's the value in porting it to Raspberry Pi or Android?
From the streams it looks like a Linux port is usually mostly up to date, and MacOS understandably lags behind. But neither of these platforms have any high priority for now.
Yeah, I guess that’s true as far as Blow goes. But there are other people interested in this thing (hence why the OP exists and why we’re commenting on it). And I presume not all of them want to lock themselves in to the apparent dead end that is the x86 platform in the current year when both cross-platform languages and cross-platform game engines are all over the place.
Design by committee vs. design by singular vision is an age old debate. We have plenty of the former, why not give the latter a try? There are plenty of good languages out there already to use, why does this language have to aim for wide adoption?
I'm not sure Blow cares that much about widespread adoption; he seems more concerned with quality. Personally I'd love an open beta, but I can understand why he might want to reserve the right to make drastic changes to the language before he releases it.
If you watch JB's videos (actually they're posted by someone else on YouTube I believe, taken from his Twitch streams), the language definitely exists.
The other niche languages are either buggy, slow, or both. Jai won't be. Ultimately it's about taste and quality. If the language gets enough right then people will switch to it, because people are desperate for a c++ alternative. Open sourcing or early access won't help here. Somebody just has to do the hard work of writing the compiler internals, and it will be done when it's done. And really, I wouldn't bet against somebody who has delivered on big projects twice before.
I agree that it's marketing but not for the 'exclusivity' reason, for the 'first impression' reason.
You'll still hear quite often that DMD is proprietary or that there is no free Ada compiler even though this hasn't been true for many years..
