3 ms·

Great project. It seems like channels are just the wrong tool for a lot of concurrency problems. More powerful than needed and easy to get wrong. Lots of nice w

Great project. It seems like channels are just the wrong tool for a lot of concurrency problems. More powerful than needed and easy to get wrong. Lots of nice ways to make go concurrency safer. The problem that bothers me (and isnt in Conc), is how hard it is to run different things in the background and gather the results in different ways. Particularly when you start doing those things conditionally and reusing results. Something like go-future helps. https://github.com/stephennancekivell/go-future https://github.com/stephennancekivell/go-future

camdencheek 4y ago
> run different things in the background and gather the results in different ways I'd be curious to see an example of the type of task you want to be able to do more safely
ilyt 4y ago
>The problem that bothers me (and isnt in Conc), is how hard it is to run different things in the background and gather the results in different ways. Particularly when you start doing those things conditionally and reusing results. Do you have any examples ? About only that I can think of is "parse something to a bunch of different types" and that can be solved easily enough. What do you mean by "reusing results" ? > Something like go-future helps. https://github.com/stephennancekivell/go-future https://github.com/stephennancekivell/go-future f := future.New(func() string { return "value" }) value := f.Get() that looks pretty awkward. with channels it would just be f := Async(func() Type{return t}) v := <- f
- stephen123 4y ago
  The main difference is that reading from channels will block if its empty where Futures, return the same value. Written more concisely. f := New(func() Type{return t}) v := g.Get() w := g.Get()
  - ilyt 4y ago
    I wish Go had macros a'la Rust, it would be possible to write the whole thing in so much nicer way.
    - philosopher1234 4y ago
      say good bye to all your nice tooling, fast compile times, uniform code bases... Programmer write cost <<<<<<<<< read cost
  - sa46 4y ago
    When do you find reusing a promise useful? I know one canonical example is a loadable hashmap as in Concurrent Programming in Java, but I was curious if you knew of other examples.

camdencheek 4y ago

> run different things in the background and gather the results in different ways I'd be curious to see an example of the type of task you want to be able to do more safely

ilyt 4y ago

>The problem that bothers me (and isnt in Conc), is how hard it is to run different things in the background and gather the results in different ways. Particularly when you start doing those things conditionally and reusing results. Do you have any examples ? About only that I can think of is "parse something to a bunch of different types" and that can be solved easily enough. What do you mean by "reusing results" ? > Something like go-future helps. https://github.com/stephennancekivell/go-future https://github.com/stephennancekivell/go-future f := future.New(func() string { return "value" }) value := f.Get() that looks pretty awkward. with channels it would just be f := Async(func() Type{return t}) v := <- f

stephen123 4y ago
The main difference is that reading from channels will block if its empty where Futures, return the same value. Written more concisely. f := New(func() Type{return t}) v := g.Get() w := g.Get()
- ilyt 4y ago
  I wish Go had macros a'la Rust, it would be possible to write the whole thing in so much nicer way.
  - philosopher1234 4y ago
    say good bye to all your nice tooling, fast compile times, uniform code bases... Programmer write cost <<<<<<<<< read cost
- sa46 4y ago
  When do you find reusing a promise useful? I know one canonical example is a loadable hashmap as in Concurrent Programming in Java, but I was curious if you knew of other examples.