4 ms·

Go did that, and it's working out very well. Agree with the grandparent. Async/await is unnecessary complexity in all but the most performance-oriented languag

Go did that, and it's working out very well. Agree with the grandparent. Async/await is unnecessary complexity in all but the most performance-oriented languages (like Rust). Very curious to see how Java Loom will pan out in practice.

pjmlp 4y ago
Java has a better approach, because you can still decide which kind of thread to use, which makes FFI performance still much better than cgo.
oaiey 4y ago
Once you develop in a non single threaded ui framework it is not only about performance.
- cube2222 4y ago
  Could you please expand on that?
  - oaiey 4y ago
    You need to keep the UI responsive, so you hand off all resource or cpu heavy work off the UI thread, give back control to rendering and responding to user input ... and later need to collect the results in the UI thread to change the UI state. It is about doing things in parallel. There are many ways on how to achieve that, I am just nit picking on performance.
    - cube2222 4y ago
      Then I think we misunderstood each-other. Go is asynchronous-first, it just doesn't use the (flawed) async-await semantic to model asynchronicity.
metaltyphoon 4y ago
Not really, look at doing FFI using Go. Its very slow compared to C# specially because of how Goroutines work.
- cube2222 4y ago
  Trading this for simplifying the remaining 99% of my code is a tradeoff I'm willing to make. The vast majority of projects don't use CGo, and of those that do, the majority doesn't call CGo in a tight loop, making the performance impact mostly irrelevant. So it's really coming back to the performance-orientedness of a language.
  - int_19h 4y ago
    The practical end result is an insular ecosystem that tends to rewrite code "in pure Go" rather than reusing existing libraries. To the point where this attitude resulted in the standard library of Go breaking on occasions because they tried to go around libc on macOS and use syscalls directly (which are not guaranteed to be stable). .NET is the opposite - it was designed from the get-go from cross-language and cross-runtime interop. Back when Java folk still had to struggle with JNI to use anything native, .NET 1.0 had P/Invoke and COM Interop. And now that it has async/await, it's all mapped down to a C-compatible ABI for interop purposes, so you can easily write async code in C# that calls into async code written in C++ that calls back into C# etc.

pjmlp 4y ago

Java has a better approach, because you can still decide which kind of thread to use, which makes FFI performance still much better than cgo.

oaiey 4y ago

Once you develop in a non single threaded ui framework it is not only about performance.

cube2222 4y ago
Could you please expand on that?
- oaiey 4y ago
  You need to keep the UI responsive, so you hand off all resource or cpu heavy work off the UI thread, give back control to rendering and responding to user input ... and later need to collect the results in the UI thread to change the UI state. It is about doing things in parallel. There are many ways on how to achieve that, I am just nit picking on performance.
  - cube2222 4y ago
    Then I think we misunderstood each-other. Go is asynchronous-first, it just doesn't use the (flawed) async-await semantic to model asynchronicity.

metaltyphoon 4y ago

Not really, look at doing FFI using Go. Its very slow compared to C# specially because of how Goroutines work.

cube2222 4y ago
Trading this for simplifying the remaining 99% of my code is a tradeoff I'm willing to make. The vast majority of projects don't use CGo, and of those that do, the majority doesn't call CGo in a tight loop, making the performance impact mostly irrelevant. So it's really coming back to the performance-orientedness of a language.
- int_19h 4y ago
  The practical end result is an insular ecosystem that tends to rewrite code "in pure Go" rather than reusing existing libraries. To the point where this attitude resulted in the standard library of Go breaking on occasions because they tried to go around libc on macOS and use syscalls directly (which are not guaranteed to be stable). .NET is the opposite - it was designed from the get-go from cross-language and cross-runtime interop. Back when Java folk still had to struggle with JNI to use anything native, .NET 1.0 had P/Invoke and COM Interop. And now that it has async/await, it's all mapped down to a C-compatible ABI for interop purposes, so you can easily write async code in C# that calls into async code written in C++ that calls back into C# etc.