Jonathan Blow's language is the most interesting from these three for me because it will have nice metaprogramming features. The document you linked to seems slightly outdated. One of the beta testers has published some more up to date videos with his language introduction and initial experience: https://youtube.com/watch?v=i1vbvikDiI8&index=1&list=PLhEuCy...
Personally, I agree with Jon in that he is not too bothered about being the "winner" with regarding to his language. He wants a tool that can help him actually solve problems he has. And he wants to make sure that his tool is good before releasing it to the public. Releasing a product before it is done is can of worms in itself, not to mention the problems related to open source software itself. So it is entirely respectable for why Jon has not been as opened up his language to the public yet.
I created Odin for the very same reason that I wanted a tool that made me more productive and helped me solve the problems that I actually have. Even if Odin only benefited myself, I would class that as a success, but it has been helping so many people create amazing things.
> Releasing a product before it is done is can of worms in itself
Perhaps, but a programming language which is released when “done” is essentially dead on arrival. I’d guess the people who created amazing things with Odin helped the language move forward, right? Nothing wrong with keeping something to oneself, but promising for a long time to move something into an open source model with no set date.. I’ve rarely seen that end well. Hope I’m proved wrong though!
well Jai is probably the least interesting language for me as the others actually exist. When Jai ever gets released, only then I can see all its warts and glories.
I mean it obviously exists. He livestreams coding on the language and in the language. Sure very few people can actually use it right now, but existence is not in question.
But existing for someone else, and existing where I can use it are two different things. I'm sure there are lots of cool tools and things that exist at big companies like Google (or more interestingly say the NSA) but for all my intents and purposes they don't because I can't interact with them.
A reverse corollary to Russell's Teapot? So what if there is a teapot orbiting Jupiter, I can't get it so it allows me no ability to serve tea. Therefore it might as well not exist!
I understand that. However my comment was just a statement that the existence the person above me was implying was useful existence. As in we can all be excited about this new tool, or game, or whatever, but if we never get to use it, its usefulness is moot. So while the language certainly exists we can observe him working on it, and he could even create a game using it that would have some societal impact, the current usefulness of the language to anyone except him is as if it did not exist at all.
Of course you could make the argument that its mere existence and him highlighting certain aspects could have influences on other language designers... and wow am I going down a tangent spiral now...
Anyways: TL;DR reality is objective but words can have complex semantics
But that's a big deterrent for a lot of people. Odin, Zig, and the like are languages that can be used right now. Yeah, they're not mature yet, but you don't have to wonder what it is like to program in them, and you can start building familiarity with them today.
It’s been a while since I was following Jai descriptions, but IIRC, Nim exists today and has all the meta programming features Jai is supposed to - and to a large extent so does D.
The GC can also run incrementally to meet deadlines. It’s not like a Java GC. It has been used in microcontrollers. People should probably learn more about it before shooting it down based on the word GC.
Java GC also has been used in microcontrollers, with soft real time deadlines, there are plenty of JVM vendors out there, including a couple that are only focused on embedded development like PTC, Aicas, Gemalto, microEJ, Virtenio.
Yes, with some relatively minor caveats, mostly having to release memory yourself.
Also, the arc/orc GC is shaping up and already allows you to use exclusively reference counted memory management - so, efficient and perfectly deterministic timing but still get automatic memory management. (As usual, if you introduce cycles, it becomes more complicated)
And the Nim compiler elides many ref/unref ops, as well as keeping objects thread-local, so most performance objections to ref counting don’t actually apply. (.... and you have a choice of other automatic GC modes, including “none”)
And D has the DasBetterC mode, but I'm not sure that's good enough: when the language has a GC by default, all the libraries use it, the APIs relies on it..
What good is a language if you can't (easily) use its libraries?
Nim’s relationship with GC is very different than any other language that I’ve used.
It has very different selectable GC systems - Boehm, Bacon/Dingle, reference counting, or real-time deadline mark-and-sweep, and “none”. Perhaps I forgot one. Some libraries rely on a specific GC behavior but most work with any (with the caveat that “none” requires you to manually deal with garbage).
Nim’s mark-and-sweep is suitable for embedded systems and games, unlike Java’s, and so is the ref counting one; but even if none of the GCs work for you, the fact that there’s many of them and they are mostly interchangeable means that the dependency on them is much, much weaker than you are used to (although it still exists)
Yes, the general idea is not new but the devil is in the details.
As far as I can tell, Odin's `using` is applicable in the same areas as Kotlin's, but I still favor Kotlin's scoped version. When I see "using foo;" in Odin, it's not quite obvious to me where the scope of applicability is.
Any reason why you didn't do something like
entity.use {
// "this" is now the entity instance
}
// back to your regular "this"
?
You can easily do the same in Odin, if you would like. However, `using` works for a lot more than that just this. `using` allows for many for type system features beyond a basic scope import like Pascal's with. `using` can be applied to procedure parameters, struct field declarations allow for subtype polymorphism (even of pointers), scope imports, and more.
Koltin's approach is limited to purely the same Pascal's `with` allowed.
But if you want to be clear:
{ using entity;
// the fields of "entity" are not usable in this scope
x = 123;
}
entity.x = 123;