• 1 Post
  • 10 Comments
Joined 2 years ago
cake
Cake day: July 2nd, 2023

help-circle

  • I thought I would give my experiences with odin and zig. Maybe it will be of use to op.

    Odin:

    I used Odin about 6 months ago.

    I found Odin to be a very easy language to use. It also has wrappers for popular third party c libraries (called vendors) built in (glfw, sdl2, etc.). The vendor libraries are mostly focused on multimedia. Odin also has an extensive standard library.

    My problem with Odin is that it is still not finished. They say the language features are done and will not change but they are still working on the standard library. When last I used it they were rewriting the OS part of the standard library, so anything you wrote using the OS module could change and you would need to rewrite parts of your code.

    My second problem with Odin is the documentation. They do have a large source file with lots of examples in it which is very helpful but documentation for the standard library is seriously lacking. You often have to read the source code to figure out what the standard library functions do. Another documentation resource is their discord but, because of the changing standard library, answers you find via search in Discord are often old. So, you will need to ask and hope someone answers. I will say that the creator of Odin is very active on Discord and does answer a lot of questions.

    I am waiting for a full Odin release before I try it again.

    Zig:

    I used zig about 8 months ago.

    I found zig a bit more difficult to learn. The syntax is a bit different than what I was used to (especially around error handling). But, after I got my head around some of the strange syntax it made sense and worked fairly well.

    My big problem with zig was using c libraries. Zig is good at generating a wrapper for c libraries but the wrapper will feel very c and not zig. So, ideally, someone would have manually tweaked the wrapper to be more zig like and release it as a library. I had issues with zig versions and libraries. Libraries are built against a specific version of zig. Some target the latest in development build and some target a specific release build (and then some have abandoned their libraries and it targets old versions). When you want to use 2 libraries that target different versions it is a nightmare. This brings me on to the build system.

    My second problem is the build system. It is powerful but with power comes complication. I struggled terribly to use the build system to bring in libraries. What did not help is that the build system is constantly evolving so the documentation on forums and in the libraries “how to use” sections was often out of date. This was painful to try to use.

    Another thing with zig that worries me is that they say the syntax is not finalized and it could change forcing you to rewrite your code.

    My conclusion:

    Odin is easy to use especially if you want to use it for graphical programs but have the speed/power of c. Just the documentation is a problem. Also, it is not that popular so the community is quite small.

    Zig is much more popular with a larger community than Odin. More applications are being written and released in zig. It looks like zig may one day become a c replacement. Using it now requires a lot of effort to keep up with its changes.

    Rust… I tried it once but I did not have the energy to learn the borrow checker (or I am just to stupid).

    This is all just my experiences. Your mileage may vary.



  • I took another crack at it using a similar concept. This time I separated the pulse extender and the clock. This way it is very reliable and the clock speed and the speed between pistons extending can be easily controlled with the repeaters.

    Basically I have the same pulse extender which switches on a clock. Then each pulse from the clock is connected to the pistons with a repeater going into one piston to make it extend after the first one.

    By the way, the dropper and stuff coming out of it previously was just stuff I saw in your pic and tried to replicate it to see what space I was dealing with, it did nothing. I removed all the extra stuff in the new pics.

    Here are some pics:


  • I am by no means good at redstone, so I do not know if my solution is compact or efficient (or any good at all!).

    My approach is to make the pistons fire alternatively constantly until the string is not triggered for a few seconds then it stops firing the pistons. This way there is always a constant piston firing rate and after the last item has fallen through the string the pistons still fire a couple of times just in case some items fell on top of a slime block then this will clear the items.

    In the images you can see I made a pulse extender coming off the observer that is looking at the string. Then there are observers looking at the dust that is part of the pulse extender and every time the pulse degrades the observers trigger. Then after those observers are repeaters to slightly extend the pulse so that the pistons fire slow enough not to leave their slime blocks behind.

    Note that the repeater after the left observer is 3 ticks and the repeater after the right observer is 4 ticks.



  • Odin is quite a fun new language I just started learning. It is meant as a C replacement and comes with a decent standard library and third party library so there is a lot already built that you can use. It also is fully compatible with C and can use C libraries.

    Just be warned that documentation is lacking and you will have to read the source code of the standard library from time to time or seek help from their discord.