hello-world.rs
hello-world.rs copied to clipboard
Added backwards to langauges and made 100 numerical constants
Pull request
Fill either one
-
[ ] Does your pull request add a crate?
-
[x] Does your pull request add a new language?
-
[x] Is your pull request memory safe?
-
[x] Is your pull request configurable?
-
[x] Is your pull request minimal?
-
[x] Is your pull request blazing fast?
Hello guys 👋, it's me, Generic Name, Generic SaaS Startup Lead Developer.
In this pull request, we see a new addition to the translations, that being backwards. On top of that, I have add 100 numerical constants from 1 to 100. This should help improve speed and performance, as well as allowing the use of soft coded values rather than the actual numbers. These constants are of type i64, so it can be extended until 9223372036854775807.
Appreciated, Generic Name, Generic SaaS Startup Lead Developer
@Get-DevVed-YT 100 numbers feel random in this repo, maybe just remove it?
That is where you are wrong, good sir. Having 100 numerical constants are shown to improve performance by 10000%. On top of that, it encourages the use of soft coded values rather than actually writing it out.
@Get-DevVed-YT shouldn't thirteen be twelve+one
??
Can you rewrite everynumber, so its
const one: i64 = 1;
const two:i64 = one+one;
const three:i64 = two+one;
const four:i64 = three+one;
@Get-DevVed-YT shouldn't thirteen be
twelve+one
?? Can you rewrite everynumber, so itsconst one: i64 = 1; const two:i64 = one+one; const three:i64 = two+one; const four:i64 = three+one;
While this is certainly an improvement, The numeric literal 1
still doesn't seem as fast as it could get. We can get rid of the numeric values entirely with the following:
const one: i64 = i64::MAX / i64::MAX;
To add onto @alexislefebvre's suggestion with ninetyten
I'd like to suggest the following so this codebase is prepared to handle Bilbo's eleventy first birthday:
+ const eleventyone: i64 = 111;
Or, to be in-line with @mTvare6's suggestion:
+ const eleventyone: i64 = eleven * ten + one;
I like the ideas presented here, however it doesn't seem the most secure to various attack vectors. This is due to the fact that these values are visible by anyone once they are stored in the repository, thus it is very dangerous!
I believe the attack surface can be minimized by instead storing these values encrypted on a central authenticated server. In order to reduce latency and maintain the current blazing fast speeds, the API would be implemented using WebRTC, however a fallback HTTP API would also be available. Only these two protocols would be supported in order to keep the PR minimal, as bloat must be avoided at all costs.
It would be possible to create a standalone repository for this server, however that increases complexity unnecessarily, so it would be best to keep it within the monorepo.
Please share your thoughts below.
We should prevent the pre-allocated numbers from overflowing:
- const four:i64 = three+one;
+ const four:i64 = three.saturating_add(one);
Because of Rusts turbocharged 🤘🏗 compile time evaluation of constants this improvement will have std::Option::None
runtime hit (zero cost abstraction).
As a successor of PURE functional language (e.g. Haskell), maybe we should think it more functionally: I recommend to define numbers as Church Numerals.
I can't find a heap-free implemention, but i think the rustc 🚀 can magically elide the heap allocation just like things on iterators it does.
type λ = fn(i64) -> i64;
type λλ = fn(λ) -> Box<dyn Fn(i64) -> i64>;
const zero: λλ = |f| Box::new(|x| x);
const one: λλ = |f| Box::new(move |x| f(x));
const two: λλ = |f| Box::new(move |x| f(f(x)));
const three: λλ = |f| Box::new(move |x| f(f(f(x))));
const four: λλ = |f| Box::new(move |x| f(f(f(f(x)))));
@zuoxinyu Why don't you make a pull request, I am rather busy teaching Chuck Norris martial arts, you will have contributed to a repo to which [the git of] Linus Torvalds has contributed, you would make this world a better for you and for me and the entire human race.
PS: I do not expect you to respond to my swift reply
Check #327