5 ms·

I would wonder why Go if Rust is available. Rust isn't hard. The only somewhat hard thing in Rust is writing with borrow checker, and honestly, if you want to

I would wonder why Go if Rust is available. Rust isn't hard. The only somewhat hard thing in Rust is writing with borrow checker, and honestly, if you want to seriously write in C, you really need to go through that experience and understand it enough to feel somewhat comfortable with it. And even if that would really be a thing, giving up compiler checks in order to allow more low quality code to be contributed doesn't really seem like a good trade off to me.

Rusky 9y ago
Rust is certainly harder than Go. There's no need to dance around the issue, that doesn't help anyone. Further, Mercurial is already 100% on the train of "giving up compiler checks," though "low quality code" is hardly a fair characterization of why.
- vvanders 9y ago
  In isolation Go is probably easier to write than Rust. However in terms of embedding/interop Rust is certainly much easier. Last I looked there wasn't a way to pin a pointer in Go and they explicitly forbid passing around opaque handles so you're already constrained in how you can interop. Secondly you now have a whole nother runtime to hoist up instead of a simple C FFI. It hit this just recently with Python+Rust. Needed to optimize an inner loop. I could just drop down to a single Rust fn, write it and be on my way. No need to spin up a whole runtime just for that inner function. The parent also hit it on the head. If you're going to be writing C you already need to understand lifetimes deeply, Rust just codifies that in a way that lets you catch it at compile time.
  - Rusky 9y ago
    Certainly, those are exactly the reasons I would use to argue for Rust. I just don't like seeing people minimize its learning curve just to make a point.
  - wott 9y ago
    > If you're going to be writing C you already need to understand lifetimes deeply, Deeply? Unlike complicated languages like for example GC-languages, C only has 2 lifetimes: block scope for stack variables, forever (until explicitly free'd) for heap malloc'ed memory. You don't have to twist your head to know in which of N possible ways the data you get from a function was allocated, you don't have to twist your head to know if you need to free it manually, or semi-manually, or hope that it gets freed automatically at some point. You don't have to care about stack variables, you just have to be organised about heap variables, and that's it. No complicated concept, not many different paradigms. You malloc() something to get some memory when you need it, you free() it when you don't need it any more. Also you don't have to twist your head to know if you can access some function argument, if it was passed by copy or by reference or by a third mean, does it involve heavy data copying or not, what does it mean concerning access, etc. Everything is passed by value (copy) and you can only pass simple objects (plus structures), for anything else you pass the value of the address of the object, end of story.
    - Rusky 9y ago
      > C only has 2 lifetimes: block scope for stack variables, forever (until explicitly free'd) for heap malloc'ed memory. To the contrary, C has just as many lifetimes as Rust. They're just not explicit. "free() it when you don't need it any more" is a complex problem and C doesn't really help you solve it at all. > Everything is passed by value (copy) and you can only pass simple objects (plus structures), for anything else you pass the value of the address of the object, end of story. That's how Rust works as well.
  - gcb0 9y ago
    I don't think go is interpreted in the way python is
- coldtea 9y ago
  >Rust is certainly harder than Go. There's no need to dance around the issue, that doesn't help anyone. It's also faster, much more expressive, and much for flexible (e.g. for loading as a C-compatible lib) so there's that.
spooneybarger 9y ago
I have no idea as to the particulars here. I'm involved with a project that is working with Go code from another language. Go doesn't allow you to share pointers to Go objects with other languages/runtimes. So whatever else the pros and cons of each, working with Go from another language can be painful.
- weberc2 9y ago
  Correct me if I'm wrong, but I think Go lets you share pointers with other languages/runtimes. I think Go doesn't allow you to pass ownership of the pointer to another language, and you need to make sure the pointer is no longer used by the other language by the time Go cleans it up, but I think you can (for example) pass a Go pointer into C. And assuming I'm right about that point, I think this approach is also roughly what was outlined in the Oxidation Plan (Python won't own resources allocated from Rust and vice versa).
  - danieldk 9y ago
    I think Go doesn't allow you to pass ownership of the pointer to another language, and you need to make sure the pointer is no longer used by the other language by the time Go cleans it up, but I think you can (for example) pass a Go pointer into C. Yes, you can, but there are more constraints. E.g. you are also not permitted to pass a pointer to Go memory that contains Go pointers. There is a detailed description here: https://golang.org/cmd/cgo/#hdr-Passing_pointers https://golang.org/cmd/cgo/#hdr-Passing_pointers Also, it used to be the case that cgo calls were relatively expensive (definitely not something you want to do in a hot loop). I am not sure if this is still true, but it was when I was using Go daily for projects.
weberc2 9y ago
Rust is quite a lot harder than Go. While lots of practice makes it easier, it's still not trivial to reason about lifetimes/borrowing/moving, unlike a GC language (which isn't to say that GCs are strictly superior to other memory management schemes, mind you). There are lots of good reasons to choose Rust over Go (you have extreme performance or correctness requirements, for example), but "Rust is comparably easy to Go" is untrue (or as untrue as any user-friendliness assertions can be). EDIT: I don't mean to convey that GCs are still trivial in a mixed-runtime context; only that Rust is generally harder than Go.
- vvanders 9y ago
  Except if you're embedding a runtime you invert the simplicity of a GC. As soon as GC'd pointers start passing across an FFI boundary you either need to: 1. Pin them and track yourself, which then loses a lot of your advantage of having a GC since you've got non-deterministic seg-faults based on when GC runs and pulls objects out from underneath you. C# lets you do this, but it's really painful to get right. 2. Prevent any GC objects being passed(which is what Go does). This means that there's a lot of things you can't do(esp with respect to callbacks and future events) that require a ton of gymnastics to do something that's trivial in C.
  - weberc2 9y ago
    I absolutely agree with this. I didn't mean to convey otherwise.
deleted 9y ago
[deleted]

Rusky 9y ago

Rust is certainly harder than Go. There's no need to dance around the issue, that doesn't help anyone. Further, Mercurial is already 100% on the train of "giving up compiler checks," though "low quality code" is hardly a fair characterization of why.

vvanders 9y ago
In isolation Go is probably easier to write than Rust. However in terms of embedding/interop Rust is certainly much easier. Last I looked there wasn't a way to pin a pointer in Go and they explicitly forbid passing around opaque handles so you're already constrained in how you can interop. Secondly you now have a whole nother runtime to hoist up instead of a simple C FFI. It hit this just recently with Python+Rust. Needed to optimize an inner loop. I could just drop down to a single Rust fn, write it and be on my way. No need to spin up a whole runtime just for that inner function. The parent also hit it on the head. If you're going to be writing C you already need to understand lifetimes deeply, Rust just codifies that in a way that lets you catch it at compile time.
- Rusky 9y ago
  Certainly, those are exactly the reasons I would use to argue for Rust. I just don't like seeing people minimize its learning curve just to make a point.
- wott 9y ago
  > If you're going to be writing C you already need to understand lifetimes deeply, Deeply? Unlike complicated languages like for example GC-languages, C only has 2 lifetimes: block scope for stack variables, forever (until explicitly free'd) for heap malloc'ed memory. You don't have to twist your head to know in which of N possible ways the data you get from a function was allocated, you don't have to twist your head to know if you need to free it manually, or semi-manually, or hope that it gets freed automatically at some point. You don't have to care about stack variables, you just have to be organised about heap variables, and that's it. No complicated concept, not many different paradigms. You malloc() something to get some memory when you need it, you free() it when you don't need it any more. Also you don't have to twist your head to know if you can access some function argument, if it was passed by copy or by reference or by a third mean, does it involve heavy data copying or not, what does it mean concerning access, etc. Everything is passed by value (copy) and you can only pass simple objects (plus structures), for anything else you pass the value of the address of the object, end of story.
  - Rusky 9y ago
    > C only has 2 lifetimes: block scope for stack variables, forever (until explicitly free'd) for heap malloc'ed memory. To the contrary, C has just as many lifetimes as Rust. They're just not explicit. "free() it when you don't need it any more" is a complex problem and C doesn't really help you solve it at all. > Everything is passed by value (copy) and you can only pass simple objects (plus structures), for anything else you pass the value of the address of the object, end of story. That's how Rust works as well.
- gcb0 9y ago
  I don't think go is interpreted in the way python is
coldtea 9y ago
>Rust is certainly harder than Go. There's no need to dance around the issue, that doesn't help anyone. It's also faster, much more expressive, and much for flexible (e.g. for loading as a C-compatible lib) so there's that.

spooneybarger 9y ago

I have no idea as to the particulars here. I'm involved with a project that is working with Go code from another language. Go doesn't allow you to share pointers to Go objects with other languages/runtimes. So whatever else the pros and cons of each, working with Go from another language can be painful.

weberc2 9y ago
Correct me if I'm wrong, but I think Go lets you share pointers with other languages/runtimes. I think Go doesn't allow you to pass ownership of the pointer to another language, and you need to make sure the pointer is no longer used by the other language by the time Go cleans it up, but I think you can (for example) pass a Go pointer into C. And assuming I'm right about that point, I think this approach is also roughly what was outlined in the Oxidation Plan (Python won't own resources allocated from Rust and vice versa).
- danieldk 9y ago
  I think Go doesn't allow you to pass ownership of the pointer to another language, and you need to make sure the pointer is no longer used by the other language by the time Go cleans it up, but I think you can (for example) pass a Go pointer into C. Yes, you can, but there are more constraints. E.g. you are also not permitted to pass a pointer to Go memory that contains Go pointers. There is a detailed description here: https://golang.org/cmd/cgo/#hdr-Passing_pointers https://golang.org/cmd/cgo/#hdr-Passing_pointers Also, it used to be the case that cgo calls were relatively expensive (definitely not something you want to do in a hot loop). I am not sure if this is still true, but it was when I was using Go daily for projects.

weberc2 9y ago

Rust is quite a lot harder than Go. While lots of practice makes it easier, it's still not trivial to reason about lifetimes/borrowing/moving, unlike a GC language (which isn't to say that GCs are strictly superior to other memory management schemes, mind you). There are lots of good reasons to choose Rust over Go (you have extreme performance or correctness requirements, for example), but "Rust is comparably easy to Go" is untrue (or as untrue as any user-friendliness assertions can be). EDIT: I don't mean to convey that GCs are still trivial in a mixed-runtime context; only that Rust is generally harder than Go.

vvanders 9y ago
Except if you're embedding a runtime you invert the simplicity of a GC. As soon as GC'd pointers start passing across an FFI boundary you either need to: 1. Pin them and track yourself, which then loses a lot of your advantage of having a GC since you've got non-deterministic seg-faults based on when GC runs and pulls objects out from underneath you. C# lets you do this, but it's really painful to get right. 2. Prevent any GC objects being passed(which is what Go does). This means that there's a lot of things you can't do(esp with respect to callbacks and future events) that require a ton of gymnastics to do something that's trivial in C.
- weberc2 9y ago
  I absolutely agree with this. I didn't mean to convey otherwise.

deleted 9y ago

[deleted]