what i wish jai had:
-
better "standard library" (odin's core+vendor libraries/jai's compiler modules)
odin's interface for things is very intuitive and very well designed, it doesn't take long to find what you're looking for, and it's very consistent. for example, strings.builder_make(), strings.builder_init(), strings.builder_destroy(), etc. meanwhile in jai you have things like String_Builder procs: init (which could refer to any number of procs because overloading) print_to_builder, free_buffers/reset, append, etc. (there are more examples like this in other modules.) once you find what you're looking for, it works great, but odin's core library discoverability is top notch (especially with https://pkg.odin-lang.org/ exisiting)
-
slice syntax
jai has "array views" which are exactly like odin slices. but odin's way of handling them with the python syntax makes it 10x more usable, rather than having to use array_view(*view, 0, count) everywhere, and lets you not depend on pointer arithmetic like jai does (there's a time and a place for both but i feel like sometimes it's giving up one for the other when you could just support both)
-
enumerated arrays
jai is a very user-level language, so i understand why they don't think they need to support something like this (and maybe they're right, i literally just made my own module and used that instead so...)
-
discriminated unions
see last point ^ (except in this case Tagged_Union is a compiler module)
-
more public access
i understand why it's not "out" yet like odin is, but i feel like that lack of discoverability hurts it more than it helps. even just having a place where you can see an up-to-date feature list of what the language can do would be nice (https://github.com/Jai-Community/Jai-Community-Library is trying but it's not always the most current because it's the community updating it and jon isn't involved), and it would be so much better to have a dedicated issue tracker (the status quo right now is to send bugs and feature requests to an email that jon sees every once in a while, so you can't know if he's seen it or if you're submitting a bug/feature request that someone else already mailed in)
-
source code access
again, i understand why it's not "open source" but i feel like letting us see the source code so we can at least try to fix compiler bugs if we run into them would be super beneficial, rather than possibly being blocked for weeks or months because of a compiler bug (this has happened to focus more than once). the whole "you can't fix unity bugs" vs "you can fix unreal bugs" situation (not pertaining to the difficulty of actually doing so, just the ability)
what i wish odin had:
-
compile-time execution + type info + code browsing
not going to beat on that drum again, we've had this debate before. but i will say i've been able to do some pretty awesome things like implementing custom checks in my code (think clang-tidy but written in a metaprogram, with type information straight from the compiler itself rather than implementing a separate parser and checker). (one guy is even making an lsp based on metaprogram info as well!)
-
not needing a separate script for building
related to the last point. i know the whole point of odin is to be able to odin build . and you're up and running, but that doesn't always scale. being able to have a program build script that i can write directly in odin would be a million times better than needing to write shell scripts (one per OS), or a python script (which has it's own set of issues -- the orca team in the handmade network server just had a bad experience where people couldn't build their tools because of python shenanigans), or something else. this isn't just a jai thing either, zig also does this, and imo it's the way to go
-
more ambitious projects/libraries
jai ships more than just "standard library" and "vendor" functionality with the compiler modules, there are also things like a whole rendering abstraction (like bgfx/sokol but in native jai), an imgui library, a jai lexer, a texture atlas creator, a frigging bindings generator that works SUPER well (more on that later), etc. I know this is something odin will have more of as time goes on and more people start using odin, but having those available to use is awesome
-
the bindings generator
jai's bindings generator is EXTREMELY useful when you need bindings for something that isn't already available and you need to quickly make some bindings for it. no need to whip out python or parse some xml, the bindings generator uses libclang so literally give it a c OR c++ (!!) header file and it will translate it as best as it can to jai and 99.9% of the time it Just Works™️
-
if-case syntax instead of switch
this is a minor point but the if cond == { syntax instead of switch would be super super nice, i've already had multiple places where changing from a single if cond == true to if cond == { was barely an inconvenience whereas in odin it would have been more work (but again, very minor so not really a complaint)
-
inline asm
i know it's on the way gB!!! but it would be a huge benefit for people who just want to implement a thing at user level without needing to implement it in the compiler as an intrinsic or something (jai has managed to get rid of 99% of their intrinsics thanks to their inline asm, the only ones they have left are things like memcpy because of llvm)
there's more i could probably add but i'll leave it there for now
documentation is meh in both languages, odin's is better to search through but jai's is a lot more in-depth
i feel like both languages fill different niches though. odin prides itself in its simplicity, and jai lets you do more things but also warns you to think about the consequences. to me odin is more like "c but better" and jai is more "c++ but better", which tracks with the experiences from both gB and jon
jai has docs?
the compiler ships with a how_to folder that explains how to use most language features and why they were implemented