5 ms·

This is the best way to categorize programming languages, but applying it only to relatively unpopular languages seems a strange choice. I'd categorize the pop

by devit 8y ago

This is the best way to categorize programming languages, but applying it only to relatively unpopular languages seems a strange choice. I'd categorize the popular ones like this: - One sparse byte array: C, C++ - GC heap with class instances with fields: Java, C#, etc. - Affine structs and enums on the stack, plus library support for heap and other models: Rust - Dictionaries and primitives: JavaScript, Python, Ruby, etc. - Immutable structs and enums on the heap: (safe) Haskell - Textual/array/dictionary variables, global and local: bash and other shells

myrloc 8y ago
What about Golang?
- jerf 8y ago
  Same category as Java. Values can go on the stack in Go, but it's an optimization, the language semantics are still essentially based on the casual use of the heap. There's a way in which C# is Java done right. Go can be seen as Java done right, for a different definition of "right". On paper they are virtually identical languages. In practice they are quite different.
  - bogomipz 8y ago
    >"Go can be seen as Java done right, for a different definition of "right" Can you explain this? In what sense is Go "Java done right"? The OPs comment isnt offering me much insight into your comment. Thanks.
    - jerf 8y ago
      For as popular as Java is, and as much work has been put into it, and as high quality as its multiple JVM implementations may be, it still shows its heritage as a language designed for a different purpose entirely (to run set-top boxes) than either the one Sun wanted to put it to ("write once run anywhere") or the one it ultimately ended up dominating (server-side code). The biggest example in my opinion is the grave error that Java made in making classes declare their conformance to interfaces. Go's structural typing is uniformly superior, and I believe this one change is roughly 80% of Go's ability to have generally simpler code and to avoid the framework monstrosities that populate the Java world. I fully recognize that sounds bizarre if you've only used one or the other, but I believe it. The ability to declare an interface in my module that some other module that knows nothing about me automatically conforms to prevents people in the Go ecosystem from having to pre-emptively buy into huge frameworks to solve this simple problem. (This is a great deal of the reason I darned near classify Go as a scripting language; for all the drama about "missing generics" I find the experience of writing Go to feel much more like Python than like writing Java.) I have enough of the "explicit better than implicit", formal proof Haskell-y sort of stuff in me to understand where that impulse comes from, but I believe that this is a case where those intuitions are disproved by experience. Recently I was looking at an crash dump in an Atlassian product, and it clearly had two of those monstrous frameworks in there. We were 600 stack levels deep at the point of the failure. ~100 of them I could excuse as a template renderer recursing on the AST of the template, but there was just this amazing amount of junk in the stack trace. You don't get that in Go code; it looks more like a typical Python dump in depth. There's a few other places where Go gets things right just by virtue of being newer; again, contra to accusations that the designers have never heard of newer tech, it has closures in it from the get-go. (Yes, I am aware those are hardly new, but if the designers really were completely closed off those wouldn't go in there.) Go has value types from the beginning, which Java is still jamming in. There's a few other things too, like just generally being a bit more memory-aware than Java and a bit more able to put things on the stack, even if the optimizer is generally not that great. It's the combination of these little fixes that are the reason why Go hangs in there with Java performance wise by most measures, and is often more memory efficient, despite the probably 3+ orders of magnitude more effort put into the JVMs.
dingo_bat 8y ago
> One sparse byte array: C, C++ What does sparse mean in this context?
- slrz 8y ago
  Thinly populated. The whole address space is the array and addresses/pointers are indices into it. This point of view might not necessarily be supported by the actual language specifications, though.
deleted 8y ago
[deleted]

by devit 8y ago

myrloc 8y ago

What about Golang?

jerf 8y ago
Same category as Java. Values can go on the stack in Go, but it's an optimization, the language semantics are still essentially based on the casual use of the heap. There's a way in which C# is Java done right. Go can be seen as Java done right, for a different definition of "right". On paper they are virtually identical languages. In practice they are quite different.
- bogomipz 8y ago
  >"Go can be seen as Java done right, for a different definition of "right" Can you explain this? In what sense is Go "Java done right"? The OPs comment isnt offering me much insight into your comment. Thanks.
  - jerf 8y ago
    For as popular as Java is, and as much work has been put into it, and as high quality as its multiple JVM implementations may be, it still shows its heritage as a language designed for a different purpose entirely (to run set-top boxes) than either the one Sun wanted to put it to ("write once run anywhere") or the one it ultimately ended up dominating (server-side code). The biggest example in my opinion is the grave error that Java made in making classes declare their conformance to interfaces. Go's structural typing is uniformly superior, and I believe this one change is roughly 80% of Go's ability to have generally simpler code and to avoid the framework monstrosities that populate the Java world. I fully recognize that sounds bizarre if you've only used one or the other, but I believe it. The ability to declare an interface in my module that some other module that knows nothing about me automatically conforms to prevents people in the Go ecosystem from having to pre-emptively buy into huge frameworks to solve this simple problem. (This is a great deal of the reason I darned near classify Go as a scripting language; for all the drama about "missing generics" I find the experience of writing Go to feel much more like Python than like writing Java.) I have enough of the "explicit better than implicit", formal proof Haskell-y sort of stuff in me to understand where that impulse comes from, but I believe that this is a case where those intuitions are disproved by experience. Recently I was looking at an crash dump in an Atlassian product, and it clearly had two of those monstrous frameworks in there. We were 600 stack levels deep at the point of the failure. ~100 of them I could excuse as a template renderer recursing on the AST of the template, but there was just this amazing amount of junk in the stack trace. You don't get that in Go code; it looks more like a typical Python dump in depth. There's a few other places where Go gets things right just by virtue of being newer; again, contra to accusations that the designers have never heard of newer tech, it has closures in it from the get-go. (Yes, I am aware those are hardly new, but if the designers really were completely closed off those wouldn't go in there.) Go has value types from the beginning, which Java is still jamming in. There's a few other things too, like just generally being a bit more memory-aware than Java and a bit more able to put things on the stack, even if the optimizer is generally not that great. It's the combination of these little fixes that are the reason why Go hangs in there with Java performance wise by most measures, and is often more memory efficient, despite the probably 3+ orders of magnitude more effort put into the JVMs.

dingo_bat 8y ago

> One sparse byte array: C, C++ What does sparse mean in this context?

slrz 8y ago
Thinly populated. The whole address space is the array and addresses/pointers are indices into it. This point of view might not necessarily be supported by the actual language specifications, though.

deleted 8y ago

[deleted]