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.
Keeping two implementations side by side would be expensive to maintain and not a good user experience: you start writing nice, "modern" .NET6 code and then need to rewrite things to run on top of .NET4-ish (and the older BCL and C#).
Mono was largely folded into CoreCLR a couple releases ago and part of that infrastructure is used to support some targets like mobile and WebAssembly.
It has been excellent, best browser game engine imo - however as of Godot 4, the web export is completely broken, unfortunately. Godot with C# straight up has no web export and no mobile export atm, just desktop.
Hmm, something is amiss here... They're already on RC5 and web export not working doesn't sound like the web platform is a focus of theirs. AFAIK, the web export being broken is not mentioned in "Known Issues" about V4 either.
No, it's not fine. It's broken on Chrome for macOS and freezes on startup for about 10-20 seconds. Has nothing to do with C#, this happens with GDScript, too. It's a known issue, has been discussed at length on Github (by myself as well) and there is no fix in sight at the moment.
In the Runtime Changes Section: "Mobile and web platforms are not supported at the moment, and will be worked on for a future Godot 4 release." / "For the mobile platform specifically we are going to use the Mono runtime."
This library is probably the most full-featured, well-documented open source PDF libraries I ever came across. Implementing it right now for a small app I'm building and it's simple & fun to use.
Can't believe it's developed by one single dev and it's MIT-licensed. Really happy this exists, as before this there were almost only paid/commercial PDF libraries in the .NET ecosystem.
> but if you want to cause a so called "paradigm shift" then you'll need to understand where the progress is happening and what kinds of opportunities it creates.
This is the most Hacker News thing I read all year. What are you talking about? Where did he say anything about wanting to cause a paradigm shift?
And I remember when Python, React, Node were all fringe. Until they disrupted the industry. But the important take away is to choose for a specific reason, and expecting a traction in the future. While OCaml might be good for a research project, it is unrealistic it gives you some future advantage. On the other hand, you can see how Rust can give you an advantage right now for some cases. Or even arguable rescript.
Typically, you should not attempt multiple paradigm shifts simultaneously. In fact, I would argue, the more innovative your end user product is, the more boring your tech stack should be.
Facebook was PHP.
Google was C++.
Bitcoin was C++.
Netflix was Java.
Spend your innovation points on your product, not on programming language.
Google is mostly Java and C++, Go has more use outside than on internal projects.
Nokia Networks customers were using a mix of C++ and Perl running on HP-UX back in 2004, and nowadays it is mostly C++ and Java running on Linux distributions. Not every telco is using Siemens Erlang based switches.
Apple created Clascal and Object Pascal, migrated to C++, got Objective C via NeXT acquisition, which previously licensed it from StepStone. They also created Mac Lisp, Hypercard, Dylan and Newtonscript.
Microsoft used BASIC for a looong time, dabbled with Pascal, had one of the best macro assemblers in the market, was the last MS-DOS vendor to actually add C++ support to their C compiler, focused on VB and C++ until .NET came to be.
I can definitely say that for me, this is the straw that breaks the camel's back. I am turning my back on the .NET ecosystem, after having written C# for 7 years. The `dotnet watch` debacle from last year, still having key parts like the debugger closed-source and now again with this: It's just too much.
I do not want to build anything of value on top of such a shady platform that's completely controlled by one Megacorporation. It's too big of a risk.
No matter how many MVPs tout "MS <3 Open Source", how can anyone still believe them after these repeated violations?
.NET was open sourced in 2016, that's 6 years ago. It looks like you were 1+ years fully within the ecosystem before any part of it was OSS, and now you're demanding new features they write get open sourced as well?
Reminds of that time they introduced WiFi on planes; it was a brand new thing, and they let folks on the flight use it for free - but of course being a new tech it broke down after about an hour. There was this guy on the flight making a big fuss about the WiFi stopping working, like truly upset and vocal about it. Dude, how are you owed something you didn't even know existed an hour ago?
The problem with MVPs is that they are effectively Microsoft sponsored marketing outlets. I know a few of them personally and they are great people but damn have they drunk the kool-aid.
It's not only that debugger is closed-source - if you try to run non-MS provided build of VS Code, the .Net debugger would decline to start. That was very surprising, after installing VS Code on ubuntu from some default package.
No, it has a lot of bytecode level intelligence to surgically replace the parts of the program that need replaced (as I understand it). Your version just re-runs the project from scratch whenever a change occurs.
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.