3 ms·

Once you start using channels, Go doesn't seem that beginner friendly

• rastignack 3y ago
  Yes async pin and all that jazz are so easy to understand !
  • laerus 3y ago
    I am writing Rust daily with async, channels and all that jazz and a then some, daily for a year now, but I have only written pin once to wrap existing code that was then refactored with no pin. So yeah I would take types with explicit semantics over arcane CSP syntax any time.
• winrid 3y ago
  is there a language/runtime where running multithreaded code is easier?
  • udev4096 3y ago
    python?
  • pornel 3y ago
    Depends how you define it. If you want fine-grained concurrency, in a large and complex program, then Rust can be easier. Rust itself is not easy to learn, but once you overcome that, its thread-safety features are amazing, and can catch bugs that could otherwise be very difficult to track down. In Golang you're at risk of forgetting to use a mutex or atomic where necessary, or having some function mutate object you thought was immutable, and the race detector needs to catch such violations at run time, whereas Rust catches them at compile time. Rust has libraries for multi-threaded jobs (like parallel iterators), while in Golang I see people making ad-hoc DIY versions of these with channels and goroutines, and the simple constructs don't always handle cases like cancellation or panics.
    • winrid 3y ago
      if someone finds go-routines hard I don't think the suggestion is rust.
      • pornel 3y ago
        Go’s difficulty doesn’t come from being too hard to understand, but from being too simplistic to solve problems properly once. Repetitive code creates more room for simple mistakes. When every case gets an ad-hoc solution it’s natural to cut corners, because it feels wasteful and too noisy to make every boilerplate copy look complicated by handling edge cases. So you don’t have `parallel for`. Instead, each instance is a hand-rolled combo of channels that may or may not limit maximum concurrency, may not care to preserve order when items take different time to process, may not finish or report failure correctly when one of the tasks panics. Additionally, goroutines don’t have any thread safety guarantees. Built-in types aren’t safe to share unsynchronized between goroutines, and the language is too basic to prevent accidental sharing or force immutability or synchronization. A too-easy language can put more burden on programmers.
  • maltmaster 3y ago
    Elixir?
• mrklol 3y ago
  Why? It’s quite straightforward