4 ms·

I have been wondering for some time now, when exactly is a language "fat" or "light"? The idea seems to be there and "obvious" in a way, but haven't been able

I have been wondering for some time now, when exactly is a language "fat" or "light"? The idea seems to be there and "obvious" in a way, but haven't been able to pinpoint exactly what it is. Is it a feeling or an actual metric? e.g. When I work with Java in IntelliJ, things don't feel significantly slower than developing Node in WebStorm. Is it perhaps the way the code looks, in terms of verbosity? I do agree that frameworks contribute to this feeling of Java, but again, is it because a Spring Boot webserver boots slower than a Node one? Or maybe, say a Java cli program vs a C++ one. Is it the speed at which things run? Could it be that, because we know Java uses a VM then it "should" be slower than compiled code and thus it's fatter? What is that "thing" that makes us determine that a language is fat or light?

ypcx 7y ago
The one area where Java feels fat is the memory usage overhead due to 64-bit pointers being used a lot. So if you end up holding and processing a lot of data in RAM, the process allocation and the garbage collector metrics won't look awesome. That said, recently Openj9 improves on this literally by miles. I agree with all the other points - Java and its tooling are very powerful and by that nature they are enabling us to put that much more load on it, so yes, that's where it will be predominantly visible. Edit: that said, Java was created when we didn't have containers. (Just as Clojure was created before Java had lambdas and aggregate streams). So it may be the time to come back closer to the metal again, but as you point out, we need to maintain a clear mind while contemplating that.
- pjmlp 7y ago
  Yes we did, HP-UX vault and Tru64 sandboxes.
Corazoor 7y ago
Well,"fat" is an unprecise term anyway, but the main concern when evaluating languages like that is mandatory overhead. What exactly constitutes overhead is debatable, but generally anything that is not strictly necessary for the functionality is considered as such... Even if it has useful tradeoffs. Examples from Java are the GC, compound types need to be objects and thus are wasting space with type and vtable pointers, and the jvm is actually an interpreter (one with only stack semantics at that). Since C++ has none of that, it is quite natural to say that it is more lightweight than Java. But that in itself is not necessarily a judgement about execution speed, although it is heavily implied. If you write Java in a way that it is heavily jitable and doesn't stress the GC, you can end up with a faster program than a naive C++ version would achieve. But all else being equal, the C++ version will be ever so slightly fester, because less stuff to do means more stuff done.
- saganus 7y ago
  I agree that this is the picture I get in my mind when talking about "fat" languages. So I was wondering if it was something that people felt differently, or if it was mainly the same theme, as it seems like it is.
marmaduke 7y ago
> What is that "thing" that makes us determine that a language is fat or light? In the same way the word modern is thrown around in the context of languages that have evolved a bit, I think heaviness is a notion that is an indicator of how committed the person is to the tradeoffs made by the tech: a heavy language made tradeoffs erring on the side of technical debt and the light one has not. But it's easier to present one's own preferences as technical facts when trying to flame or troll. In the case of frameworks, they often make choices for you, they are opinionated. It's easier to get unhappy about it, in a bike shed sort of way
apta 7y ago
It's just that some people repeat what others say without fully comprehending them (this is especially evident in the golang community). People parrot what the golang authors claim, even though many of such claims are baseless and incorrect.

ypcx 7y ago

The one area where Java feels fat is the memory usage overhead due to 64-bit pointers being used a lot. So if you end up holding and processing a lot of data in RAM, the process allocation and the garbage collector metrics won't look awesome. That said, recently Openj9 improves on this literally by miles. I agree with all the other points - Java and its tooling are very powerful and by that nature they are enabling us to put that much more load on it, so yes, that's where it will be predominantly visible. Edit: that said, Java was created when we didn't have containers. (Just as Clojure was created before Java had lambdas and aggregate streams). So it may be the time to come back closer to the metal again, but as you point out, we need to maintain a clear mind while contemplating that.

pjmlp 7y ago
Yes we did, HP-UX vault and Tru64 sandboxes.

Corazoor 7y ago

Well,"fat" is an unprecise term anyway, but the main concern when evaluating languages like that is mandatory overhead. What exactly constitutes overhead is debatable, but generally anything that is not strictly necessary for the functionality is considered as such... Even if it has useful tradeoffs. Examples from Java are the GC, compound types need to be objects and thus are wasting space with type and vtable pointers, and the jvm is actually an interpreter (one with only stack semantics at that). Since C++ has none of that, it is quite natural to say that it is more lightweight than Java. But that in itself is not necessarily a judgement about execution speed, although it is heavily implied. If you write Java in a way that it is heavily jitable and doesn't stress the GC, you can end up with a faster program than a naive C++ version would achieve. But all else being equal, the C++ version will be ever so slightly fester, because less stuff to do means more stuff done.

saganus 7y ago
I agree that this is the picture I get in my mind when talking about "fat" languages. So I was wondering if it was something that people felt differently, or if it was mainly the same theme, as it seems like it is.

marmaduke 7y ago

> What is that "thing" that makes us determine that a language is fat or light? In the same way the word modern is thrown around in the context of languages that have evolved a bit, I think heaviness is a notion that is an indicator of how committed the person is to the tradeoffs made by the tech: a heavy language made tradeoffs erring on the side of technical debt and the light one has not. But it's easier to present one's own preferences as technical facts when trying to flame or troll. In the case of frameworks, they often make choices for you, they are opinionated. It's easier to get unhappy about it, in a bike shed sort of way

apta 7y ago

It's just that some people repeat what others say without fully comprehending them (this is especially evident in the golang community). People parrot what the golang authors claim, even though many of such claims are baseless and incorrect.