6 ms·

I can't help wondering when this will be ported to Go. Doesn't performance matter in such a sophisticated technology?

• andybak 6y ago
  From the FAQ: > USD consists of a set of C++ libraries with Python bindings for scripting.
• integricho 6y ago
  I also can't help but wonder, since when is go considered a performance oriented language :)
  • steve_adams_86 6y ago
    I think people see python as accessible but not very fast. Then they see Go which is fairly accessible but with significantly better performance than python. Why not use Go instead? What people don’t realize when they make that comparison is that the python version of many popular libraries is a light wrapper over a bunch of C++ (or some other really fast language). At least that’s what I figure is going on. I see a lot of people wanting to port stuff to Go. Having said that, Go is awesome for bespoke solutions where you don’t have some python bindings on a C library to do what you need. It’s certainly not a slow language, and its tooling is exceptionally nice to get started with. But what I want to know is when are they going to port PyQT to Go?
    • UncleEntity 6y ago
      > I think people see python as accessible but not very fast. Then they see Go which is fairly accessible but with significantly better performance than python. Why not use Go instead? Most (all?) 3d graphics programs use python as an extension language so they'd have to re-architecture their whole system to use Go programs in place of python. If it's even possible to dynamically load Go programs without having to resort to an Inkscape level of tomfoolery where the extension is called as a separate program and all the data is passed as shell arguments. ...not saying anything is wrong with Inkscape's way of doing things but I sure wish it had a built-in python api.
• Cthulhu_ 6y ago
  Don't make claims about performance without measuring first. Don't push a language without measuring first. Don't push a language without comparing its performance with similar workloads. Don't make assumptions about performance based on the language. You seem to be trying to come across as if you know and care about performance, but your comment actually proves you still have a long way to go.
• marcinzm 6y ago
  If you care about absolute speed then Go isn't generally the best choice. You're looking at Fortran/C/C++ (depending on the application) and maybe Rust if you can take a bit of a performance hit. Of course, most performant Python code is actually Fortran/C/C++ with a thin wrapper so you get the best of both worlds.
  • nl 6y ago
    Unless you are a physicists there are very few Fortran libraries used from Python.
    • da39a3ee 6y ago
      Don’t the linear algebra libraries used by numpy (blas and lapack) use fortran? That’s the case for R, I thought it was for numpy also.
    • marcinzm 6y ago
      I thought SciPy used Fortran for some things?
• jpm48 6y ago
  python is the front end, a language that most Technical Artists use and know well. If you look at the core libraries behind this you will see some really good modern C++, including other libraries such as OpenImageIO, OpenColourIO OpenSubDiv etc all of which are C++ (including SIMD and CUDA routes for most).