GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-11-15) - page 1 of 10
 
___________________________________________________________________
Code together in real time with Teletype for Atom
567 points by hswolff
https://blog.atom.io/2017/11/15/code-together-in-real-time-with-...
___________________________________________________________________
 
AriaMinaei - 6 hours ago
Is it only a coincidence that real-time collaboration is being
announced both for Atom and VS Code
(https://news.ycombinator.com/item?id=15704376) at the same time?
 
  Egidius - 6 hours ago
  I was just noticing the same, looking at my HN feed. It's higly
  remarkable, to say the least.
 
  __BrianDGLS__ - 6 hours ago
  Came here to make the same comment :D
 
  JPKab - 6 hours ago
  The fact that VS Code's version isn't ready yet, and Atom's is
  makes me think that Microsoft wanted to respond to Atom's
  announcement.  But I honestly have no idea if that's the case.
  Just pure speculation.Edit: Atom's announcement was yesterday.
  Microsoft's was today.  That further fuels my speculative hunch.
  :)
 
    nikon - 5 hours ago
    Are you sure Atom's was yesterday? The blog posted is dated 15
    November.
 
    amadeusw - 6 hours ago
    Microsoft employee here. Today is also the Connect conference.
    My colleagues who worked on live share knew all along that
    Connect is their deadline.Which makes me curious, does Github
    know what Microsoft is going to announce at their conference,
    or did Microsoft knew what Github is building?
 
      atmos - 5 hours ago
      It looks like one of the main authors of atom is presenting
      today at QConSF too. Seems like dumb luck. :D
 
        haacked - 3 hours ago
        Yeah, appears to be dumb luck. You don't put together
        branding and a demo of real-time collaborative editing in a
        day.
 
          twitchard - 2 hours ago
          My hack-a-thon team did it in 48 hours this weekend, lol.
          https://www.nodeknockout.com/entries/35-nodeist-colony
 
          IMTDb - 42 minutes ago
          You put developed "the world's most advanced code
          collaboration experience" as advertised by the website in
          48 hours ? Can I hire you somewhere ?
 
          sixdimensional - 42 minutes ago
          I prefer to imagine that great minds think alike!  :)  Or
          more scientifically speaking, the theory of multiple
          discovery [1].[1]
          https://en.wikipedia.org/wiki/Multiple_discovery
 
      smilbandit - 4 hours ago
      not sure it really matters, either way, we win :)  By we I
      mean coders.
 
    bad_user - 5 hours ago
    Microsoft is not known for finesse in their marketing
    tactics.Just had a d?j? vu with Microsoft's NetPC, announced
    just after Sun Microsystem's Network Computers.That said, I do
    like VS Code very much. Gave Atom a try, but it felt sluggish
    and its add-ons were very fragile.
 
      g051051 - 5 hours ago
      VS Code is certainly neat, but with the rush to cram
      everything into it, it's starting to feel more like emacs
      than vi.
 
        bad_user - 4 hours ago
        That VS Code is not Emacs-like, that?s my problem with
        it.In my experience nothing beats Emacs at editing text.
        Vim has better shortcuts, but Emacs is just smart about
        everything.My problem with Emacs is that it?s showing its
        age, it?s hard to configure and you have to learn an old
        and obscure LISP dialect for it. On the other hand I?ve
        heard that VS Code plugins are a joy to develop, MS
        apparently did a good job at that.But Emacs? Yes please, I
        want that ? plus to be honest, in 20 years from now Emacs
        will still be around, whereas I have my doubts about these
        fancy new editors.
 
          signal11 - 3 hours ago
          > you have to learn an old and obscure LISP dialect for
          itAs someone who is glancingly familiar with emacs (I
          have only ever written one elisp function, that too with
          help) it's a really stupid question, but couldn't emacs
          have bindings for lua or python or something? That would
          increase the number of people who can program for it and
          customize it.> in 20 years from now Emacs will still be
          aroundI think the real risk for emacs is, over the years,
          slowly losing the pool of people who care enough to
          contribute to it -- not just core developers, but also
          people who write packages, themes, etc. I already see a
          lot of developers who think Atom / VSCode / Sublime Text
          is "good enough". You may choose to discount Sublime
          because it's closed source (I do despite loving it
          otherwise), but VSCode and Atom are open-source and
          browser technology is only going to get better.
 
          chaoky - 2 hours ago
          Elisp would still a better much better language than
          python or Ruby (for emacs), especially now that lexical
          binding is becoming standard. Emacs people would like to
          move to scheme, if anything. (even RMS wishes emacs would
          move to scheme.)
 
        jsight - 4 hours ago
        So you think it is awesome then?
 
          g051051 - 4 hours ago
          Nothing but love for emacs, props to those who use it.
 
        dbmikus - 4 hours ago
        I doubt any Electron-based editor is going to feel as
        snappy and light as Vi. Have you been noticing performance
        decreases? I haven't noticed any.
 
          Barrin92 - 3 hours ago
          > feel as snappy and light as Vi.this is only true if
          we're strictly talking editing text wihtout any plugin
          functionality. As soon as you add code completion
          features vim shows its age, the Ale extension for async
          linting for example feels very sluggish on a few only
          slightly dated laptops I tried out and frequently grills
          the cpu.
 
          foldr - 2 hours ago
          This. Vim also has a nasty habit of hanging completely if
          something goes wrong at the filesystem level (e.g. a
          disconnected sshfs mount).
 
          ayushgp - 4 hours ago
          VS Code is trying hard to be an IDE for all languages. If
          you use pure VS code without extensions, it quite snappy.
          But as you start adding more and more extensions, it
          starts slowing down and that too quite fast.
 
          [deleted]
 
          drunkkcunt - 2 hours ago
          This is true, but its still very snappy for an electron
          app.After adding around 10+ plugins on Atom it not only
          became slower but it started crashing or having internal
          errors.With VS code I have 17 plugins installed and it
          still feels light enough. Personally I disable most
          plugins until I need them and I think most people should
          do the same considering how easy it is to disable a
          plugin.I have all my language specific plugins disabled
          until I need to use them.
 
        zimablue - 5 hours ago
        But?
 
          g051051 - 3 hours ago
          Just making the point that it went from a simple text
          editor to a much more full-featured IDE wanna-be.  That's
          a bit of a paradigm shift to me.
 
          petre - 2 hours ago
          That's why I've been using Atom instead. Since 1.17 or so
          it got quite usable and it's getting better with every
          iteration. Nowhere near as fast as Sublime Text but
          usable for daily coding. I disabled the git plugin
          because we're using fossil. I hope it doesn't become an
          IDE like VS Code. At least they made the IDE packages
          separate.
 
    zardo - 5 hours ago
    I have a hard time imagining that Microsoft would make a
    decision like that in under 24 hours.
 
  acgIssues - 6 hours ago
  The main reason I read this thread was to compare both
  announcements.
 
  martinsuchan - 6 hours ago
  Wouldn't it be nice for VS Live Share and Teletype to be
  compatible on protocol-level?
 
    frizkie - 4 hours ago
    That would be nice. https://xkcd.com/927/
 
      TimTheTinker - 2 hours ago
      I don't think VS Live Share counts as a standard, though. :)
 
  api - 5 hours ago
  Why is there breakneck competition here to offer the best free
  code editor?
 
    keithnz - 3 minutes ago
    What I'm interested in is whether Live Code Share is a free
    service.... feels like it might be a paid service.  Or limited
    free then pay?  Not sure.  It's also for visual studio.Also be
    interesting if someone makes a teletype plugin for VSCode :)
 
    smacktoward - 3 hours ago
    Ballmer's Law: "Developers, developers, developers." If you
    want to be a platform vendor, you need to have developers. Lose
    the developers and you lose the business.Microsoft has been a
    platform vendor for a long time. VSCode is part of their
    argument for why they should continue to be one.
 
    [deleted]
 
    adtac - 5 hours ago
    I know, right? Vim and emacs should ease off a little :)
 
    alfonsodev - 4 hours ago
    I guess that when users make the habit of using the free tool,
    then the company that provides it can easily embed other
    convenience habits that could potentially lead to a future
    sale.Both Microsoft and Github have commercial products to sell
    at a later stage, VSCode has now integrations with Azure, I
    don't know about Github integrations on Atom but the potential
    is there.When the user is using your free tool you are one step
    closer to provide something additional that is so convenient
    that is hard to say no, even if is paid.
 
peterkelly - 5 hours ago
Am I the only one who finds it ironic that the development teams
behind the top two open source editors introduce support for
collaborative editing on the dame day, apparently unaware that they
were both working on the same thing, and there being no evidence of
collaboration between the two?
 
  heartbreak - 4 hours ago
  > the top two open source editorsSubtle.On-topic, I remember
  recently Uber and Lyft were working on a similar feature, and
  both knew about the other but neither knew that the other knew. I
  wish I could remember what the feature was.
 
    sac2171 - 3 hours ago
    I believe this happened with Lyft Line and Uber Pool.
 
      heartbreak - 1 hours ago
      That?s the one! Thank you!
 
  krallja - 4 hours ago
  > top two open source editorsI must have missed the announcements
  for vim and Notepad++.
 
bousaid - 5 hours ago
Atom?s detriment with this post is that there?s 4 paragraphs of
text before I can even see what this feature looks like, and even
then it?s gifs on how to install the feature.
 
  level - 4 hours ago
  The marketing site does it better [1].[1]
  https://teletype.atom.io/
 
[deleted]
 
reaperducer - 6 hours ago
This reminds me of that rant from last week about how computers are
less functional these days than they were in the 80's.  The reason
is that the Amiga had cooperative document editing way back when.
(Sorry, can't remember the programs that supported it.)/Some
version of AmigaDOS also had truly relative timestamps.  So you
might see a file last accessed "Christmas, 1991."
 
120bits - 5 hours ago
I have never tried real time collaboration. What scenarios are
there when you need real time collab. I know technical interviewers
prefer this. Do you think it causes distraction when you have 2
people writing code on a same file. I would rather one finish and
then do my stuff.
 
  Antrikshy - 5 hours ago
  Ever been to a hackathon? It's hard to coordinate over Git when
  you're just getting started on a codebase and there's barely
  anything for the 3 other people to work on. I've used Cloud9 for
  this very successfully in the past.
 
holman - 6 hours ago
Lovely seeing Nathan and co ship this.Interestingly enough, this
feature is the primary reason behind Atom itself existing. We saw
the first internal demo of "Atom" (I believe it was "Thunderhorse"
at the time) 6-7 years ago, and the main idea was real-time
collaboration on code. That sorta took a backseat for awhile as
GitHub started to recognize that a collaborative editor was pretty
swell in its own right, but glad to see that it's finally all come
full circle.
 
  indescions_2017 - 8 minutes ago
  This one single feature could potentially have the largest impact
  on my workflow in 2018. As much as I love async task management.
  Real-time collaboration with remote team members should be
  fascinating ;)
 
ovrdrv3 - 5 hours ago
Awesome! It worked with the same github account over two computers
as well! This is exciting.
 
AbenezerMamo - 3 hours ago
Amazing! Love it :)
 
jimnotgym - 3 hours ago
Were Microsoft and Github using some kind of collaboration tool?
Calendar syncing perhaps?
 
fro0116 - 6 hours ago
Curious if this supports multiple-cursors (as in multiple cursors
per user through ctrl/cmd+d, etc)? If so that'd be awesome!
 
  jasonrudolph - 6 hours ago
  It does indeed.
 
    fro0116 - 6 hours ago
    Beautiful!
 
killnine - 6 hours ago
Really gave atom a hard try. Back to notepad after a few months.
The add-ons are the only advantage, but are grossly overshadowed by
the resource consumption this behemoth requires.
 
  Syntaf - 4 hours ago
  As did I, but I just couldn't get over how slow it was.Startup
  time on windows was rough, meaning I had to remove it as a
  default editor almost immediately for most filetypes. Worse off,
  opening large files would grind Atom to a halt and usually lock
  the editor up.Beyond the performance, I thought it was a great
  text editor. The problem is I just have no use for a slow-to-
  start editor when I can just DL vscode and get the same features
  with considerably better performance.
 
  vlunkr - 6 hours ago
  I really hope you mean notepad++ or something
 
  melling - 6 hours ago
  Yeah, someone complains about the resource usage in every Atom
  post.I feel likes it's a rehash of emacs vs vi debate from 30
  years ago.  Emacs needed many megabytes more than vi so people
  wouldn't use it.As time goes on the resource usage becomes less
  of a problem.  My 4 year old laptop has 16GB of RAM and I don't
  really worry about it. I'll get 32GB or 64GB in my next computer.
  I never liked quibbling over memory. My time is much more
  important to me and I want the best tools. I also want them to
  swim in RAM.
 
    dingo_bat - 6 hours ago
    > My 4 year old laptop has 16GB of RAMEven now the highest end
    laptops have same 16GB RAM. Sad state of affairs :(
 
      anoother - 6 hours ago
      For certain definitions of 'high-end', maybe. You've been
      able to configure workstation-class laptops with 64 gb for a
      few years now.And most mid- high-end laptops will happily
      accept 32GB, again going back a few years.(Broadwell removed
      the density limitation that made 16GB DIMMs a no-go; anything
      that takes DDR4 should support 16GB SODIMMs, excepting the
      very low end Atom, Celeron etc.)
 
        discreditable - 5 hours ago
        Why am I expected to have a workstation-class laptop to run
        my text editor?
 
          maxbrunsfeld - 5 hours ago
          You really aren't. Atom runs fine on a Macbook Air. There
          are definitely performance issues, but we're addressing
          them; it's just that our team is small and our initial
          goal at launch was to produce the most hackable text
          editor possible.
 
          valesco - 4 hours ago
          I had to drop Atom when it began launching white flashes
          when scrolling on a 2011 MBA. I saw that this was a
          recurring problem. Is that an issue that is being
          addressed?
 
          maxbrunsfeld - 3 hours ago
          Do you remember if there was an issue opened for this on
          the Atom repo? I haven't heard of this problem.
 
    Shorel - 6 hours ago
    >  My time is much more important to me and I want the best
    tools.That's what I think, and the reason I use SublimeText.
 
      esMazer - 5 hours ago
      I don't mind resource usage, but I want speed!  and
      SublimeText delivers on that front!
 
    outworlder - 4 hours ago
    Yes, Emacs stands for "eight megabytes and constantly
    swapping". How silly this sounds today.I wonder why do those
    people even care.The only time I look at my resource usage is
    when apps start to behave funny. Or when it's an app that I am
    developing. Other than that, why should one care?One argument
    could be made that they are using memory wastefully. Not sure
    that's the case. The baseline memory consumption is higher, so
    what? It's a tradeoff. It's easier to build a better editor
    using browser-based tools, as much as I like Elisp. Over time
    Atom and VSCode will close the gap.Now, if there is a memory
    leak, or memory increases non-linearly with the workload, than
    it could be a problem. VI and Emacs are pretty great with large
    files (Emacs not so great with long lines), browser-based
    editors usually do not work as well. But there is no reason
    they shouldn't, it just takes engineering effort.
 
      YaLTeR - 3 hours ago
      A text editor using 600 MB of RAM to open a file is
      ridiculous. That with a couple of Chrome tabs grinds my
      laptop to a halt.
 
        outworlder - 3 hours ago
        Why? Unless that pushes you to swap, that is not the cause
        for your slowness.
 
      pmoriarty - 3 hours ago
      "Yes, Emacs stands for "eight megabytes and constantly
      swapping". How silly this sounds today. I wonder why do those
      people even care."Well, because if an application you're
      using is constantly swapping, it'll slow that application
      down to a crawl.  This was especially true back in the day
      when disk was slow (and expensive.. as was RAM).People today
      are used to being awash in resources.  RAM is fast,
      plentiful, and cheap.  Disks are relatively fast and
      cheap.You have to imagine what it was like to live in a
      resource-constrained environment where you actually had to
      care about how much memory and disk you used, and how you
      were using it.  These decisions had severe, immediately
      apparent practical consequences.
 
        outworlder - 3 hours ago
        Sorry, I wasn't clear enough.What I meant to say was that
        "eight megabytes" sounds silly today. Who cares if an app
        uses 8MB today? The extrapolation is that it will be the
        same for Atom or other editors (I'd argue that it already
        is).I created my first programs with a computer which had
        exactly 28815 bytes free when it booted up (out of a
        possible 64k). If you plugged in a floppy drive, the free
        memory dropped further.So, I do understand resource
        constraints.Btw,
 
    andoma - 6 hours ago
    Personally I don't mind RAM usage that much. I'm more concerned
    about excessive CPU usage resulting in unnecessary battery
    drain on my laptop or annoying fan-spinning.
 
      fro0116 - 5 hours ago
      Atom for me consistently sits at 0-0.1% (mostly 0) CPU usage
      when idling. You may want to investigate some of the
      extensions you're using if the numbers are different for you.
 
        RussianCow - 3 hours ago
        It's probably not idle CPU usage that the parent is
        complaining about.
 
        andoma - 2 hours ago
        Yeah, this was more a generic comment not specifically
        aimed at Atom. Sorry if that wasn't clear.
 
    nulagrithom - 6 hours ago
    > As time goes on the resource usage becomes less of a
    problem.Yet vim is still more popular today by a wide margin.
    :)It's not just about memory usage; it's about lag. Atom felt
    laggy to me. I also value my time, and I can't stand waiting
    for my editor.
 
      have_faith - 5 hours ago
      It was the lag (and at the time, struggling to open "large"
      files) that stopped me giving it more than a cursory check a
      year or so ago. No idea if it's worth looking into again?
      Would be hard to beat sublimes snappiness doing almost any
      task.
 
        outworlder - 4 hours ago
        Sublime is still faster.But try VSCode. I do not notice any
        lag on the Mac.I still prefer Emacs due to the maturity of
        its packages. But I have used VSCode for a month and I have
        no complaints about the performance.
 
    pmoriarty - 3 hours ago
    "I feel likes it's a rehash of emacs vs vi debate from 30 years
    ago. Emacs needed many megabytes more than vi so people
    wouldn't use it."The thing is, this was in fact a valid
    critique of Emacs back in the day, and it cost Emacs users.  I
    know I stopped using it back then partially because of its
    resource use (and because it was a lot slower than vi and
    because of its finger-twisting keyboard shortcuts).If Emacs was
    as light on resources as vi was back then, it would have more
    users today.
 
  maxbrunsfeld - 6 hours ago
  Sorry to hear that. We?re improving Atom?s efficiency all the
  time, but there are definitely areas that we just haven?t gotten
  to yet.
 
    pier25 - 54 minutes ago
    I think you are doing a great job.I've been using Atom since
    2015 and it's only getting better on each new version.I tried
    going back to Sublime which has objectively much better
    performance but that doesn't make the whole experience better.
    It's like sitting in a Formula 1 car with no cushion and no AC.
 
    adtac - 5 hours ago
    In your opinion, what, if improved, will give Atom the biggest
    performance boost?
 
      maxbrunsfeld - 5 hours ago
      I really want to create a public-facing roadmap that's
      specific to this issue. Unfortunately, our resources are
      limited so we often don't focus enough on
      blogging/publicizing our planning... but in the meantime,
      here's something of a brain dump:In terms of our actual data
      structures and algorithms, we're already starting to be in
      really good shape. We've dropped a number of components of
      our core TextBuffer to C++, ensured that most of our
      algorithms scale logarithmically with file size, cursor
      count, etc, and made use of native threading for important
      operations.1. The one remaining structure that we need to
      drop to C++ is what we call the 'display index' - the thing
      that stores the locations of things like folds and soft
      wraps. Once we do that, opening large files (which is already
      reasonably fast) will be like butter.2. Our find-and-replace
      is already pretty good - you can type without almost any lag
      even when we're storing the locations of millions of search
      results. But now that we have the ability to easily use
      background threads, there are some easy optimizations we
      could do there. The search results could really update
      instantaneously, we no longer need to wait until you pause
      when typing in the search box.3. We have in the works a major
      change to our syntax highlighting system using my incremental
      parsing library Tree-sitter. Once this lands, it should
      eliminate any perceived latency in syntax highlighting (as
      well as enable a host of great syntax-related
      improvements).4. Atom still uses synchronous IO (which blocks
      the UI thread) in some places. This is because it was created
      before GitHub created Electron, so node APIs were not
      available from the outset. Many of these have been
      eliminated, but there are several Git-related code paths that
      we still have not updated. This probably kills the experience
      of editing on remote drives like SSHFS for some users. We
      need to revisit these code paths.
 
        frik - 4 hours ago
        What are the current plans about Coffeescript? I just
        looked at the code on Github, it says 85% Javascript, 12%
        Coffeescript. Is the plan to port the 12% to JS6? (and
        hopefully not Typescript)Great work with Atom editor. I
        successfully conviced my friends to move from VSC to Atom
        on macOS.
 
          free_everybody - 4 hours ago
          What's wrong with Typescript? Also, why does it matter to
          you? Genuinely curious.
 
          frik - 4 hours ago
          Curious, Why does it matter to you?On the Atom.io website
          https://atom.io/ it reads "A hackable text editor for the
          21st Century". Well I can code in JavaScript 5 and 6. I
          love love it when a project sticks to web standard, and
          not have to worry about slangs I don't care about.>
          Typescript is great at catching bugsThe same with
          JavaScript. Google Closure compiler and anyway most IDEs
          "understand" JavaScript too and catch bugs. JavaScript is
          dynamically typed not typeless.
 
          free_everybody - 2 minutes ago
          I was surprised to see someone who cared what style of
          javascript a program is written in, especially if they
          aren't an active contributor. Maybe you are?
 
          marcoms - 4 hours ago
          Typescript is great at catching bugs which would trickle
          down to the end user
 
          z3t4 - 2 hours ago
          It's like having Leonard Cohen transpiled to Justin
          Bieber. Now look at it from the Justin Bieber fans point
          of view, why would they listen to Leonard Cohen in order
          to hear Justin Bieber ? Even though research says Leonard
          Cohen makes better music! From Leonard Cohen fan's point
          of view it doesn't matter as they only hear Leonard
          Cohen, not Justin.
 
          maxbrunsfeld - 4 hours ago
          Thanks! Yeah all of the CoffeeScript in atom/atom should
          be gone in a few months probably. We use plain JS
          now.It'll probably take a while before there's no more
          CoffeeScript in the entire Atom org. We're gradually
          converting the code to JS as we come upon it for other
          reasons.
 
          frik - 4 hours ago
          Thanks!
 
minicoolva - 9 minutes ago
I'm using vs code now
 
tomaskafka - 1 hours ago
The use cases don't need to be remote. Really looking forward to a
chrome/firefox plugin that would sync a textarea with a new Arom/VS
code buffer!(Why? How many of you have edited some config/sql
query/... in past week?)
 
BoiledCabbage - 4 hours ago
I don't use it at all, but hasn't emacs supported this since the
80s or 90s?
 
  scbrg - 2 hours ago
  Not sure if there's been a way to integrate separate emacs
  processes, but it has always been possible to launch a new frame
  (emacs speak for window) displaying the same buffer, and given
  network transparency in X, have it displayed on any remote
  computer running X.
 
xrd - 4 hours ago
Anyone using this to edit Android source files? I need to look and
see if Android Studio has anything similar.
 
sleepybrett - 5 hours ago
I miss subethaedit
 
buryat - 6 hours ago
I wish there was something like this for Intellij.
 
  sscotth - 6 hours ago
  Floobits works with Intellij as well as Neovim, Emacs, Sublime,
  and Atom.I'd like to explore whether Teletype can be used across
  editors in a similar manner.
 
    fro0116 - 6 hours ago
    It's almost certainly _possible_. See under "Editor-agnostic
    client library", and https://github.com/atom/teletype-client
 
kakuri - 1 hours ago
For VS Code there's sockscode, it's a little bare, but works well!
https://marketplace.visualstudio.com/items?itemName=shyykose...
 
Animats - 2 hours ago
It's amusing to see this while building in Second Life. The Second
Life build tools are a 3D CAD system with real-time collaboration
in virtual reality. Several people can be editing the same set of
3D objects simultaneously. Others can stand around and watch, from
different viewpoints.Doing this for text is trivial by comparison.
 
fjabre - 2 hours ago
I can appreciate your efforts here. It isn't trivial to put
something like this together but I'm going to go ahead and state
the obvious: Face to face is far superior to a solution such as
this one for what I think are self evident reasons. You're better
off, by orders of magnitude, getting on a plane or train and going
to see your code buddies.When I'm coding with someone we're not
usually on the same files or piece of code anyway. And I don't get
any value from seeing them type away at the code file that they are
focused in, or knowing which file they're in beyond the name. It's
a simple "hey mate what line are you on?" question.I get excellent
value from talking to and seeing the other devs face to face
figuring out where their head's at and what 'page' they're on.
That's the stuff of a proper realtime and face to face code sesh
IMHO.
 
  seveneightn9ne - 2 hours ago
  Being together in person doesn't solve the problem of wanting to
  edit the same code simultaneously. For some projects, git is
  enough, but for something really small this seems like it would
  really help.
 
    fjabre - 2 hours ago
    I'm not saying it isn't a legitimate problem but I've never had
    it.For me, if we're not using git I could get the other dev's
    latest changes by simply doing a file copy of whatever I needed
    and then get it into my own environment. I work offline with
    most of my dev mates. We are rarely ever coding at the same
    time of day given time zone differences and sleeping
    patterns.If we're a small team we're probably quite aware of
    where the other one is in the code and what they're working on.
    I don't need real time for that.I think being able to see the
    other dev type in real time in the same file doesn't solve
    anything for me and may in fact be distracting and counter
    productive. I'm not sure 'real time' fits here.
 
      brandall10 - 1 hours ago
      "We are rarely ever coding at the same time of day given time
      zone differences and sleeping patterns."This is to aid pair
      programming.  I work on a remote team as well, but there are
      times we pair when hashing out of a particular issue that
      either myself or one of my teammates is having.  It's far
      quicker to do this than to work disconnected and go back and
      forth, esp. if it may impact the schedule/sprint.  In the
      past I've worked with devs that had as much as a 10 hour time
      difference and we literally scheduled  times where our
      schedules crossed so we could pair on a specific issue.  One
      person drives at a time but it's common to switch back and
      forth so tools like this are helpful.
 
Dryken - 3 hours ago
I so want this for visual studio code now :)Really cool stuff !
 
  GilbertErik - 3 hours ago
  You mean something like
  this?https://code.visualstudio.com/blogs/2017/11/15/live-share
 
twitchard - 2 hours ago
My team at the Node Knockout hackathon implemented an editor-
agnostic version of this feature last weekend. I guess it is an
idea whose time is come.https://www.nodeknockout.com/entries/35
-nodeist-colonyFor me, the editor-agnosticism is the most important
feature I would want my live coding experience to have. My team
uses a mixture of Vim, Sublime, Emacs, VS Code, and Atom, and we
have configurations we are comfortable with. It's too bad that this
seems to be happening well within the confines of each editor's
ecosystem, and not by some common protocol that all editors could
share.
 
  cbcoutinho - 2 hours ago
  The team behind this feature think that editor-agnosticism is
  also really important, that's why they split up this project into
  atom-teletype and teletype-core. AFAICT the 'core' library could
  be used to implement a package in any of the electron based
  editors.
 
    derefr - 2 hours ago
    Could the protocol implemented by teletype-core be (easily)
    spoken by a non-electron editor, or is there an inherent
    impedance mismatch where  e.g. the protocol structures its data
    in ways amenable to DOM manipulations of text but not to other
    text buffer formats?
 
      maxbrunsfeld - 2 hours ago
      The protocol isn't coupled to the DOM or Electron in any way.
      The one thing that makes it easier to implement in electron
      is that it uses the WebRTC standard for peer to peer
      connections.
 
        Karrot_Kream - 1 hours ago
        WebRTC is a beast of a protocol to implement, and so far
        browsers have had the canonical implementation. There's a
        few C++ libraries out there, but even then it's a lacking
        ecosystem.
 
liamdanielduffy - 6 hours ago
?participants all keep their own custom key bindings, packages, and
themes.?what happens when two different people editing the same
document have two different settings for # spaces per tab
character? whose takes precedence? (Or would there be a possibility
of inconsistent spacing depending on who is adding a tab?)
 
  llimllib - 6 hours ago
  I would guess that tab -> spaces happens locally, and then the
  spaces are what's sent over the wire. So it would be whoever
  inserted the tab. (What other possibility could there be?)
 
    MsMowz - 4 hours ago
    Why would spaces be sent over the wire?
 
      RussianCow - 3 hours ago
      Why wouldn't they be? How else would you envision indentation
      working?
 
        thedaniel - 1 hours ago
        Well, one of the people in the scenario uses tab
        characters, not spaces.
 
          hobofan - 1 hours ago
          Why would someone do that? ducks
 
  have_faith - 5 hours ago
  Defaulting to whatever the document is currently using would be
  sane?
 
    hobofan - 1 hours ago
    The document isn't "using" anything, since a document is a
    passive object. Unless you have something like vim modelines
    where you configure it at the top of the file like `/* vim: set
    tabstop=8:softtabstop=8:shiftwidth=8:noexpandtab */  `, the
    document itself doesn't know anything about how things _should_
    be (which is the important part).
 
kimjongman - 5 hours ago
How safe is this?
 
jitl - 6 hours ago
See also Floobits, which is a fully-realized, production ready
service that allows collaborative real-time editing of your editors
entire workspace.Floobits has plugins for all major editors,
including Vim and IntelliJ, as well as Google
Hangouts.https://floobits.com/Disclosure: I used Floobits a few
times and think it?s awesome 10/10
 
  alexozer - 5 hours ago
  Tested with neovim, really does not work (you must edit greater
  than 40 lines away from each other or so, or else the editor bugs
  out).
 
  elliotec - 1 hours ago
  Floobits does not work. I've tried it several times hopefully. It
  simply doesn't do anything.Please enlighten us to how you got it
  to work at all. I use neovim.
 
  clebio - 6 hours ago
  Except, it's not Vim, it's Neovim.
 
    dopamean - 5 hours ago
    Might it work in vim8 now?
 
_pferreir_ - 3 hours ago
This looks really neat. As a side note, it bothers me a bit that
they haven't used an actual URI, e.g. tty:xxxxxxxx-xxxx-... That
would allow for nice hyperlinks from web pages and chat rooms.
 
mrspeaker - 4 hours ago
Not sure this is wise, but I started a test portal
252510f8-e474-45e0-bec1-5714435fa305 if you want to give it a
whirl.Edit: it's still working great even with 15+ people - very
slick!Also, here's the madness in repo form -
https://github.com/mrspeaker/teletest
 
  Klathmon - 2 hours ago
  I'm curious, how was the performance with all of that happening?
  (i'm assuming at some points you had 10+ people in there at
  once?)
 
    mrspeaker - 2 hours ago
    I just stopped sharing the document. I was just running it over
    crappy cafe wife for 2.5 hours, max ~20 people, always 5 to
    10... performance seemed fantastic - didn't tax my lappy at
    all. Very impressed![Re-shared it at 28e6c3b4-754c-
    44ef-9406-869604db9db5 - it would be good if you could keep a
    UUID somehow, but I guess that's unfeasible]
 
      sillysaurus3 - 1 hours ago
      Someone please build a game around this premise. 15+ people
      having fun in a shared simulation is prime territory for game
      ideas.
 
serg_chernata - 6 hours ago
Is there anything like this for sublime?
 
  metahost - 6 hours ago
  Floobits is all you need!
 
  SCdF - 6 hours ago
  Apparently the protocol can be implemented by any editor, so
  hopefully we'll end up in a glorious future where this works in
  lots of browsers (including VSCode, who just announced their own
  version of this)Edit: can in the future, not now. So we'll see
 
idontknowman - 46 minutes ago
This looks like a cool feature to use to teach.
 
mundanevoice - 4 hours ago
This is super neat. Would be awesome debugging with my teammate
when I am working remotely.
 
LesZedCB - 5 hours ago
i prefer this over floobits in that i don't need a floobits
account, just a github account, which pretty much all devs will
already have. it would be nice if there was a way to do this
without needing the github account though.
 
  sleepybrett - 5 hours ago
  With floobits though you can go ahead and use atom while I chill
  in vim or sublime. It doesn't demand that you both use the same
  editor.
 
    LesZedCB - 4 hours ago
    for now. since this is the framework, I think we'll see plugins
    for other editors soon enough.
 
LukeB42 - 5 hours ago
If you wish this existed for web pages:
https://github.com/psybernetics/synchrony
 
Dowwie - 4 hours ago
What software would you use to provide group voice chat for a
screen share session?  Discord?
 
  gh02t - 3 hours ago
  I've used Riot (https://riot.im , built on Matrix) and it worked
  very well. Voice chat is still in beta but I haven't had any
  trouble with it.
 
eecks - 3 hours ago
How does this work? Does the code that is typed go through a cloud
service? I guess that would stop a lot of people using it in work.
 
  dflock - 2 hours ago
  In the case of Atom, no - it's peer-to-peer - github servers are
  only involved with initial connection. Probably the same for VS
  code, but not looked.
 
    eecks - 1 hours ago
    Ok, that's pretty cool. Thanks - had a quick scan of the page
    but didn't see that.
 
  [deleted]
 
rahilsondhi - 6 hours ago
If you wish this existed in a SQL editor, we have it in PopSQL
(https://popsql.io)
 
s09dfhks - 2 hours ago
any way to use this WITHOUT a github account?
 
  neilparikh - 1 hours ago
  You can run the server yourself I think: https://github.com/atom
  /teletype-server