Re:How We’re Designing Channels
by lastofus on Monday December 04, 2017 @07:27PM
(#15848822)
Here's to hoping they change the name from Channels as to not overload the name even more w/ all the existing web socket/buffer implementations out there (e.g. web socket channels for Django or Elixir, buffer channels in Go or Clojure core.async)
Re:How We’re Designing Channels
by mintplant on Monday December 04, 2017 @08:07PM
(#15849000)
My first guess was a group chat service, segregated by programming topics. "Channels" suggests realtime flows of information; something like "Silos" would more closely resemble this product.
Re:How We’re Designing Channels
by nthaoe09ntaeont on Tuesday December 05, 2017 @12:26PM
(#15853384)
I love Stack Overflow, but what exactly is the point of this? It seems like they're trying to implement Slack, which itself is a fairly terrible idea. What problem does this solve that isn't already solved by others?
> For example, when developers need to ask their teammates questions, they tend to default to the tools that they’re already using daily: namely, chat and email. But those tools have their own problems. Chat is ephemeral and tough to search, and email is inherently limited to the people included or copied in. Both tools put a lot of strain on the few developers at a company who know the answer to a given question, and neither method excels at storage and recall.
https://stackoverflow.blog/2017/11/09/why-channels/
> For example, when developers need to ask their teammates questions, they tend to default to the tools that they’re already using daily: namely, chat and email. But those tools have their own problems. Chat is ephemeral and tough to search, and email is inherently limited to the people included or copied in. Both tools put a lot of strain on the few developers at a company who know the answer to a given question, and neither method excels at storage and recall.