I want to like GO but a language that targets native development but still uses garbage collection just seems like an odd pairing to me. Maybe it's just me especially since I rarely get an opportunity to do native development.
RAII is but one resource-management strategy, and one intrinsically linked to C++'s memory model. But if that's what you're looking for, Rust uses the same: http://doc.rust-lang.org/std/ops/trait.Drop.html
And in the absence of cycles, refcounted implementations have similar properties (although of course that assumption will break with alternate non-refcounted implementations if refcounting is not part of the language semantics).
> I want to like GO but a language that targets native development but still uses garbage collection just seems like an odd pairing to me.
Not that rare. OCaml is native and GC'd, so is D, or most lisps with native compilers. Hell, Boehm's GC exists.
http://nimrod-lang.org/manual.html#reference-and-pointer-typ...
The price you pay is you have to manually avoid cycles by annotating some references as weak.
It's a very nice scheme, actually.
Correct, Swift is built on top of the obj-c runtime (more or less) and also uses ARC.
Actually, even without cycles the destruction time is in general unbounded. Just think what happens when you allocate a very long linked list one element at a time and then drop the head. With a bit of ill luck or intention, you can make each element be allocated from a different page with enough different pages so that they fall out of the TLB. In that situation, even without having pages written out to disk, you can expect each element to take ~ a thousand cycles to free. On a million element list, that's ~500ms for freeing the head.
The problem is, compiler magic gives the illusion of safety, and then you segfault and remember that you're in a non-memory safe language. Swift is a big improvement, but it's still basically a DSL on top of objC, with all of the downsides that implies.
The segfault I hit yesterday had to do with a CoreData API that didn't retained its argument, when I assumed it did. The bug doesn't appear when compiling with -Onone, but does appear in -O. Compiler flags are another place where Swift is still very much in C-land, rather than Java/Python/Ruby land. You still need to understand the C compilation model, and e.g. getting your ARC flags wrong in a cocoapod will still cause crashes.
To be clear, swift is a big improvement over objC, but you can't pretend it's a VM managed language.
Memory safety does not require VM management (or so Rust is trying to prove).
I agree, with a few qualifications. I think Haskell has already proved it's possible.
I think Swift + ARC isn't a strong enough guarantee of memory safety for two reasons:
1) Swift has to interact with a huge amount of objC code, of varying degrees of quality (some Apple code, some OSS code via cocoapods). Swift itself would be much safer if all objC was rewritten in Swift.
2) ARC isn't as strong a guarantee as either GC or Rust's pointer semantics. For example, it's easy to hold weak references to something you thought was retained, and then dereference an invalid pointer.
So yes, you can have a memory safe language without a VM, but I think you need GC and/or much stronger pointer semantics, ala rust.
Haskell has a GC, no?
Why? I don't see what is weird about that combination. Garbage collection is usually something that is used in high-level languages, and high-level languages might as well be natively compiled as opposed to interpreted, running on a vm, etc.
If anything, C/++ seems like the odd pair out with their more manual memory management among native languages.