3 ms·

> Is Rust substantially better at this? When I read frustrations about Rust, it seems to be mostly about the Borrow Checker... does that affect "pedestrian" cod

> Is Rust substantially better at this? When I read frustrations about Rust, it seems to be mostly about the Borrow Checker... does that affect "pedestrian" code, like "take this 4-dimensional array and munge it with an arcane for-loop"? Or, here's a basic immutable class with some fields and some methods, make it available in Python? I think language complexity in general is not a problem; language consistency is. I find Rust complex, but not inconsistent or surprising (with exceptions). I'd say that yes, it is substantially better in this regard. Regarding the "pedestrian code", it depends. Rust is very unergonomic for algorithms, due to its handling of bidirectional references. However, some algorithms/data structures may work fine; the matrix operation you refer to can be very easy to work with, if the elements are Clone/Copy, which numbers are. I'm a Rust fan, but the article seems to be a puff piece; it takes one case and generalizes it. I also think that Rust is not productive [than other easy, compiled, languages] for generic programming, at least, without significant experience. Relatively small programs (I don't know the size of the typical scientific programs in academia) may be easier, but once a program grows, it definitely requires an amount of design (due to ownership) that other languages don't require.

rich_sasha 4y ago
> I think language complexity in general is not a problem; language consistency is. With C++ I do find human medium-term cache capacity to be an issue. By the time I use C++ again, I forget some of the many little things I need just to compile a glorified "fizz-buzz". Things like, is this a pointer to a const or a const pointer? What's the syntax for a move/copy constructor? Keeping headers and cpp files in sync. What's the flag to enable modern C++ extensions? How do I write this lambda? Or make a pointer to a function? And so on...
Animats 4y ago
> the article seems to be a puff piece; it takes one case and generalizes it. Agreed. I write mostly in Rust, but I don't recommend it unless you have a hard problem. If you need C/C++ speed, and there's enough complicated state coordination that you need safe threading and allocation control, Rust is useful. For typical webcrap, use Go. That's the job for which Google created Go.
- rich_sasha 4y ago
  Python sort of suffers from a lack of reliable fast companions. Here's a rough look of the field: - Things like Cython... let's just say experience is mixed. IME it is very hard to reason with its performance, and quickly it gets about-as-complex as writing your tight loop in a "natively fast" language. - C++ is the standard Python companion, and frankly it can integrate amazingly well. You can define types in C++, native C++ functions, and define conversions between C++/Python. Then you can seamlessly make a C++ object in Python, pass it to the function and get the type back. It's not just about the speed, but also about the ability to really merge two languages together. BUT getting to that point is a massive pain of template errors. - You could do it all in C, manually incrementing and decrementing refcounters. I'll leave it there. - Other languages like Nim, Fortran and who knows what else seem to offer a limited ability to merge the codebases. You can use them, it seems, as a crutch to patch up some Python slowness here and there, but not as a comprehensive "here's two codebases that live side by side". - Rust..? Might it be a replacement for C++ here? And is its complexity manageable.
  - isofruit 4y ago
    I do not have any experience with C++ and thus none about its python interop, which makes it hard for me to compare it to nim's python interop which I do have some experience with. Given that, I'm curious what bits of C++/python interop are easier. I'm mostly asking because my experience of nim-python interop consisted of: Compile nim module with nimpy imported. Put compiled nim module somewhere where your python can find it. write `import <Name_of_module>` in the python file Done, you now have access to the exported functions and symbols defined in the nim module. Is it that C++ wouldn't need any additional imports to make it work that makes it more seamless?
    - rich_sasha 4y ago
      Well, I certainly wouldn't call C++/Python interop easy. It is, IMO, verbose, arcane and complex. BUT, once it works, you have truly seamless integration of Python and C++ code. It feels as magical as, say, two languages interacting on JVM or .NET (not that I used either). Or different languages talking through a REST API. In C++, you'd write your C++ code as if you don't care about Python. Then, you add the "glue" code, which tells C++ how to convert objects to and from Python (there's more options than that but let's leave it here). That, plus a lot of boilerplate. Then, in effect, you can pass objects back and forth between Python and C++, create objects in C++, return them to Python, pass them back to more C++ functions, and so on. I haven't used Nim+Python; but looking at Nimpy documentation, it looks like, for example, to export a class from Nim to Python, it needs to inherit from a special underlying class. You can't just take a class and make it available in Python. And even then, can you pass that back to Nim to call a function with? Maybe yes, and if so, that bumps Nim higher up my priority list.

rich_sasha 4y ago

> I think language complexity in general is not a problem; language consistency is. With C++ I do find human medium-term cache capacity to be an issue. By the time I use C++ again, I forget some of the many little things I need just to compile a glorified "fizz-buzz". Things like, is this a pointer to a const or a const pointer? What's the syntax for a move/copy constructor? Keeping headers and cpp files in sync. What's the flag to enable modern C++ extensions? How do I write this lambda? Or make a pointer to a function? And so on...

Animats 4y ago

> the article seems to be a puff piece; it takes one case and generalizes it. Agreed. I write mostly in Rust, but I don't recommend it unless you have a hard problem. If you need C/C++ speed, and there's enough complicated state coordination that you need safe threading and allocation control, Rust is useful. For typical webcrap, use Go. That's the job for which Google created Go.

rich_sasha 4y ago
Python sort of suffers from a lack of reliable fast companions. Here's a rough look of the field: - Things like Cython... let's just say experience is mixed. IME it is very hard to reason with its performance, and quickly it gets about-as-complex as writing your tight loop in a "natively fast" language. - C++ is the standard Python companion, and frankly it can integrate amazingly well. You can define types in C++, native C++ functions, and define conversions between C++/Python. Then you can seamlessly make a C++ object in Python, pass it to the function and get the type back. It's not just about the speed, but also about the ability to really merge two languages together. BUT getting to that point is a massive pain of template errors. - You could do it all in C, manually incrementing and decrementing refcounters. I'll leave it there. - Other languages like Nim, Fortran and who knows what else seem to offer a limited ability to merge the codebases. You can use them, it seems, as a crutch to patch up some Python slowness here and there, but not as a comprehensive "here's two codebases that live side by side". - Rust..? Might it be a replacement for C++ here? And is its complexity manageable.
- isofruit 4y ago
  I do not have any experience with C++ and thus none about its python interop, which makes it hard for me to compare it to nim's python interop which I do have some experience with. Given that, I'm curious what bits of C++/python interop are easier. I'm mostly asking because my experience of nim-python interop consisted of: Compile nim module with nimpy imported. Put compiled nim module somewhere where your python can find it. write `import <Name_of_module>` in the python file Done, you now have access to the exported functions and symbols defined in the nim module. Is it that C++ wouldn't need any additional imports to make it work that makes it more seamless?
  - rich_sasha 4y ago
    Well, I certainly wouldn't call C++/Python interop easy. It is, IMO, verbose, arcane and complex. BUT, once it works, you have truly seamless integration of Python and C++ code. It feels as magical as, say, two languages interacting on JVM or .NET (not that I used either). Or different languages talking through a REST API. In C++, you'd write your C++ code as if you don't care about Python. Then, you add the "glue" code, which tells C++ how to convert objects to and from Python (there's more options than that but let's leave it here). That, plus a lot of boilerplate. Then, in effect, you can pass objects back and forth between Python and C++, create objects in C++, return them to Python, pass them back to more C++ functions, and so on. I haven't used Nim+Python; but looking at Nimpy documentation, it looks like, for example, to export a class from Nim to Python, it needs to inherit from a special underlying class. You can't just take a class and make it available in Python. And even then, can you pass that back to Nim to call a function with? Maybe yes, and if so, that bumps Nim higher up my priority list.