5 ms·

really wonder why not Go. original code was python with lots of C. the same can be done with Go, while keeping much of the same philosophy of python. This cha

• rkangel 9y ago
  I'm curious, why is Go+Python easier than Rust+Python?
  • Uther 9y ago
    It is not. Go alone is easier than Rust. But since Rust has no GC, it is easier to embed, especially with a language with a Garbage collector like Python.
• oconnor663 9y ago
  My understanding is that Go would be a fine candidate if you wanted to rewrite the entire codebase in it, but not for writing compiled extensions that Python can dynamically link, and they want one language to do both of those things?
• jhugg 9y ago
  One reason might be that it seems easier to mix languages with Rust vs. Go. The C interop is pretty sane and Go has a few more gotchas in that department. The rest of the Rust v Go debate may be similar to the 1000 times people have had it before.
  • kevin_thibedeau 9y ago
    Nim is an even closer match to Python and interop is trivial.
• deleted 9y ago
  [deleted]
• rubber_duck 9y ago
  One thing that comes to mind is having to bridge two GC/runtimes in the same binary, where Rust is a drop in replacement for C in that regard (systems programming language)
  • rbehrends 9y ago
    As the plan seems to be to embed Python in Rust, rather than just writing extension modules in Rust, this shouldn't be as much of a concern. The tricky part with two runtimes is (1) the system initialization and (2) the GC (if any) being able to control the initial stack frame. If you're just writing extension modules, either problem can be a challenge. But the first problem goes away if you embed Python, as Python initialization is trivial for the host language when embedding. So does the second problem, as the host language is now in control of the initial stack frame. The fact that a language is garbage-collected should not matter much; Python uses reference counting as its primary memory management mechanism, with a generational trial deletion approach for cycle colletion (which does not require root scanning). This approach can generally coexist well with a tracing garbage collector (though some challenges remain, but those can be designed around). That said, Go specifically may have problems (I'm speculating here) due its green threads not being happy if Python does any blocking operations, and it's probably not safe to operate on Python objects concurrently in multiple threads. But that wouldn't necessarily be a problem for other languages.
• seba_dos1 9y ago
  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.
• jstewartmobile 9y ago
  Last I read, any C calls have to be spun off into their own OS thread since the runtime is unable to inject soft context-switches into foreign code. With heavy FFI usage, that could become costly...
• panic 9y ago
  Forget Rust and Go, why not ATS? You get C compatibility with dependent types!
• usrusr 9y ago
  Outsider guess: they want to move away not only from Python syntax and runtime, but also from Python philosophy.
• durin42 9y ago
  Go isn't really a huge win for hg, and it doesn't support being used as a shared library, so we couldn't easily use it as a replacement for C for native extensions. main() has to be in Go, and even then you've got two GCs in the mix which is not great.
  • neandrake 9y ago
    Using rust for a shared library implementation seems like it would mean a big improvement for mercurial's tooling in the long run. Right now the options are command line invocation or using the python library (effectively puts a requirement on implementation). Though I'm not sure the integrations I'm aware of[0] would benefit from a shared library. [0] https://secure.phabricator.com/T9548 https://secure.phabricator.com/T9548
• chme 9y ago
  There are places where C and other places where programming C++ makes more sense; the same is true with Rust and Go. When it comes to low-level, high performance, no overhead stuff and less unexpected behaviour C and Rust fit better. Where high implementation speed and fast changing, experimental and highly modular architecture systems are more important C++ and Go are better. For Mercurial and Git Rust or C makes more sense. Especially if you put experimental and fast changing stuff into a scripting language. IMO.
• petre 9y ago
  I wonder why not Dlang. It has better C/C++ interop than Rust, C parts coukd be used/wrapped before they're rewritten.
• erpellan 9y ago
  Given a situation where (pre-rust) the usual choice would be to use C or C++, it's totally appropriate to choose Rust. That's one of Rust's express design goals. Go is intended to make it very easy for junior devs to build concurrent network applications. That's its design goal. It's not a zero-sum game. Choosing rust doesn't weaken go or vice versa.
• Varriount 9y ago
  Or Swift, or Nim. Really, There are so many other languages that are both performant and more readable than Rust (I consider Rust readability to be on par with C++).