|
|
|
|
|
|
by ilyt
1297 days ago
|
|
|
> The functional requirement here is to take some HTML, parse it and emit slack flavoured markdown. That is solved already and not what the article is about The nonfunctional requirement is a self-contained binary that is not dependent on machine's own libraries or any extra files. That's not just mental excercise but a feature. That is what article is about. The "proper" engineering solution might be very well "just rewrite that small part in Go", but this approach is nonetheless interesting. |
|
|
Let me add more to this: speed.
You have Rust/WebAsssembly in the mix and automatically you gain in speed as shown in the article.
I honestly don't understand the negative comments.
If you build a lib in C and then you use standard binding mechanisms, oh it's ok. In this case you leverage a great tool (cargo) to do the heavy lifting for you and bam you get a safe binary that gives you better performance and overall better tooling -> it's bad.... why?
I read the original version of the poster's comment and it was way more aggressive and more about "sound architecture". Maybe he/she can explain what exactly is wrong with this approach and what other approach should be taken instead?
> The "proper" engineering solution might be very well "just rewrite that small part in Go", but this approach is nonetheless interesting.
Why? In this case it's a trivial function. What if it's a strong algorithm that needs speed? Rust helps there, and it's faster than Go.