Comment by trklausss

Comment by trklausss 17 hours ago

Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative.

Also, tons of CAE platforms have Python bindings, so you are "forced" to work on Python. Sometimes the solution is not just "abandoning a language".

If it fits your purpose, knock yourself out, for others that may be reading: uv is great for Python dependency management on development, I still have to test it for deployment :)

aeve890 17 hours ago

>Every tool for the right job. If you are doing tons of scripting (for e.g. tests on platforms different than Rust), Python can be a solid valid alternative.

I'd say Go is a better alternative if you want to replace python scripting. Less friction and much faster compilation times than Rust.

Reply View 8 replies

DiabloD3 16 hours ago

I am not a huge fan of Go, but if all the world's "serious" Python became Go, the average code quality would skyrocket, so I think I can agree to this proposal.

Reply View | 0 replies
physicsguy 16 hours ago

Go performance is terrible for numeric stuff though, no SIMD support.

Reply View | 6 replies
- 9rx 16 hours ago
  
  That's not really true, but we're talking about a Python replacement for scripting tasks, not core compute tasks, anyway. It is not like Python is the paragon of SIMD support. Any real Python workloads end up being written in C for good reason, using Python only as the glue. Go can also interface with C code, and despite all the flack it gets for its C call overhead it is still significantly faster at calling C code than Python is.
  
  Reply View | 1 reply
  
  adastra22 14 hours ago
  
  For the record of people reading this, I wrote a multithreaded SIMD-heavy compute task in Go, and it suffered only 5% slowdown vs the original hand-optimized C++ version.
  The low level SIMD stuff was called out to over the c FFI bridge; golang was used for the rest of the program.
  
  Reply View | 0 replies
- DiabloD3 16 hours ago
  
  (given the context of LLMs) Unless you're doing CPU-side inference for corner cases where GPU inference is worse, lack of SIMD isn't a huge issue.
  There are libraries to write SIMD in Go now, but I think the better fix is being able to autovectorize during the LLVM IR optimization stage, so its available with multiple languages.
  I think LLVM has it now, its just not super great yet.
  
  Reply View | 0 replies
- wild_egg 15 hours ago
  
  Lots of packages out there using SIMD for lots of things.
  You can always drop into straight assembly if you need to as well. Go's assembler DX is quite nice after you get used to it.
  
  Reply View | 0 replies
- pjmlp 12 hours ago
  
  Go itself no, but luckily like in any compiler toolchain, there is an Assembler available.
  
  Reply View | 0 replies
- pclmulqdq 16 hours ago
  
  There are Go SIMD libraries now, and there's also easy use of C libraries via Cgo.
  
  Reply View | 0 replies