4 ms·

> Make something idiot-proof and the world invents a better idiot. Sure, but if you only ever give people safety scissors then you're severely limiting the kin

> Make something idiot-proof and the world invents a better idiot. Sure, but if you only ever give people safety scissors then you're severely limiting the kinds of things that they can build. You have to let people who know what they are doing be able to do what they need to do, so you have to be able to turn the runtime safety off. Zig can do this at the scope level.

TchoBeer 6y ago
I don't understand why there aren't any solutions like this. Why aren't there any languages with a good garbage collector but also let you turn it off and work with memory manually. Maybe there is and I don't know of it? Maybe garbage collected languages and manual memory languages require different design? I don't know.
- arc619 6y ago
  Nim is built like this. The gc is opt-in by type and manual memory management is simple. All other types are stack allocated by default. The new gc is pretty much compiler assisted scope managed smart pointers as well. Also when using the gc you can build your own types with custom create/free/copy/move operators to do what you want without worrying about a stop the world gc. Using the arc gc pretty much compiles down to what you'd do manually. For cycles you can use the orc gc, again it's all opt in. I find this a great balance of productivity and performance, where it's easy to have high control when you want it, and still get good performance when you're not bothered.
  - elcritch 6y ago
    +1 for Nim and being usable without a GC or for manual memory management like dealing with C apis. Though to be fair, quite a few types in the stdlib are heap based. But you can make your own static heap pool. With the new ARC & move semantics, Nim has hit a sweet spot, IMHO. It's like the language struggled to find a fit for a long time. But ARC allows very low overhead memory safety, perfect for mcu's and wasm in particular. Though perhaps Swift could be a contender in this arena as well with its ARC, but it's development is so Apple centric. What's interesting to me is that with move semantics and smarter compiler analysis, an ARC based GC overhead approaches that of Rust's compile time lifetime memory management. For any non-trivial program Rust seems to use a lot of Rc's or copies to get around lifetime analysis issues. So if the compiler can automatically figure out lifetimes in code it can eliminate many ARC operations. I hope more languages adopt more flexible ARC based gc's or improve on rusts ergonomics.
- ArtifTh 6y ago
  C# has GC by default, but you can do manual memory management in "unsafe" blocks
  - pjmlp 6y ago
    You can also do manual memory management in safe code. - value types - stackalloc is safe since C# 7 - SafeHandles since C# 2.0 - IDispose interface - IDispose like Dispose() since C# 8 - Marshal class since C# 1.0 - Span<>() classes since C# 7
    - pjmlp 6y ago
      Forgot to mention: - static lambdas since C# 9 - native function pointers since C# 9
- kaba0 6y ago
  Well, GC languages can’t really allow arbitrary pointer arithmetic (because it would make GC useless/unsafe), but languages that can do explicit stack—allocation are numerous, like C#, Go, I’m sure D as well. Nim also has an optional GC, so there are languages all around the spectrum.
- dnautics 6y ago
  for erlang, if you drop down to C you completely lose the garbage collector, but the docs for doing this show you how to set up a hook for your memory to be garbage collected just like any other first-class data in the system. If you're really responsible, it's possible to use the system allocator to inform the system about how much memory your allocations consume so that the memory pressure triggers have a correct accounting of how much memory is being used.
- june11 6y ago
  dlang has exactly this, with both marking functions as @nogc and being able to both use the gc in one block, and malloc free in the next. You can also limit D a subset called 'BetterC'. I Really enjoy being able to gc my way though a problem until I need some explicit memory structure for putting together a ECS or similar memory management heavy patterns.
- Narishma 6y ago
  I think this will just lead to a split ecosystem with some libraries requiring a GC and others requiring manual memory management.
- bitmapper 6y ago
  My favorite example of this is probably Clean, which solves this using uniqueness types. You can have unique values that are managed using compile time memory management, but also are free to use garbage collected values. It makes for a very performant pure functional language. My only gripe is that the stdlib is abysmal, and hardcoded into the compiler.
- pjmlp 6y ago
  You can use value types and do manual memory management in C#, F#, VB, D, Nim, Swift (RC is GC). Then on the past languages that failed to gain steam, Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-07, Oberon-2, Active Oberon, Eiffel, Sing#, System C#, Component Pascal, among many others. The only thing missing is that many are badly taught, use new everywhere and don't bother to fully understand all language features.
lionkor 5y ago
In my mind this isn't about safety scissors at all. I hate languages that in any way limit the kind of code I want to write, which is why I write C++ for the most part, but that's another rant for another day. If you dont want full control like in C++, a language would be nice that has one specific style, one specific way to do things, and so on. Go(lang) is quite close to this, in my experience. You can't do thread safety wrong, because there's only really one way, and so on. I would love a language with 1. Explicit nullable types (not like Java's "anything can be null" design), so everything is a non-nullable reference type unless its "optional<T>" for example. I strongly support the idea of a nullable type only being used where it being null carries information. 2. Strong typing - like, tungsten strong. Implicit conversions need to be compiler errors, no implicit constructors, etc. with simple explicit casting 3. One style - and it better not be Java-like forced-OOP. 4. Full and clear memory control, RAII support, no gc. I need my RAM for other stuff. I'm not sure if there's a language like that out there. I don't care for library support, I just want a fun language.

TchoBeer 6y ago

I don't understand why there aren't any solutions like this. Why aren't there any languages with a good garbage collector but also let you turn it off and work with memory manually. Maybe there is and I don't know of it? Maybe garbage collected languages and manual memory languages require different design? I don't know.

arc619 6y ago
Nim is built like this. The gc is opt-in by type and manual memory management is simple. All other types are stack allocated by default. The new gc is pretty much compiler assisted scope managed smart pointers as well. Also when using the gc you can build your own types with custom create/free/copy/move operators to do what you want without worrying about a stop the world gc. Using the arc gc pretty much compiles down to what you'd do manually. For cycles you can use the orc gc, again it's all opt in. I find this a great balance of productivity and performance, where it's easy to have high control when you want it, and still get good performance when you're not bothered.
- elcritch 6y ago
  +1 for Nim and being usable without a GC or for manual memory management like dealing with C apis. Though to be fair, quite a few types in the stdlib are heap based. But you can make your own static heap pool. With the new ARC & move semantics, Nim has hit a sweet spot, IMHO. It's like the language struggled to find a fit for a long time. But ARC allows very low overhead memory safety, perfect for mcu's and wasm in particular. Though perhaps Swift could be a contender in this arena as well with its ARC, but it's development is so Apple centric. What's interesting to me is that with move semantics and smarter compiler analysis, an ARC based GC overhead approaches that of Rust's compile time lifetime memory management. For any non-trivial program Rust seems to use a lot of Rc's or copies to get around lifetime analysis issues. So if the compiler can automatically figure out lifetimes in code it can eliminate many ARC operations. I hope more languages adopt more flexible ARC based gc's or improve on rusts ergonomics.
ArtifTh 6y ago
C# has GC by default, but you can do manual memory management in "unsafe" blocks
- pjmlp 6y ago
  You can also do manual memory management in safe code. - value types - stackalloc is safe since C# 7 - SafeHandles since C# 2.0 - IDispose interface - IDispose like Dispose() since C# 8 - Marshal class since C# 1.0 - Span<>() classes since C# 7
  - pjmlp 6y ago
    Forgot to mention: - static lambdas since C# 9 - native function pointers since C# 9
kaba0 6y ago
Well, GC languages can’t really allow arbitrary pointer arithmetic (because it would make GC useless/unsafe), but languages that can do explicit stack—allocation are numerous, like C#, Go, I’m sure D as well. Nim also has an optional GC, so there are languages all around the spectrum.
dnautics 6y ago
for erlang, if you drop down to C you completely lose the garbage collector, but the docs for doing this show you how to set up a hook for your memory to be garbage collected just like any other first-class data in the system. If you're really responsible, it's possible to use the system allocator to inform the system about how much memory your allocations consume so that the memory pressure triggers have a correct accounting of how much memory is being used.
june11 6y ago
dlang has exactly this, with both marking functions as @nogc and being able to both use the gc in one block, and malloc free in the next. You can also limit D a subset called 'BetterC'. I Really enjoy being able to gc my way though a problem until I need some explicit memory structure for putting together a ECS or similar memory management heavy patterns.
Narishma 6y ago
I think this will just lead to a split ecosystem with some libraries requiring a GC and others requiring manual memory management.
bitmapper 6y ago
My favorite example of this is probably Clean, which solves this using uniqueness types. You can have unique values that are managed using compile time memory management, but also are free to use garbage collected values. It makes for a very performant pure functional language. My only gripe is that the stdlib is abysmal, and hardcoded into the compiler.
pjmlp 6y ago
You can use value types and do manual memory management in C#, F#, VB, D, Nim, Swift (RC is GC). Then on the past languages that failed to gain steam, Mesa/Cedar, Modula-2+, Modula-3, Oberon, Oberon-07, Oberon-2, Active Oberon, Eiffel, Sing#, System C#, Component Pascal, among many others. The only thing missing is that many are badly taught, use new everywhere and don't bother to fully understand all language features.

lionkor 5y ago

In my mind this isn't about safety scissors at all. I hate languages that in any way limit the kind of code I want to write, which is why I write C++ for the most part, but that's another rant for another day. If you dont want full control like in C++, a language would be nice that has one specific style, one specific way to do things, and so on. Go(lang) is quite close to this, in my experience. You can't do thread safety wrong, because there's only really one way, and so on. I would love a language with 1. Explicit nullable types (not like Java's "anything can be null" design), so everything is a non-nullable reference type unless its "optional<T>" for example. I strongly support the idea of a nullable type only being used where it being null carries information. 2. Strong typing - like, tungsten strong. Implicit conversions need to be compiler errors, no implicit constructors, etc. with simple explicit casting 3. One style - and it better not be Java-like forced-OOP. 4. Full and clear memory control, RAII support, no gc. I need my RAM for other stuff. I'm not sure if there's a language like that out there. I don't care for library support, I just want a fun language.