4 ms·

There are no popular languages that both have no GC and are comfortable to work in. Rust is going to be one, though I feel it's not entirely comfortable yet. G

by tinco 11y ago

There are no popular languages that both have no GC and are comfortable to work in. Rust is going to be one, though I feel it's not entirely comfortable yet. Garbage collection is just one of the things that make languages like Java comfortable to work in, but certainly not the only thing. Disabling automatic garbage collection in Java or C# I feel is a very effective way of gaining most of their advantages while limiting the effects of the runtime on the variability of your execution time. Java is not an interpreted language by the way. FactoryFactories are a choice, not necessarily forced by the language.

asveikau 11y ago
Comfortable is a relative term. There are people comfortable working in C or C++.
- tinco 11y ago
  True, there's a relevant photograph here[1]. Although I think that even those when they fall asleep or otherwise let their guard down their programming experience can get real uncomfortable real quick. 1] https://en.wikipedia.org/wiki/Bed_of_nails#/media/File:RGS_13.jpg https://en.wikipedia.org/wiki/Bed_of_nails#/media/File:RGS_1...
ryao 11y ago
How is your statement not one by someone who would find the modification of any language considered comfortable to remove garbage collection and require explicit free operations to render it uncomfortable? Also, Java is interpreted at the byte code level by default. The way the hotspot JIT works is by detecting hot areas of code and then doing JIT to be compiled.
- ScottBurson 11y ago
  What sense does it make to speak of a language as being interpreted or compiled? These are attributes of an implementation. The existence of GCJ, a native-code Java compiler that's been around for years, proves this. It's true there are languages that are essentially uncompilable, and so have to be interpreted. Perl is the best example I can think of; there are constructs in the language that can't be parsed correctly without runtime context. Python, Ruby, and JavaScript are all difficult to do AoT compilation on as well, at least if you want to do much optimization, but I wouldn't agree that they can't be compiled. But Java is not as dynamic as these languages.
  - ryao 11y ago
    When talking about Java, you can mean the standard library, the virtual machine or the language. The term Java itself is ambiguous.
- tinco 11y ago
  I don't think it must be absolutely so that a language without garbage collection is uncomfortable, as I said I feel Rust comes very close. The only popular languages without a garbage collector are either from the 70s (C) or based on a language from the 70s (C++xx). Both have extreme discomforts when compared to modern languages (Ruby/Haskell/C#/Rust). Also, technically, that would make Java bytecode an interpreted language, not Java itself ;) edit: Ok, apparently according to wikipedia I am wrong and Java generally is considered to be an interpreted language, I had a slightly different definition of interpreted in mind.
  - ryao 11y ago
    C++ first came into existence in 1983. C was made in the 1970s and was the basis for C++, but modern C is rather different than the original C because it assimilated C++'s strong type system. As for popular languages without a garbage collector, here is a list off the top of my head: * C * C++ * FORTRAN * Objective C * Objective C++ * Pascal * Swift Making a new Turing complete language is ultimately just an exercise in how to do the same things differently rather than better unless you find a way to construct a language that can use hardware more effectively than the existing languages can. Languages that lack garbage collection provide no incentive to wipe the slate clean for easier garbage collection. There is an enormous difference between expert level use of C and languages like it and beginner use. There are static analysis and dynamic analysis tools that have been built to assist with catching bugs such as misuse of memory or undefined behavior. C and several others that I listed above are flexible enough that you can implement design patterns that you would expect to see in more "advanced" languages and with structured programming, you can use them fairly easily once they are written. Functional programming is doable: https://github.com/cioc/functionalC https://github.com/cioc/functionalC Object oriented programming is also doable: http://ooc-coding.sourceforge.net http://ooc-coding.sourceforge.net Generic programming can also be done using a mix of macros and void pointers. A rather powerful design pattern that I have seen in C is a function that encapsulates iteration on some data and invokes a callback that takes an accumulator that had been passed to it with the callback. It is great for iterating over things that are not expected to always fit in system memory. The non-accumulator version of that pattern is used in the POSIX standard ftw C function. The acculumator version feels much like generic programming as the type of the accumulator is known only to the caller and callback. The iteration function has no clue about the acculumulator's type. The same goes for plenty of in-memory data structures implemented with void pointers like lists and trees where the memory describing each node is encapsulated inside the object. There is definitely a greater learning curve to C and languages like it, but once you are faililiar with the right patterns/abstractions, such languages are a joy to use and the advantages of more "advanced" languages look more like trade-offs rather than be killer features. Also, people who are familiar with such languages tend to program differently. At work, I have been asked to write some userspace code in Go. I wanted to make some directory traversal code use as few CPU resources as possible (which is a design goal), so I asked for tips on how to do system calls from Go and horrified at least one Go programmer in #go-nuts on freenode in the process. Using the syscalls directly enabled me to take advantage of SYS_gentdents64's d_type to avoid doing a stat to determine whether an entry is a directory or not, increase the buffer to read more directory entries per syscall fewer calls per directory and detect when the end of directory by checking when the buffer has 65535 bytes of free space remaining, which reduces the verse the invocations from 2 to 1. A programmer that does everything the way that garbage collected language authors recommend likely would have had a far less CPU efficient traversal. The superfluous stat syscalls alone would have increased the number of syscalls by at least 1 order of magnitude. I wrote a patch to glibc last night that enables readdir() to skip the second getdents64 call on small directories and I plan to submit after I have what I consider to be the final version. That ought to accelerate GNU find. I might give the Go OS package similiar treatment, although doing fast directory tree traversal the way I am doing it (which is similiar to what GNU find does) requires that to go OS package provide type information from getdents. That is a non-portable BSD extension that Linux adopted and consequently is something that I would not expect Go to provide.
na85 11y ago
>Java is not an interpreted language by the way. Java compiles to native machine code?
- pjmlp 11y ago
  Yes, it all depends which JDK you make use of. Apparently many seem to think the OpenJDK is the only option available.
- ysleepy 11y ago
  Most of the time yes. The JIT will generate machine code for almost all usual code paths after little time.

by tinco 11y ago

asveikau 11y ago

Comfortable is a relative term. There are people comfortable working in C or C++.

tinco 11y ago
True, there's a relevant photograph here[1]. Although I think that even those when they fall asleep or otherwise let their guard down their programming experience can get real uncomfortable real quick. 1] https://en.wikipedia.org/wiki/Bed_of_nails#/media/File:RGS_13.jpg https://en.wikipedia.org/wiki/Bed_of_nails#/media/File:RGS_1...

ryao 11y ago

How is your statement not one by someone who would find the modification of any language considered comfortable to remove garbage collection and require explicit free operations to render it uncomfortable? Also, Java is interpreted at the byte code level by default. The way the hotspot JIT works is by detecting hot areas of code and then doing JIT to be compiled.

ScottBurson 11y ago
What sense does it make to speak of a language as being interpreted or compiled? These are attributes of an implementation. The existence of GCJ, a native-code Java compiler that's been around for years, proves this. It's true there are languages that are essentially uncompilable, and so have to be interpreted. Perl is the best example I can think of; there are constructs in the language that can't be parsed correctly without runtime context. Python, Ruby, and JavaScript are all difficult to do AoT compilation on as well, at least if you want to do much optimization, but I wouldn't agree that they can't be compiled. But Java is not as dynamic as these languages.
- ryao 11y ago
  When talking about Java, you can mean the standard library, the virtual machine or the language. The term Java itself is ambiguous.
tinco 11y ago
I don't think it must be absolutely so that a language without garbage collection is uncomfortable, as I said I feel Rust comes very close. The only popular languages without a garbage collector are either from the 70s (C) or based on a language from the 70s (C++xx). Both have extreme discomforts when compared to modern languages (Ruby/Haskell/C#/Rust). Also, technically, that would make Java bytecode an interpreted language, not Java itself ;) edit: Ok, apparently according to wikipedia I am wrong and Java generally is considered to be an interpreted language, I had a slightly different definition of interpreted in mind.
- ryao 11y ago
  C++ first came into existence in 1983. C was made in the 1970s and was the basis for C++, but modern C is rather different than the original C because it assimilated C++'s strong type system. As for popular languages without a garbage collector, here is a list off the top of my head: * C * C++ * FORTRAN * Objective C * Objective C++ * Pascal * Swift Making a new Turing complete language is ultimately just an exercise in how to do the same things differently rather than better unless you find a way to construct a language that can use hardware more effectively than the existing languages can. Languages that lack garbage collection provide no incentive to wipe the slate clean for easier garbage collection. There is an enormous difference between expert level use of C and languages like it and beginner use. There are static analysis and dynamic analysis tools that have been built to assist with catching bugs such as misuse of memory or undefined behavior. C and several others that I listed above are flexible enough that you can implement design patterns that you would expect to see in more "advanced" languages and with structured programming, you can use them fairly easily once they are written. Functional programming is doable: https://github.com/cioc/functionalC https://github.com/cioc/functionalC Object oriented programming is also doable: http://ooc-coding.sourceforge.net http://ooc-coding.sourceforge.net Generic programming can also be done using a mix of macros and void pointers. A rather powerful design pattern that I have seen in C is a function that encapsulates iteration on some data and invokes a callback that takes an accumulator that had been passed to it with the callback. It is great for iterating over things that are not expected to always fit in system memory. The non-accumulator version of that pattern is used in the POSIX standard ftw C function. The acculumator version feels much like generic programming as the type of the accumulator is known only to the caller and callback. The iteration function has no clue about the acculumulator's type. The same goes for plenty of in-memory data structures implemented with void pointers like lists and trees where the memory describing each node is encapsulated inside the object. There is definitely a greater learning curve to C and languages like it, but once you are faililiar with the right patterns/abstractions, such languages are a joy to use and the advantages of more "advanced" languages look more like trade-offs rather than be killer features. Also, people who are familiar with such languages tend to program differently. At work, I have been asked to write some userspace code in Go. I wanted to make some directory traversal code use as few CPU resources as possible (which is a design goal), so I asked for tips on how to do system calls from Go and horrified at least one Go programmer in #go-nuts on freenode in the process. Using the syscalls directly enabled me to take advantage of SYS_gentdents64's d_type to avoid doing a stat to determine whether an entry is a directory or not, increase the buffer to read more directory entries per syscall fewer calls per directory and detect when the end of directory by checking when the buffer has 65535 bytes of free space remaining, which reduces the verse the invocations from 2 to 1. A programmer that does everything the way that garbage collected language authors recommend likely would have had a far less CPU efficient traversal. The superfluous stat syscalls alone would have increased the number of syscalls by at least 1 order of magnitude. I wrote a patch to glibc last night that enables readdir() to skip the second getdents64 call on small directories and I plan to submit after I have what I consider to be the final version. That ought to accelerate GNU find. I might give the Go OS package similiar treatment, although doing fast directory tree traversal the way I am doing it (which is similiar to what GNU find does) requires that to go OS package provide type information from getdents. That is a non-portable BSD extension that Linux adopted and consequently is something that I would not expect Go to provide.

na85 11y ago

>Java is not an interpreted language by the way. Java compiles to native machine code?

pjmlp 11y ago
Yes, it all depends which JDK you make use of. Apparently many seem to think the OpenJDK is the only option available.
ysleepy 11y ago
Most of the time yes. The JIT will generate machine code for almost all usual code paths after little time.