CalcuLaTeX VS traits

Check out the main repo here: https://github.com/mkhan45/CalcuLaTeX And the website repo here: https://github.com/mkhan45/CalcuLaTeX-Web

Hey HN, I created CalcuLaTeX because I was frustrated with my workflow for chemistry and physics homework. Generally, I'd use the Python REPL as a calculator and type each problem into LaTeX to turn it in. CalcuLaTeX merges these two steps and makes it easier to reason about calculations by real time visual feedback.

I've posted on r/rust as well (https://www.reddit.com/r/rust/comments/lqn5aa/calculatex_a_p...), and there seems to be interest in using it for scientific papers and such.

The only alternative I know of is PTC MathCAD, which is quite powerful and definitely worth looking into. However, it's quite expensive and Windows only.

The main repo (a Rust library and basic CLI) can be found here: https://github.com/mkhan45/CalcuLaTeX

The website repo using WASM and very hacky JS can be found here: https://github.com/mkhan45/CalcuLaTeX-Web

It supports basic unit conversion via the Unit hints. E.g. you can write 1 hour = ? days. A long term goal is proper Unit coercion which is kind of hard to explain but I did my best in this issue https://github.com/mkhan45/CalcuLaTeX/issues/3.

I'm still working on https://github.com/mkhan45/CalcuLaTeX. I'm hoping for it to be ready for my chemistry quiz next week. I've created a very basic web interface via WASM here: https://mkhan45.github.io/CalcuLaTeX-Web/.

For ECIES that'd probably be something like HPKE. HPKE isn't specific to ECC though, and is defined in terms of a KEM, so the first step there would probably be defining KEM traits which would allow you to plug in ECDH or potentially a post-quantum algorithm or RSA.

No need for eternal stability. It would be indeed nice to get the API right the first time, but in practice it's borderline impossible to do. It's fine for trait crates to introduce breaking changes from time to time, especially for pre-1.0 ones. For prior art you can take a look at rand_core or RustCrypto trait crates.

I finally dusted off my barely-working git hosting solution and added a basic user account system. It took me some time to understand how exactly I was supposed to use password-hash in combination with my hashing function of choice, as well as with the DB. Using sqlx together with Rocket turned out to be somewhat easy once I figured out that I should disregard the built-in database support, since it's seemingly incompatible with sqlx.

The main difference between those two languages, I think you should look at, is power of type system. A good type system allows to encode various invariants checked at compile time, help with interoperability, and even improve performance a bit (e.g. by eliminating runtime-checks). In this regard Rust is far, far ahead of Go in my opinion and continues to improve in this regard (e.g. soon we will have const generics). For example, in RustCrypto we have trait crates which contain "interfaces" of several algorithm types. Almost all algorithm implementations in this org (and some third-party implementations) are implemented in terms of those traits, which means you can easily swap algorithms with each other and combine them like Lego blocks, without diving deep into source code. This property is especially important if you want to support less common algorithms (e.g. regional standards or newly developed algorithms).