3 ms·

Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, tha

Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, that variables are defined correctly and not shadowed, and that errors are all handled. I'm not sure if there are many GC'ed languages that would do all that? These kinds of safety guarantees tend to come from compiled languages not GC'ed languages. Beyond the correctness argument, also because the GC can really come back to bite you when you least expect, following the sudden "knee" of Little's Law. I've seen multi-minute pauses every few seconds even with V8's GC in production and it was not a pleasant experience. It cropped up, out of the blue, and in the end required a V8 core team member to advise and help comment out a few lines of C++ GC code that were overzealous.

creata 6y ago
In your first paragraph, you seem to be confusing interpreted languages and GC'd languages. Even Java has all of the features you've listed above, afaict.
- jorangreef 6y ago
  Yes, I was thinking of Java, which is why I said not "many" and "tend".
oblio 6y ago
> Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, that variables are defined correctly and not shadowed, and that errors are all handled. I'm not sure if there are many GC'ed languages that would do all that? These kinds of safety guarantees tend to come from compiled languages not GC'ed languages. GCed is orthogonal (as in: doesn't have anything to do) to type safety. Java is GCed, so are Scala, Kotlin, C#, F#. Even dynamic GCed languages towards the scripting side of things are moving to static typing: Typescript, Python Mypy, Ruby types (I forgot the name of the project).
- jorangreef 6y ago
  Of course, but in the past these would tend to go hand in hand, and the context here is not only about type safety, but about checked behavior for ignored return values and for exhaustive switches, i.e. all syscall errors are handled, and the compiler (or interpreter) will crash at compile time or run time with an error if not. Do Scala, Kotlin, C#, F# have all those features? Do most Java versions also not allow integer overflow?
square_usual 6y ago
I'm responding really late because I didn't check my threads for a while, but in response to your first point, there's plenty of GC'd languages that can give you type safety and compiler checks. As others have pointed out, Java, TypeScript and Go are fairly solid compiled languages with GC. If you want more type safety, Scala, F#, Ocaml and Haskell all have extremely powerful type systems that I personally find very useful when working on complicated business logic (my personal favorite is Ocaml). In the more exotic space, Nim has a really cool cross between ARC and GC, and comes with dependent types for extra safety! GC is not perfect, and as you point out, a "stop the world" GC can cause more pain than is saved from not having to do manual memory management, but I think there's a lot of good work in the space that makes me think really hard about picking up a language that would require manual memory management.

creata 6y ago

In your first paragraph, you seem to be confusing interpreted languages and GC'd languages. Even Java has all of the features you've listed above, afaict.

jorangreef 6y ago
Yes, I was thinking of Java, which is why I said not "many" and "tend".

oblio 6y ago

> Because, for example, a business-rules heavy project would also benefit from type safety and from a compiler that checks that return values are not ignored, that variables are defined correctly and not shadowed, and that errors are all handled. I'm not sure if there are many GC'ed languages that would do all that? These kinds of safety guarantees tend to come from compiled languages not GC'ed languages. GCed is orthogonal (as in: doesn't have anything to do) to type safety. Java is GCed, so are Scala, Kotlin, C#, F#. Even dynamic GCed languages towards the scripting side of things are moving to static typing: Typescript, Python Mypy, Ruby types (I forgot the name of the project).

jorangreef 6y ago
Of course, but in the past these would tend to go hand in hand, and the context here is not only about type safety, but about checked behavior for ignored return values and for exhaustive switches, i.e. all syscall errors are handled, and the compiler (or interpreter) will crash at compile time or run time with an error if not. Do Scala, Kotlin, C#, F# have all those features? Do most Java versions also not allow integer overflow?

square_usual 6y ago

I'm responding really late because I didn't check my threads for a while, but in response to your first point, there's plenty of GC'd languages that can give you type safety and compiler checks. As others have pointed out, Java, TypeScript and Go are fairly solid compiled languages with GC. If you want more type safety, Scala, F#, Ocaml and Haskell all have extremely powerful type systems that I personally find very useful when working on complicated business logic (my personal favorite is Ocaml). In the more exotic space, Nim has a really cool cross between ARC and GC, and comes with dependent types for extra safety! GC is not perfect, and as you point out, a "stop the world" GC can cause more pain than is saved from not having to do manual memory management, but I think there's a lot of good work in the space that makes me think really hard about picking up a language that would require manual memory management.