Drop hestiaRS and opting hestiaNIM?

[hollowaykeanho]

Question

Please state your question in a brief and ended with question mark (?). You
may include sub-questions with "if cases" to communicate more effectively
instead of many 'ping-pong' passing.

Given the extreme authoritharian goverences from Rust upstream in terms of tools, conventions, standards, naming conventions, and worst: incomplete support of cross-platform while spending time messing with logo and brand trademark, I really do not wish to continue supporting Rust in Hestia.

Given that Firefox (Gecko Engine) has been playing catch up, I'm very permisstic about supporting that language given the track records were too vocal, too little actions.

Given this trend is the same as Accelerated Mobile Pages (AMP) where it has good intention but bad execution, Rust goverence is sharing the same fate. We been through supporting AMP the hard way; I do not want to re-write another library because of external forces and threats that I can't control.

The few reasons I selected Rust initially were primarily because:

1. WASM
2. Embedded Microcontroller
3. Non-GC requirements

and their offered RAII. Since we're going to rebuild a standard library, RAII is not really a priority (we're going to deal with unsafe interfacing with hardware anyway).

I'm planning to replace with Zig, and Zig also has:

1. WASM
2. Quite friendly with embedded microtroller
3. Non-GC requirement
4. A lot better cross-compilation supports similar to Go
5. Very flexible naming convention (highly compatible with Go and TinyGo).

Both still failed to have built-in code coverage tool like Go did but it does not really matter since the libraries are inter-operable so Go can cover it.

@corygalyna , I need your input.

Background

Please provide a short description of what you are trying to ask.

The 3rd language requirements:

1. Cross-compilation - compulsory feature (not relying on an external too and gamble the OS to setup whichever compilers and I don't want my end-users to buy 3 different computers or 1 powerful and expensive computer with 3 vm just to work on 1 project).
2. Access to assembly - compulsory feature (where we can interface with the hardware directy).
3. Some kind of memory protection for end user - compulsory feature to protect users from manual memory counting.
4. No upstream politics or harassment - compulsory trait (ref. case: Nikolay Kim vs. Rust Communities (https://www.theregister.com/2020/01/21/rust_actix_web_framework_maintainer_quits/).
5. WASM capable - compulsory feature.
6. No GC - Go and TinyGo already did a great job there.
7. Unit Testing Capability - compulsory feature.
8. Decentralized Distribution - compulsory feature.
9. Ignore offered libraries - we're assimilating them into our own libraries so no point being how big they are and close source.

Current Research Artifacts (COMPULSORY)

Please list out all your research artifacts that you did (e.g. link, blog post,
documentations, and etc) for us to gauge your context and current efforts. We
may not reply and will close the ticket with perjuidice if this section remains
empty and unconvincing.

1. https://en.wikipedia.org/wiki/Zig_(programming_language)
2. https://ziglearn.org/
3. https://ziglang.org/learn/
4. https://github.com/C-BJ/Awesome-Zig

Attachment

Please drag and drop the necessary data files (e.g. screenshot, logs, etc)
below.

[corygalyna]

Community seems ok: https://github.com/ziglang/zig
Project is active.

The downside I can see is Rust being WASM first-class citizen while Zig can have some uphill battle. I do agree that the noise and nuisance is very de-motivating.

[corygalyna]

Give me time to look through. After all, you're still working on Phase 1.2.

[corygalyna]

Go stays right?

[hollowaykeanho]

Yes Go stays. It's a matter of choosing a statically-linked non-GC language to compliment Go where Go can't reach.

[JeanShuralyov]

Wow. This can be a hard decision. I'm on the move side mainly because:

1. Rust is really poor at facilitating the necessary and required tools like cross-compiler. So no matter how great and safe the language is, if you can't reach the audience, you do not have customer.
2. I disagree with @corygalyna that Zig is an uphill battle. This project is an uphill battle when you two had decided to re-write the entire standard library for various-sized CPUs in 1 package. Hence, it should out of the picture.
3. Zig is not as complicated as Rust. In fact, Zig can perform C/C++ compilations without using Zig code.
4. The problem with embedded is that LLVM does not support most of the products. Hence, both Rust and Zig are poor choices.
5. Given the fact that Rust already causing stirs here and does not seems to have a plan to dissipate its risks, I'm too not convinced to continue with Rust.

[corygalyna]

@JeanShuralyov , thanks for the feedback. The thing is that the market are heading towards Rust, not Zig in a large volume manner.

Secondly, Rust is like C++, an extension to Go which is being represented as C like Zig. Have 2 common C-based compilers together does not bring in much values either.

Besides, we got TinyGo which is still under development on their side that uses LLVM.

[JeanShuralyov]

Rust is like C++, an extension to Go which is being represented as C like Zig.

Yeah but you're going to re-write the entire libraries right so what's the point of those extra libraries? You are not going to use them anyway and very likely are going to discourage your customers from using them.

---

Looking at this thread, the project is not yet reaching at code development and the Rust authorities already created concerns here and there. This is already a good reason not to proceed further.

Yes, RAII is attractive but it is just a disciplined algorithm. What matters is solving the business problem first that sells, not having a shiny golden shovel that doesn't dig but used for bragging all over the places.

[corygalyna]

Looking at this thread, the project is not yet reaching at code development and the Rust authorities already created concerns here and there. This is already a good reason not to proceed further.

Okay, remove the politics aside and keep it to technical requirements only.

Yes, RAII is attractive but it is just a disciplined algorithm. What matters is solving the business problem first that sells, not having a shiny golden shovel that doesn't dig but used for bragging all over the places.

The concern is if we successfully developed the library but no one is using, what's the point? It is also building a solution nobody buys.

[JeanShuralyov]

Okay, remove the politics aside and keep it to technical requirements only.

That's the point. You guys don't involve in their politics but look at what they did to both of you.

The concern is if we successfully developed the library but no one is using, what's the point? It is also building a solution nobody buys.

The thing is LLVM can't serve many micro-controller products anyway. Most sellers are stuck with embedded C. At least Zig has a proven track records of natively interacting with C codes while working with a C transpiler.

At least Zig facilitates cross-compilation as easy as TinyGo and Go compared to the restrictions made by rustup and etc with its one way of doing things all the way down to coding practice. That's good enough.

[hollowaykeanho]

all right ladies, so far to support Embedded in Zig/Rust:

1. Cross-compilation - compulsory feature (not relying on an external too and gamble the OS to setup whichever compilers and I don't want my end-users to buy 3 different computers or 1 powerful and expensive computer with 3 vm just to work on 1 project).
2. Access to assembly - compulsory feature (where we can interface with the hardware directy).
3. Some kind of memory protection for end user - compulsory feature to protect users from manual memory counting.
4. No upstream politics - compulsory trait (ref. case: Nikolay Kim vs. Rust Communities (https://www.theregister.com/2020/01/21/rust_actix_web_framework_maintainer_quits/).
5. WASM capable - compulsory feature.
6. No GC - Go and TinyGo already did a great job there.
7. Unit Testing Capability - compulsory feature.
8. Decentralized Distribution - compulsory feature.
9. Ignore offered libraries - we're assimilating them into our own libraries so no point being how big they are and close source.

The technical goal is to deprecate from using C with the new advanced tools.

Please clam down and continue the debates. Thanks for the inputs.

[corygalyna]

Decentralized Distribution - compulsory feature.

Need to find out Zig has such feature.

[corygalyna]

Decentralized Distribution - compulsory feature.

Answer is YES. C-style way with headers.

[hollowaykeanho]

Note that if I get harassed by any Rust zealot because of this case, I will cast a veto decision to move to zig.

[corygalyna]

After reading through this article, https://kevinlynagh.com/rust-zig/, I can see your perceptive on why you're dropping Rust:

1. In case of Zig flops (e.g. project abandoned, etc), Zig still permits the use of C codes so all efforts are not lost.
2. 8/16/24-bits micro-controllers are still using embedded C compiler so the HAL layer libraries can remain as C codes and inter-op with Zig for safety checking. In other word, it's not just Zig, but also C where Zig is parenting it. Folks also can use vendor-specific compilers via the C codes.
3. No extremely authoritative naming convention. That also means this will affect Phase 1.2 since it is defining the library API blueprint.
4. We have Monteur to automate things and manage packages already.

Note that if I get harassed by any Rust zealot because of this case, I will cast a veto decision to move to zig.

I concur.

[corygalyna]

What about nim - https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers?

This one is much closer to the requirement and have transpiler capability.

[hollowaykeanho]

My turn to find out.

[hollowaykeanho]

1. Cross-compilation - compulsory feature compile to C, then GCC/CLang it.
2. Access to assembly - compulsory feature natively supported.
3. Some kind of memory protection for end user - Checkes are available.
4. No upstream politics or harassment - not seen.
5. WASM capable - Nim -> C --> Emscripten.
6. No GC - Go and TinyGo already did a great job there (an on/off switch: https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers).
7. Unit Testing Capability - compulsory feature.
8. Decentralized Distribution - modules, libraries.
9. Ignore offered libraries - we're assimilating them into our own libraries so no point being how big they are and close source.

---- Extra offering ----

1. Able to transpile to C, C++, and Javascript reusing existing toolkits and etc.
2. Python-style.
3. Same naming convention with Go.
4. Compatible with Zig since zig acts as an LLVM C compiler.

---

Good taste @corygalyna .

[corygalyna]

Yeah. I vote to use hestiaNIM over hestiaRUST. The big change is mainly:

1. Upstream poses themselves as a non-technical threat that can disrupt this project.
2. The over authoritative governance of Rust is already disrupting the project (e.g. naming convention, etc).

---

Opted Nim because:

1. The ability to transpile to C, C++, and Javascipt which enables status quo tools to be completely reusable.
2. Able to interact with Zig.
3. Can work with WASM.
4. Statically linked / GC over a switch. In our case, we will stick to statically linked since we have Go and TinyGo do the counterparts.
5. Unit test capable.
6. Direct assembly interaction.
7. No upstream threat (yet).

@JeanShuralyov , although I don't know what's the story between you and rust, would you support the idea?

[JeanShuralyov]

Interesting language. If it can natively support Zig, I'm fine. Sharp eyes you got there!

[hollowaykeanho]

Okay, in that case, we will drop the Rust in favor of Nim as our 3rd language (statically typed). We can close this discussion now.