3 ms·
> developers keep wasting that on inefficient languages like javascript, python, java, etc > For fast, efficient software there will always be low level langua
by nikofeyn 7y ago
> developers keep wasting that on inefficient languages like javascript, python, java, etc
> For fast, efficient software there will always be low level languages such as C, C++, etc.
this sounds like every "low level developer" ever, in that the opinions are completely removed from reality. it isn't 19<whatever>. if by inefficient, you mean slow, then java isn't anywhere near comparable to javascript or python. beyond being a completely different type of language, java is fast. so is c# and f#. so is chez scheme and sml. so are plenty of much higher-level languages than c and safer languages than c++ that are just as fast (if not faster in some cases dependent upon development time and application and developer) than c and c++.
also, c++ is low-level? it is an insanely complex high-level language.
- F-0X 7y ago> this sounds like every "low level developer" ever, in that the opinions are completely removed from reality. it isn't 19<whatever>. Who cares what year it is. Fact is, with low level languages, you can write software which consumes less resources. This won't ever change. > if by inefficient, you mean slow, then java isn't anywhere near comparable to javascript or python. Sure, I (and presumably the poster you responded to) agree. Java is plenty fast for most things. But its memory usage is horrendous. Like seriously bad. It seems Intellij takes a solid 1.5gb to simply exist. I'd like to use Java (well, JVM based languages really) more, but basically all JVMs are memory hogs that take too long to start up. Graal might help here, we shall see. C#, F#, Chez, et al. follow a similar suit. (Chez is probably the best of that lot, though. Would be my choice).
- nikofeyn 7y ago> Fact is, with low level languages, you can write software which consumes less resources. This won't ever change. and you'll be much more susceptible to bugs and schedule elongation and robustness issues. that won't ever change either.