5 ms·

This is an interesting point actually. Because it gets raised every time and I actually thought the same before starting with Go. Thing is, in practice you usu

This is an interesting point actually. Because it gets raised every time and I actually thought the same before starting with Go. Thing is, in practice you usually don't need special generic containers. And when I actually need it, I'll just code up a non-generic implementation. When I need a complex type system I'll use Scala.

kuschku 10y ago
Well, I use them a lot – I’ve written lots and lots of generic code in my projects, and reuse it across many dozens of projects. This allows me to have fully reactive collections in Java, lazy reactive collections, and more. I can just connect to a socket transmitting updates with netty, write a transformer, apply those to a lazy reactive collection, and have the changes directly appear in the list in the UI, fully threadsafe. Writing those things again, and again, every time, would be far more work, and increase the time I need to write code massively. I’ve actually used go a bit, and tried reimplementing several of my projects in go, but either it wasn’t easily possible, or I had to translate dozens of generic classes into hundreds of non-generic versions, with lots of duplicated code. And then I had found a bug, fixed it at one point, and had to copy it to hundreds of files.
- cube2222 10y ago
  I'd love to take a look at your codebase if it's hosted on github (or something comparable).
  - kuschku 10y ago
    Currently not, as I only used it in smaller projects in the past. In the future I’ll use it likely with QuasselDroid-NG, an app of mine that’s very early in development, and for which I developed it. The use case there is that we have a list of IRC messages, constantly updating and adding messages at any point of the list, and we want to update the UI and animate. The client can also cache, or preload, messages at any point, or throw them away. Additionally, users can filter, search, or choose to disable some messages. Other messages might get merged, or synthetic ones inserted. So I have a backing store of messages that can constantly change, I have on top of that a stream of transformations taking part, and on top of that an interface presenting a single, consistent Java List, but also triggering the relevant updates on Android’s recyclerview. Most importantly, you can just add a message to the lowest list, it will be properly filtered, transformed, animated, and displayed, and this properly threadsafe across UI thread, backend thread, and filtering threadpool, while being faster than the solutions Realms and co provide for such updated UI.
    - cube2222 10y ago
      I'm not sure if I understand, are you actually using Go for your UI backing or using it as a backend for your application?
      - kuschku 10y ago
        The application described above is Java. Runs on Android and desktop Java with JavaFX. I tried to reimplement the desktop version with Go, due to native UI bindings. And failed.
        cube2222 10y ago
        Well, I don't see any problems with the logic part. Receiving, filtering, transforming, and notifying someone else about incoming messages (would probably do it in a few threads, sending messages between each other). For the UI part: no wonder, Go, at least currently, is useless for UI's.
        kuschku 10y ago
        > (would probably do it in a few threads, sending messages between each other). The problem is that I try to abstract these things away – in Java, I have a general framework, and just do var c = new ObservableCollection<Message>(); var f = new AsyncObservableFilter<Message>(); f.setSource(c); f.addFilter(new DayChangeMessageFilter()); f.addFilter(new CollapseJoinLeaveMessageFilter()); f.addFilter(new RemoveIgnoredMessagesFilter()); var adapter = new ObservableAdapter<Message, MessageViewHolder>(); adapter.setCollection(f.getResultCollection()); and then I can do c.add(new Message(new Date(), "cube2222", "Well, I don't see any problems with the logic part.")); And this works for any type – I can use the same code for observable collections of IRC networks, of channels, etc. And I do use them for that. And if I change the filters, it also does the minimum amount of work necessary to update the list, and not a single CPU cycle more. I’m using it with over 11 different types in the Java version, and I’d have to maintain 11 identical, but with different types, versions in the Go version. You can understand how much of a pain in the ass this is. Oh, btw, this also abstracts away the entire thread handling, while still doing it in a reasonable way. And the backing collection doesn’t have to be a normal ObservableCollection storing data in memory – I also have ones using SQLite as backend, or caches, and I have the ability to add listeners for scrolling up or down to load or unload data as well, if it’s not needed anymore. In Go, I’d manually have to reify all these, and if I find a bug in one, I’d have to update all of the others, too.

kuschku 10y ago

Well, I use them a lot – I’ve written lots and lots of generic code in my projects, and reuse it across many dozens of projects. This allows me to have fully reactive collections in Java, lazy reactive collections, and more. I can just connect to a socket transmitting updates with netty, write a transformer, apply those to a lazy reactive collection, and have the changes directly appear in the list in the UI, fully threadsafe. Writing those things again, and again, every time, would be far more work, and increase the time I need to write code massively. I’ve actually used go a bit, and tried reimplementing several of my projects in go, but either it wasn’t easily possible, or I had to translate dozens of generic classes into hundreds of non-generic versions, with lots of duplicated code. And then I had found a bug, fixed it at one point, and had to copy it to hundreds of files.

cube2222 10y ago
I'd love to take a look at your codebase if it's hosted on github (or something comparable).
- kuschku 10y ago
  Currently not, as I only used it in smaller projects in the past. In the future I’ll use it likely with QuasselDroid-NG, an app of mine that’s very early in development, and for which I developed it. The use case there is that we have a list of IRC messages, constantly updating and adding messages at any point of the list, and we want to update the UI and animate. The client can also cache, or preload, messages at any point, or throw them away. Additionally, users can filter, search, or choose to disable some messages. Other messages might get merged, or synthetic ones inserted. So I have a backing store of messages that can constantly change, I have on top of that a stream of transformations taking part, and on top of that an interface presenting a single, consistent Java List, but also triggering the relevant updates on Android’s recyclerview. Most importantly, you can just add a message to the lowest list, it will be properly filtered, transformed, animated, and displayed, and this properly threadsafe across UI thread, backend thread, and filtering threadpool, while being faster than the solutions Realms and co provide for such updated UI.
  - cube2222 10y ago
    I'm not sure if I understand, are you actually using Go for your UI backing or using it as a backend for your application?
    - kuschku 10y ago
      The application described above is Java. Runs on Android and desktop Java with JavaFX. I tried to reimplement the desktop version with Go, due to native UI bindings. And failed.
      - cube2222 10y ago
        Well, I don't see any problems with the logic part. Receiving, filtering, transforming, and notifying someone else about incoming messages (would probably do it in a few threads, sending messages between each other). For the UI part: no wonder, Go, at least currently, is useless for UI's.
        kuschku 10y ago
        > (would probably do it in a few threads, sending messages between each other). The problem is that I try to abstract these things away – in Java, I have a general framework, and just do var c = new ObservableCollection<Message>(); var f = new AsyncObservableFilter<Message>(); f.setSource(c); f.addFilter(new DayChangeMessageFilter()); f.addFilter(new CollapseJoinLeaveMessageFilter()); f.addFilter(new RemoveIgnoredMessagesFilter()); var adapter = new ObservableAdapter<Message, MessageViewHolder>(); adapter.setCollection(f.getResultCollection()); and then I can do c.add(new Message(new Date(), "cube2222", "Well, I don't see any problems with the logic part.")); And this works for any type – I can use the same code for observable collections of IRC networks, of channels, etc. And I do use them for that. And if I change the filters, it also does the minimum amount of work necessary to update the list, and not a single CPU cycle more. I’m using it with over 11 different types in the Java version, and I’d have to maintain 11 identical, but with different types, versions in the Go version. You can understand how much of a pain in the ass this is. Oh, btw, this also abstracts away the entire thread handling, while still doing it in a reasonable way. And the backing collection doesn’t have to be a normal ObservableCollection storing data in memory – I also have ones using SQLite as backend, or caches, and I have the ability to add listeners for scrolling up or down to load or unload data as well, if it’s not needed anymore. In Go, I’d manually have to reify all these, and if I find a bug in one, I’d have to update all of the others, too.