4 ms·

For what it's worth, I like Rust because I like Python. Python does strive to have one "obvious way to do it", but that ends up meaning it has a very colorful

by eevee 14y ago

For what it's worth, I like Rust because I like Python. Python does strive to have one "obvious way to do it", but that ends up meaning it has a very colorful toolbox full of different ways to solve different problems, much like Rust. Generators, context managers, metaclasses, decorators, and descriptors are all very different mechanisms, but they all work together well. Hell, I keep discovering that Rust has already implemented language features I'd independently thought up half-baked versions of. And not to encourage a flamewar, but I believe there's a gigantic unspoken niche that Rust and Go will be fighting over: people like me who stay away from systems programming because it's a pain in the ass. C is tedious, C++ is bozotic, D is obscure—so the lowest I've bothered to go for a while is Cython. But now there's Rust, and I'm genuinely enjoying it, and I see other people who've mainly been sticking to Ruby or Python who are enjoying Go. This will be interesting to watch. And regardless of what I think of Go, I'm glad there's finally some activity in this space again. :)

cdavid 14y ago
I have not had time yet to look into rust more closely, but do you know if it would be able to export a Rust module in a dlopen-able library, accessible from C ? Writing python extensions in Rust instead of C would be pretty exciting
- eevee 14y ago
  Ha, I was just thinking about how Rust bindings to Python might look. I haven't actually tried this, but since Rust libraries just compile to .so's and it's possible to declare a Rust function with a C signature, I bet it'd be a simple exercise to write a CPython-compatible extension module.
  - kibwen 14y ago
    "I haven't actually tried this" Please remedy this immediately. I'll even provide a highly-imaginative name: "Prusty".
    - eevee 14y ago
      Apparently it won't work yet! Tragic. In the meantime, I can deliberate on whether or not to call it FOXDIE.
      - phaemon 14y ago
        Surely "Pyrite"?
        surrealize 14y ago
        Awesome :) For those with even less of a chemistry background than I have: rust is iron oxide, and pyrite is iron sulfide. It's a good analogy because oxygen and sulfur are in the same group (column) in the periodic table, so they have some chemical similarities.
        crucialfelix 14y ago
        There was a music software language called Pyrite. It ran inside of Max graphic programming environment. It then evolved into SuperCollider which is now one of the most used music programming languages in experimental and academic music. Http://github.com/supercollider But that pyrite hasn't been active for a long time.
        eevee 14y ago
        Awesome.
    - malkia 14y ago
      Prusty comes closes to "Prusti" which is the bulgarian word for "fingers", and "prust" meaning "finger", but also "soil"
- brson 14y ago
  This is not quite possible yet, but will be at some point. Rust does currently depend on a language runtime which expects to control the execution of all Rust code (in particular managing the task scheduler), and the runtime does not have an embedding story yet. Even with an embeddable runtime though, the process would be more involved than loading a library through `dlopen` and executing a function. As part of the effort to rewrite the remaining bits of C++ runtime code in Rust (almost all of Rust is written in Rust), there are further plans to make Rust code runnable without an underlying runtime and without split stacks. After that it will be feasible to write code in Rust and just call it like any C function.
cmccabe 14y ago
Rust has three different ways of allocating memory. And you can't pass things allocated one way to functions that expect something allocated the other way. A Python replacement, this ain't. More like C++ on quaaludes.
- pcwalton 14y ago
  No, Rust has two ways of allocating memory (on the task heap or on the exchange heap), and most functions take borrowed pointers, which accept both kinds of memory. (Edit, re below reply: It depends how you define "allocation"; it's either two or three. I wasn't considering the stack as allocation, but you're right that Rust takes the traditional stack/heap distinction and expands it to stack/exchange heap/task heap. We should update the tutorial to make it clear that borrowed pointers work for the stack as well as both heaps.) I agree that the language is not designed to be a Python replacement, however. No language is suitable for every task.
  - cmccabe 14y ago
    from http://dl.rust-lang.org/doc/tutorial.html http://dl.rust-lang.org/doc/tutorial.html "7.3 What to be aware of Rust has three "realms" in which objects can be allocated: the stack, the local heap, and the exchange heap. These realms have corresponding pointer types: the borrowed pointer (&T), the shared box (@T), and the unique box (~T). These three sigils will appear repeatedly as we explore the language. Learning the appropriate role of each is key to using Rust effectively." It's 3 different types, not 2.
- eevee 14y ago
  Rust statically prevents leaks and double-frees, warns about implicit copies of large structures, and has GC built in if I want to use it. It's certainly more familiar to a Python dev than C++. The whole trait system is even like a built-in and vastly simpler zope.interface.
reinhardt 14y ago
Would be interesting to read a comparison with D. And no, "obscure" is not a meaningful description when comparing it to a language still at v0.3.
- p0nce 14y ago
  I have used D but no Rust yet. They look superficially similar. On the Rust side, algebraic data types, an AST macro system, saner tuples, non-nullable and immutability by default. I'm a bit skeptic about the different pointer types and how they will interact with meta-programming. On the D side, many good things like unittest(), best-in-class overloading support, compile-time everything, etc. http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20cour...
- eevee 14y ago
  That's fair. I'm conjecturing somewhere into the future: D never really took off, but I'm hoping Rust will.

by eevee 14y ago

cdavid 14y ago

I have not had time yet to look into rust more closely, but do you know if it would be able to export a Rust module in a dlopen-able library, accessible from C ? Writing python extensions in Rust instead of C would be pretty exciting

eevee 14y ago
Ha, I was just thinking about how Rust bindings to Python might look. I haven't actually tried this, but since Rust libraries just compile to .so's and it's possible to declare a Rust function with a C signature, I bet it'd be a simple exercise to write a CPython-compatible extension module.
- kibwen 14y ago
  "I haven't actually tried this" Please remedy this immediately. I'll even provide a highly-imaginative name: "Prusty".
  - eevee 14y ago
    Apparently it won't work yet! Tragic. In the meantime, I can deliberate on whether or not to call it FOXDIE.
    - phaemon 14y ago
      Surely "Pyrite"?
      - surrealize 14y ago
        Awesome :) For those with even less of a chemistry background than I have: rust is iron oxide, and pyrite is iron sulfide. It's a good analogy because oxygen and sulfur are in the same group (column) in the periodic table, so they have some chemical similarities.
      - crucialfelix 14y ago
        There was a music software language called Pyrite. It ran inside of Max graphic programming environment. It then evolved into SuperCollider which is now one of the most used music programming languages in experimental and academic music. Http://github.com/supercollider But that pyrite hasn't been active for a long time.
      - eevee 14y ago
        Awesome.
  - malkia 14y ago
    Prusty comes closes to "Prusti" which is the bulgarian word for "fingers", and "prust" meaning "finger", but also "soil"
brson 14y ago
This is not quite possible yet, but will be at some point. Rust does currently depend on a language runtime which expects to control the execution of all Rust code (in particular managing the task scheduler), and the runtime does not have an embedding story yet. Even with an embeddable runtime though, the process would be more involved than loading a library through `dlopen` and executing a function. As part of the effort to rewrite the remaining bits of C++ runtime code in Rust (almost all of Rust is written in Rust), there are further plans to make Rust code runnable without an underlying runtime and without split stacks. After that it will be feasible to write code in Rust and just call it like any C function.

cmccabe 14y ago

Rust has three different ways of allocating memory. And you can't pass things allocated one way to functions that expect something allocated the other way. A Python replacement, this ain't. More like C++ on quaaludes.

pcwalton 14y ago
No, Rust has two ways of allocating memory (on the task heap or on the exchange heap), and most functions take borrowed pointers, which accept both kinds of memory. (Edit, re below reply: It depends how you define "allocation"; it's either two or three. I wasn't considering the stack as allocation, but you're right that Rust takes the traditional stack/heap distinction and expands it to stack/exchange heap/task heap. We should update the tutorial to make it clear that borrowed pointers work for the stack as well as both heaps.) I agree that the language is not designed to be a Python replacement, however. No language is suitable for every task.
- cmccabe 14y ago
  from http://dl.rust-lang.org/doc/tutorial.html http://dl.rust-lang.org/doc/tutorial.html "7.3 What to be aware of Rust has three "realms" in which objects can be allocated: the stack, the local heap, and the exchange heap. These realms have corresponding pointer types: the borrowed pointer (&T), the shared box (@T), and the unique box (~T). These three sigils will appear repeatedly as we explore the language. Learning the appropriate role of each is key to using Rust effectively." It's 3 different types, not 2.
eevee 14y ago
Rust statically prevents leaks and double-frees, warns about implicit copies of large structures, and has GC built in if I want to use it. It's certainly more familiar to a Python dev than C++. The whole trait system is even like a built-in and vastly simpler zope.interface.

reinhardt 14y ago

Would be interesting to read a comparison with D. And no, "obscure" is not a meaningful description when comparing it to a language still at v0.3.

p0nce 14y ago
I have used D but no Rust yet. They look superficially similar. On the Rust side, algebraic data types, an AST macro system, saner tuples, non-nullable and immutability by default. I'm a bit skeptic about the different pointer types and how they will interact with meta-programming. On the D side, many good things like unittest(), best-in-class overloading support, compile-time everything, etc. http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20course%20parts%201%20and%202.pdf http://laser.inf.ethz.ch/2012/slides/Alexandrescu/2-D%20cour...
eevee 14y ago
That's fair. I'm conjecturing somewhere into the future: D never really took off, but I'm hoping Rust will.