Type inference woes

CONSIDER this Rust code that a reasonable human being might try to write:

fn add<T>(a: T, b: T) -> T {
return a + b;
}
If you try to compile that, you’ll get an error like this:

:1:25: 1:30 error: binary operation `+` cannot be applied to type `T`
What you actually have to write is something like this:

use std::ops::Add;
fn add<T: Add>(a: T, b: T) -> T::Output {
return a + b;
}
Now it typechecks correctly.

This seems a little ridiculous. The compiler already knew that T had to be a type that supports addition — it just told me that. So why am I spelling it out?

>>34
Nobody claimed that addition is impure you anus.

>>41
Nobody claimed it, but Rust and Haskell devs decided, both that addition is not worthy of being a native language construct. As if, their pure language can function without addition.

>>42
What would they gain by making it a primitive?

>>43
Language primitives:
1.Require no library/header/method import and processing time associated thereof.

2.Are able to be optimized further than library construct, within the compiler.
Many optimizations and code transformations are simplified if internally available.

3.Secure the existence of libraries using the code, since library changes and bugs can't affect them. You can't just have a situation where is a need to upgrade to Addition2.0 or your code is now incompatible.

4.Language primitives reduce syntax clutter and boilerplate, as demonstated in this thread, you don't need to explicitly import anything or adapt your code to call library/method/functions, since the construct is native to the language.

>>44
#1 "Processing time overhead"
Furthermore, the ridicolous dependency chains which bottom out on primitives such as addition or booleans existing as library methods increase compilation time.
This is a tax you pay for autismal purity ideology, addition and booleans being pulled from libraries instead of being internal language primitives.

Well, here is a good example of dependency chain breaking down. A basic function to pad a string, wasn't available within standard library and was imported through a module. (This is directly comparable to Rust Cargo crates, on which many depend to write code)
https://en.wikipedia.org/wiki/Leftpad#Notable_breakages
This is epitome of "lets let the libraries/modules/stray cats handle it".

True libertarianism begins when you import BasicAddition.js directly from shady russian accounts on github each time you compile the app.

>>47
True Libertarianism would entail entering a SLA to add Addition.js microservice to import it into your serverless cloud framework. No dirty centralized authorities, since you can easily switch to another cloud or microservice, should Addition.js start lagging, SuperAddition.js and FastAddition.js are waiting on the wings to undercut the market leader.

>>44

1.Require no library/header/method import and processing time associated thereof.

Modules do really require any more processing time than a primitive.

2.Are able to be optimized further than library construct, within the compiler.

Can also be done with library functions in the same way.

Secure the existence of libraries...

Prelude comes with GHC dude.

4.Language primitives reduce syntax clutter and boilerplate

No they do not.

you don't need to explicitly import anything

Already the case with Prelude.

>>44
half of those are solved by the fact that their're are implicitly imported in haskal

>>46
this is a good argument against relying too much on third-party libraries, not the standard library. if your're are standard library has dependencies on third-party shit then you have an even bigger problem

>>49

Modules do really require any more processing time than a primitive

Why are you using impure Numbers when pure Church numerals built on elegant lambda calculus and available as a module exist?

*Peano numerals