I was just wondering if the build size of applications written in a language that has a type system smaller than those built w/o one? coz if you can declare the type to something like unsigned integer, then you know that the value wont be a negative and consequently might end up saving some space, am i right? or will it is the runtime memory that will be affected and not the build size?
I like to build cool things, work with nice people and help others where I can. Currently I'm an engineering manager for a fintech startup and historically a serial founder & freelancer software dev.
Location
München, Deutschland 🇩🇪
Education
The Open University
Work
Engineering Manager @ Deutsche Fintech Solutions GmbH
I don't think your question is specific enough to give a solid answer to, could you reiterate perhaps with an example of what you wish to be compared?
Languages, compilers, etc are a very complex topic and comparing JavaScript to Rust, for example, would be like comparing the sun to the moon. It just doesn't work that way since they are in seperate classes.
If you can focus your question down though, I will happily answer!
Sure. The question of build size struck me from the thought that we can restrain the variable range in certain languages beforehand like making it unsigned. This might mean that it wont have to store the sign bit (not sure, just pondering and speculating) and thus perhaps may save some memory. Also, since we know more information before hand, then maybe operations on such data types performed when using pre-built helper functions could be performed in a more optimised way under the hood which we might know about. Small differences like these could possibly be playing a role in the build of the application. Ofc things also depend upon how good the code is written and yes I understand that compilers and languages are a very very complex topic. Its just that I was wondering if things like this could be impacting the build size.
I like to build cool things, work with nice people and help others where I can. Currently I'm an engineering manager for a fintech startup and historically a serial founder & freelancer software dev.
Location
München, Deutschland 🇩🇪
Education
The Open University
Work
Engineering Manager @ Deutsche Fintech Solutions GmbH
It really depends on the language, compiler and compile target at hand.
Example 1: C# / Java compile to intermediate languages which run on the CLR and JVM respectively
Example 2: ELM compiles to JS which executed in the browser
Example 3: Rust compiles to an executable and can be customised for specific compilation targets such as the x86 64 bit MSVC compile target which I use on my windows machine for example
etc..
Types could indeed decrease output sizes when compared to non-typed languages if the compiler optimises for such scenarios but their main use case is to statically find bugs at the compilation step itself. If the compiler then optimises the code that it believes is now safe, that is a different subject entirely. In general compiled languages provide smaller footprints and more performant outputs in my experience but as always, it is a nuanced subject and isn't always going to be the case. As a generalisation from my experience though, one could state such a thing with the contextual knowledge of such nuances though.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I was just wondering if the build size of applications written in a language that has a type system smaller than those built w/o one? coz if you can declare the type to something like unsigned integer, then you know that the value wont be a negative and consequently might end up saving some space, am i right? or will it is the runtime memory that will be affected and not the build size?
I don't think your question is specific enough to give a solid answer to, could you reiterate perhaps with an example of what you wish to be compared?
Languages, compilers, etc are a very complex topic and comparing JavaScript to Rust, for example, would be like comparing the sun to the moon. It just doesn't work that way since they are in seperate classes.
If you can focus your question down though, I will happily answer!
Sure. The question of build size struck me from the thought that we can restrain the variable range in certain languages beforehand like making it unsigned. This might mean that it wont have to store the sign bit (not sure, just pondering and speculating) and thus perhaps may save some memory. Also, since we know more information before hand, then maybe operations on such data types performed when using pre-built helper functions could be performed in a more optimised way under the hood which we might know about. Small differences like these could possibly be playing a role in the build of the application. Ofc things also depend upon how good the code is written and yes I understand that compilers and languages are a very very complex topic. Its just that I was wondering if things like this could be impacting the build size.
It really depends on the language, compiler and compile target at hand.
Example 1: C# / Java compile to intermediate languages which run on the CLR and JVM respectively
Example 2: ELM compiles to JS which executed in the browser
Example 3: Rust compiles to an executable and can be customised for specific compilation targets such as the x86 64 bit MSVC compile target which I use on my windows machine for example
etc..
Types could indeed decrease output sizes when compared to non-typed languages if the compiler optimises for such scenarios but their main use case is to statically find bugs at the compilation step itself. If the compiler then optimises the code that it believes is now safe, that is a different subject entirely. In general compiled languages provide smaller footprints and more performant outputs in my experience but as always, it is a nuanced subject and isn't always going to be the case. As a generalisation from my experience though, one could state such a thing with the contextual knowledge of such nuances though.