Atom 1.29 | Hacker News Reader

Atom 1.29

blog.atom.io

I see a GIF of someone going deleting a couple lines of code, with a meter showing that the application is maintaining 60 FPS. Was this not something Atom could do before? It seems to me that the bare minimum should be maintaining 60 FPS while performing basic editing tasks…is there some nuance here I'm missing?

The GIF is just intended to represent an idea - that parsing (for the purpose of syntax highlighting and other code analysis) can no longer impact the app's frame rate, because it has been offloaded onto a background thread. The actual operations depicted in the recording are not a performance breakthrough.

Ok, that's nice to know. I know my initial comment probably came off as the stereotypical Hacker News sneer, but in my defense the picture, at least to me (having not used Atom for more than four years due to its poor performance when I tried it in the beta) makes it look like Atom was having issues maintaining a decent frame rate for the editing task shown, and is now able to provide this.

Or, to put it another way: your depiction in the article really makes it easy for those who have reservations about using Atom to come to the wrong conclusion, and it's not one that paints it in a good light. Might I suggest replacing it with a GIF that showcases the actual issue that this release was supposed to fix?

That really depends on what you measure by "frame rate".

In a single-threaded setup, maintaining 60fps is likely impossible. You may think of "just deleting a few lines of code" as trivial. But syntax highlighting alone requires re-parsing, as will automated formatting, type inference, and whatever else we expect today. It's unlikely for this to be done within the 16ms frame budget.

If you're offloading such work to separate threads, you can draw the frame right away and maintain 60fps. But you won't be able to update all the meta-information and frequently see "flashes of unstyled code".

Then you probably don't appreciate what tree-sitter has to offer.

https://galois.com/blog/2017/12/tree-sitter-new-parsing-syst...

> bare minimum should be maintaining 60 FPS

Yours would be a nice world to live in.

I've seen IntelliJ and Eclipse both crawl when doing "basic editing tasks". Hell, Vim does it too if your line length is long.

> Hell, Vim does it too if your line length is long.

Or even if it is short if you're using LaTeX with syntax highlighting. This even has its own entry in the manual, called tex-slow (http://vimdoc.sourceforge.net/htmldoc/syntax.html#tex-slow).

But IntelliJ and Eclipse (depending on the language) run compilers to do code checking right? Certainly too many text editors don't work very well with large text files which is a bit funny.

Yes, Intellij and Eclipse are IDEs, like Atom.

Not sure why you think an editor should refresh it's view port 60 times per second while idle.

It's not exactly about refreshing 60 times per second, but actually, not hanging the main thread for more than 16ms at a time. That means it _could_ do 60fps if the user performs actions fast enough, not that it will actually update 60 times per second while idle.

I'm 99% sure this is just terminology lifted from games. Just means it runs at a constant fast rate.

I have seen changesets for Atom before that include something like "make typing faster and more responsive".

Generally most of those changes are for when someone is using 25+ cursors at once, or are in very large documents that reflow a ton on every character.

Typing a single cursor in most documents was never really an issue in Atom. But when you layer on a ton of plugins that do all kinds of stuff, and add in some complicated grammars with larger documents and lots of cursors at once, then performance would start to suffer.

I haven't used Atom for at least an year and a half now - After trying out Visual Studio Code I haven't looked back. Has the performance improved? Is it at the level of VS Code?

The one reason I'm still using Atom is because of the remote editing experience with Nuclide + Watchman server-side. No other editor that I've tried comes even close (the connection drops, files get out of sync, new files don't show up, etc, etc)

Given the huge number of people who work on remote servers, I find it surprising that proper solutions are still so hard to find. A "file system provider API" for VSCode is in the works so I'm hopeful for the future.

I am curious about your situation that causes you to edit files remotely. I've never had to edit files anywhere but my local file system. Are you developing or is it more of a devops/sysadmin kind of role?

I definitely use tramp a lot to remote edit files in Emacs. I suspect it depends heavily on the type of application your develop and your workflow, but it might also be that if you never really had the possibility to do that easily you might never really realize what you're missing since you're used to do things differently. It's a bit like X forwarding in that respect.

To give you an example of what you can do I often use tramp locally to edit files as root: instead of having to fire a different instance of an editor as root to edit a config file I can just do it "remotely" from my main Emacs instance, with all my config and without worrying about messing something up by having the entire editor running privileged.

I work in embedded development so I also often use it to browse and edit files on the live target system (beats using a crappy dumbed down vi from busybox). And of course as you mention for general sysadmin tasks it's also great, I'm a developer but that doesn't mean that I don't have some sysadmin to do from time to time.

I have to do it all the time cause I want to develop on a VM that matches the target platform for my project. Usually involves figuring out how to debug things. My solution is to install VS Code on remote system and use X forwarding depending on project. I also use PyCharm Pro so in such case I use Vagrant and it does its thing but it syncs awfully as OP mentions so debugging can become extremely painful idk why JetBrains has not fixed said issue customers have complained (remote SSH / Vagrant support is part of their paid tier).

This is my scenario at the mo, I've tried syncing the code dirs between the VM and my local machine but I haven't found a nice solution for that.

My current solution is just SSH/Vim but I think I'd like to go back to a graphical editor. I like Vim but sometimes it's a hassle on the big projects.

I use Vagrant w/ VirtualBox and setup shared folders, but it's not as nice when you want to debug or execute code. PyCharm Pro has great support for Vagrant though it sucks at updating certain things on the server end.

One reason I use it is if I am working on an embedded device. Sometime I just want to go in and try a concept out that I couldn't just spin virtual machine up for.

I'm developing. It's useful whenever I need to work on a machine with a specific environment and/or more bulky hardware than what's available on my laptop.

I've spent a lot of time trying to get a proper remote-editing/incremental sync setup working. That sounds really interesting to me.

How many files are you able to handle, remotely, with Nuclide/Watchman?

Does it work if the remote files are on an NFS share (i.e. spotty inotify/fanotify support) mounted onto the server you're SSHing into (no, the NFS share cannot be mounted directly on the workstation)?

How many file-change events (on your workstation or on the remote) can this system successfully sync/handle in a short time? If there is, say, a 250k file alteration that happens due to checking out a branch, is there an indication that it detected the changes and is making progress syncing them, or does that necessitate a manual sync?

Context: I've worked in environments where local editing and manual sync got really annoying: for compliance/regulatory reasons, certain tools, e.g. source control, were only available on the remote server, so having all code on my laptop and manually syncing to the remote got quite tedious. Even better, the significant (i.e. I might conceivably need to open them/run tests that touch them) number of source files in the remote repo was in the tens of millions. I wasn't able to get any incremental sync/change-detection systems working successfully: on my workstation (OSX), large changes would overflow the fsnotify kqueue, no matter what wrapper around it I used. On the remote, watching was either unavailable (due to the age of the Linux server) or prone to failures in the event of large changes in files (e.g. checking out a new branch).

I've spent a lot of time mucking about with lsyncd, unison, and lots of other tools, and eventually gave up with the conclusion that directory-diffing is too slow given slow remote filesystems, and change notification systems aren't up to the task of managing bulk changes across a huge repo. Watchman sounds really promising here; I'd love to hear more about your experiences with it.

I don't think I've reached the limit of how many files Nuclide/Watchman can handle, everything is perfectly smooth with very large codebases.

However, things don't work as well with an NFS share and I think you get an explicit warning when you try to do it.

At Facebook most of our thousands of web devs use Nuclide for remote editing on a repo with hundreds of thousands (or millions) of files and it works as advertised. We don’t use NFS though; all the repo checkouts are on disk on the remote machine.

I've got a couple co-workers who feel the same. I've always just used ssh/vim in such cases, but apparently the remote-editing experience on VSCode isn't nearly as good as that of Atom for some reason. Otherwise, I really love VSCode, the only thing it lacks for me now is the ability to separate tabs into different instances/windows but that's more of an electron issue. I've pretty much stopped using jetbrain's products in favor of it.

Can you explain a little more about the remote file editing workflow? Is there an article I can reference or something?

The official documentation is here: https://nuclide.io/docs/features/remote/

One of the steps is to install Watchman. If your remote server is on Linux, make sure to read that part of the docs: http://facebook.github.io/watchman/docs/install.html#linux-i... (In my case I just set the three settings to 999999)

Finally, you may need to create a .watchmanconfig file at the root of the folder you're working on.

We just use Vim or Emacs over SSH in such cases, or if the connection is good enough over X/RDP.

With Emacs you use it locally and edit via tramp.

One of the main reasons I use Emacs whenever I do use Emacs. Though now I just do VS Code and X forwarding.

I never heard of tramp, thanks.

You might enjoy Mike Zamansky's blog post and short video about it: http://cestlaz.github.io/posts/using-emacs-25-tramp/#.W2HhPH...

Also, the manual is pretty good. It comes with Emacs, of course, or can be read at https://www.gnu.org/software/tramp/

My favorite thing about TRAMP is how well integrated it is. It's not just opening remote files, you can also open shells on remote systems, or do file management with dired (I have a bookmark pointing to dired on a remote system I use frequently, for example.)

We've also been in the same boat as you guys. Starting to just look into VSCode as an alternative, then immediately switching to it after realising the performance difference is like night and day.

Since Atom doesn't provide anything that we can't install in VSCode as a plugin, there really is no reason to use Atom right now. The only problem I had with VSCode was the default interface, that I modified with plugins until it pretty much looks like Atom, but runs way faster.

I still use Atom mostly because of the default interface. Care to list the plugins that you used?

Of course. The most useful ones are the following:

- Bracket Pair Colorizer

- EditorConfig for VS Code

- ESLint

- Git Blame

- Material Icon Theme

- Path Intellisense

- Prettier - Code Formatter

- SCSS IntelliSense

- TSLInt

- Winter is Coming Theme by John Papa

Emmet.

I get why people use it, I just don't have any use case for it. I'd rather write my code myself instead. Just a personal preference though.

I don't find the code generation stuff that useful but I found it useful for its text manipulation features - like selecting all text within 2 nodes, editing a start and end tag at once.

To each his preference, I suppose. But I definitely could imagine a far more difficult life without Emmet.

I've a similar story and several teams at our company have switched to VS Code independently. There are some Atom "believers" though.

I hope github is going to continue working on Atom independently from MSFT. Competition is a good thing. But since both products target the same audience, from Microsoft's perspective I'd understand if they'd bring those brilliant minds together in one team.

For what is worth, in an AmA Nat Friedman stated that development of Atom will continue "as long as there's people using it", and they will probably share some code between vscode and atom (they already do)

I've bounced back and forth between Atom and VSCode - the main reason for me has been bugginess with prettier plugins. I've had more weird issues with the VSCode one, so I've leaned more on Atom.

Perf for VSCode is definitely much better though.

Is this still true? I tried Vscode / Atom the other night and Atom performed better for me, at least for the time it took to render the syntax highlighting of each file.

I had a similar experience with performance was an issue for me so I switched over. Never went to back to test any of their newer releases.

Sadly, no. I tried it out again a couple of days ago and the performance is still terrible. I'm in the same boat as you and switched to VS Code.

I hope xray[1] catches up. I prefer atom's UX-UI to any other editor but I agree that performance is still an issue. MS taking over Github doesn't seem to bring to a bright future. I really hope I'm wrong.

[1] https://github.com/atom/xray

With xray focusing away from improving the editor experience and more on this new version control thing [1] for now, it doesn't seem like we'll be seeing a GitHub-provided alternative to Atom for some time.

[1] https://github.com/atom/xray/blob/master/docs/updates/2018_0...

In an AMA the future CTO said they would never get into text editor politics by merging the two or taking one away. Both editors will remain.

I have the same question. I've never bothered looking back extensively at Atom since using VS Code.

Similar history with Atom, but I haven't looked back after switching to spacemacs :)

I don't understand the desire for all the git integration into the editor. I mean, it might make sense because Atom is owned by Github, but why otherwise?

I feel like a lot of their resources are being put towards git integration instead of improving the editor and performance... which are some of the primary reasons people leave for VSCode.

Maybe I'm the odd man out though, since I like to use CLI git directly.

I've been using PHPStorm's Git interface for a while now, and as a lover of CLI tools, I can definitively say I will never use command line git again. Hello `Smart Checkout` goodbye `git stash; git pull; git checkout branch-2; git stash pop`. Hello clicking one line and hitting revert on that one line, goodbye trying to revert that one line with `git diff` output or whatever.

A good git interface really is a game changer and can speed up your workflow quite a bit, especially if you utilize feature branches/git flow.

I felt the same way as you do, I used the git CLI directly and could never use a git GUI.

But then I figured out that Atom's git integration is actually quite neat and I started using it mostly to do `git add -i` as it makes staging files or parts of files really easy.

I still don't trust it with pushing/pulling, switching branches etc. so I still drop to the command line for those, but the atom git integration is incredibly useful for seeing your changes and committing a particular part of them.

I agree. I use the command line for everything but staging, and I often only stage parts of files while discarding a few leftover pieces I forgot about. I use sourcetree, but the concept is the same. GUI git is really nice for staging parts of changes. And then I usually commit via the GUI too, since I'm in there anyways.

I mostly feel the same. I don't like to customize my editor too much because:

1. That adds a lot of friction if you want to try out another editor 2. When it breaks, fixing things is not always easy. There are millions of git CLI users; you are probably the only one with your particular editor setup. 3. When I'm pairing with another developer, I don't want to be helpless when using their machine because they don't have the same intricate editor setup as me (or vice-versa)

There are a few things I use a Git GUI for, like staging/discarding chunks, or getting a nice graphical diff.

Having used (and loved) both Magit in Emacs and Fugitive in Vim, I totally get it. It's simply a pleasant experience to not switch contexts too far away from my editor. I certainly don't mind performing Git-related tasks in my terminal, I just like the flow provided by Atom's Git integration. At this stage in the game, it's not perf that's holding me back. Both Atom and VSCode perform well enough to be a daily driver. For me it's Atom's far superior Vim mode that keeps me using it.

At work, we use Git to store our docs (markdown) and Atom feels natural to write MD files in and to push updates. Most casual users understand what push and pull is but they are not really that comfortable to use git commands via CLI.

I have been swayed from using the CLI by emacs and magit. There are so many nice things like staging portions of a changeset, and the ability to get a quick visual diff of the changes before they are committed is really really nice. As to why they would work on it, the two main reasons I keep going back to emacs from Atom and VS Code is magit, and the ability to run in a console. to me Atom and VS Code are fast enough for my day to day work

I'm still undecided on using the CLI exclusively. Although I always use the command line for anything complex, I do feel like my editor of choice (VSCode) provides a fair amount of value with its simple file staging GUI. It also does a good job of showing diffs between versions in-editor.

Will Atom and Visual Studio Code merge into one project now that Microsoft bought GitHub? Or at least stop sharing extensions?

I would vote yes! I would love to see better GitHub integration in VS Code.

The "future CEO of GitHub" said they will continue to develop and support both VSCode and Atom: https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman...

HN discussion here: https://news.ycombinator.com/item?id=17258114

I just really hope they continue with this experiment: https://github.com/atom/xray.

It's reducing Electrons job to the view / plugin layer and have most processing done in a Rust backend.

There's also a similar project hosted by Google, Xi, which seems significantly more promising than xray.

[1] https://github.com/google/xi-editor

So Xi, is basically like an OpenSourced Version of Sublime Text in Rust?

If that is case, why Google doesn't just acquire Sublime Text and open source it?

Edit: Turns out Xi was burned out of Fuchsia, the next generation Android. So I guess Xi is tool for testing concept in Fuchsia. And it doesn't look like Xi will be amiable for general usage in the next 2 to 3 years time.

No Xi existed before Fuchsia became a thing.

It's a generic editor backend with an official GUI for OS X.

Yeah I've known about Xi for a long time, but it's moving very slowly and is just a hobby project of a Google engineer, nothing official.

Xray seems much more actively developed and actively managed by Atom developers.

Oh, didn't know about the "xray" project. So, the question I asked in 2016 is (in some way) becoming a reality: https://news.ycombinator.com/item?id=11308553

> The "future CEO of GitHub" said they will continue to develop and support both VSCode and Atom

They will "support" both by supporting VSCode and declaring Atom to be a subset of VSCode. I give it 8 months, tops.

Have you seen the upcoming GitHub PR integration in VS Code: https://github.com/Microsoft/vscode-pull-request-github

It's crazy that so fewer editors can fold code blocks in a compact manner, so that it hides line returns that are inside curly braces (might be a little trickier with python) including the ones which are just after and before those braces.

So far only visual studio (not code) can do it properly, and one which name I forget. I posted issues everywhere about it. I'm still disappointed, or it might be difficult to implement.

Scintilla (and scintilla-based editors) do this when `fold.compact` is set.

Don't vim foldmethods do this?

I wish I could use Atom but I work with very large files at time and it is very slow at some tasks (like selecting all selections of text and editing them all at once), forcing me to use Sublime Text.

Can some kind user tell me if this latest version performs better now?

Please don't take this the wrong way, but what do you need to do in very large files that requires a fancier editor?

I know people will give me shit for this, but this is one of the reasons why I like to have multiple tools for multiple use cases.

Atom is for development. It's for programming in source files and being basically an IDE that I have a lot of control and customization over.

When I need to work with long logfiles or hunt through large compiled text files, I use something like Sublime. And if the files get absurdly large (like 5GB+) I start reaching for CLI tools.

I completely understand that many don't want to work like that, and if it works for you then that's awesome! But I like my tools to be good at what they do, and if that means tradeoffs in areas that other tools are good at, then it's fine with me.

Even if Atom could never open a file over 100kb, I'd still use it daily, because it's plugin ecosystem, customization, and the ease that you can write very custom plugins for it is unparalleled. And if atom ever starts giving those things up to be able to open larger files, i'm going to be quite upset.

User-interface is still very laggy compared to Emacs but it opened large files much better than I expected, though it disabled syntax coloring for larger files and scrolling is really slow. I wonder how this compares to VS Code and Oni which are also built in Electron..

I've tested it myself as well. It is still as laggy as I remember, such a shame. I really want a simple graphical editor that can color the files that have been modified in Git.

large files aside, Sublime's startup time is what's keeping me.

> ensuring that parsing can never impact the frame rate.

This is exciting. Anyone has feedback anout how it actually impact performance?

I've been using 1.29 for a while in the beta with the new tree-sitter syntaxes, and i've noticed some changes.

It's not groundbreaking, but folding is definately better and more responsive, and using tons of cursors (which often happens from using a plugin that gives me sublime-style click-and-drag to place cursors ability) is improved by a noticeable amount.

The new parsers do regress when it comes to opening minified files though, so a 300kb file with the whole file "on one line" will drop the editor to 1fps (interestingly it only happens when something syntax highlighted is on the screen, so if I'm scrolling through a minified file and hit a large enough string that's not highlighted, the FPS picks back up to 60!), but opening 500mb+ logfiles isn't really an issue any more (meaning as long as there are linebreaks at reasonable points, and you don't mind waiting a second for it to open, it's pretty consistently fast). I'm not sure if that was the tree-sitter parser or other updates made in the last year, but at some point it stopped slowing down with "logfile" style large files.

Please keep in mind I have an... absurd... amount of plugins installed. I use this editor to do heavy javascript/flow development, as well as python and go and a bit of PHP, with a ton of "nice to have" plugins like automatic test runners, coverage reporters, "intellisense" style IDE stuff, and more for each language. It's also running on a pretty beefy 8-core 32GB machine. so interpret my experience through that lens.

Cool, I'll try again today, and try to update this thread.

What packages are folks using these days?

Is it still unbearably slow?

Honest question: can someone explain why everyone loves emoji these days, especially with regards to 'modern' programming communities such as those around JS and Rust? Is it just a celebration of the fact that we have Unicode support everywhere now?

I think the goal is adding a sense of lightheartedness and by humanizing code in general, which has historically had the perception of being dry.

I don't mind it being used in some (mostly) 'closed off' service, but given how commit messages from git will show up on several locations it seems a bad idea to allow users to use `:art:` in a commit message IMHO.

Also if your coding guidelines can use emojis in commit message to mean a certain thing if you all have a common lookup and it becomes natural to see what a change affects. e.g. :bug: for fixing bugs

You can do that with plain ASCII, e.g. Github recognizes the phrase "Closes #123." in commit messages and autocloses that issue when the commit is merged into master. I've seen similar commit hooks in SVN over 10 yrs ago.

I don't think it has an explicit "goal", as in someone wondering "How can my code appear more humanizing?"

It's just that people somehow enjoy this new new dimension of expression in text-only media. It has long been pretty obvious that text lacks the subtlety of face-to-face or voice interactions, and that many problems stem from people misjudging the intended tone of writing. Emojis, while imperfect, may help ;)

Emojis are the new punctuation marks. Displaying emotions in written text started at some point with the exclamation mark, which over time evolved and shifted in meaning. At some point !!! become a different meaning then a single !, and !? was added too. But then someone developed the smilie and the 90's was all about :-) and ;-> and sometimes even =^o^=. But it was kinda hard to write on mobile devices and took too much space in SMS. So the emojis were invented, standards were created and at some point universal support was established and the explosion of usage begun. Now people can communicate emotional without the need to write lengthly words.

According to https://blog.sourcerer.io/ascii-art-dead-or-alive-cc237391e5... the first ASCII emoticons were written by scott Fahlman in 1982.

> can someone explain why everyone loves emoji these days

What do you have against emojis? I'm hoping I can set my hostname to all emoji characters (UTF-8) so that other workstations on the network will show my hostname as those emoji characters.

They convey emotions and add a touch of lightheartedness and fun. It's all about a healthy balance. You can still have constructive discussions about complex topics, with emojis, without giving up the Professional Adult™ card.

Would that the unicode support was indeed ubiquitous. Then you wouldn't need to parse the message for things like ":penguin:", you could just include the appropriate character/icon.

Is there a downside to including the actual unicode emoji versus the text version that needs to be rendered? I tend to go for the former.

I find the whole trend very childish and unprofessional. Why? Because emojis don't convey much meaning and borders on child-talk, worst yet, they're very vague and so makes for very poor and unprofessional form of communication.

I am baffled by your assertion that they convey little meaning. Do facial expressions also convey little meaning?

To me the combination of both gives a hell of a lot more to base interpretation of tone on.

The issue I have with emojis is that they are rendered different on different fonts/devices, and because of this they can convey a different meaning.

And text is read wildly differently depending on the readers's culture, mood, font, and how well they know the language.

Communication is messy as hell, and the fact that emoji's render differently doesn't add that much confusion in most cases (of course there are the odd watergun vs revolver emoji problems, but the worst offenders are slowly being brought into line)

If I send a text message from Android to iPhone, the message is the same. Obviously there's cultural differences etc. but I can usually work with those if I know the person I'm sending a message to.

However, emojis can change when sending them from my Android phone to an iPhone, changing the meaning of the message inadvertently.

1. The size of emoji makes them difficult to grok, probably more so when you have to context switch between language comprehension and determining the emotion of the face. Also factor in how they look different on different platforms.

2. What about emoji's that aren't faces, or that have taken on a different meaning (see, eggplant or that infernal clapping emoji that's taken over twitter)

I never use emojis (I'm not even sure how people manage to input them on a keyboard, I assume they're using mobile devices?) but I try to avoid the kneejerk reaction of hating on them, they're mostly harmless. It's very tempting to go on a "back in my days we couldn't even put accents in commit messages" rant but in the end it doesn't really matter.

If it makes writing commit messages more fun and it means that people will make more of an effort to come up with descriptive messages then I say amazing. I can't count the number of open source projects where people write absolutely useless commit messages, even coming from projects I respect. I'll take emojis over "several changes, new stuff" or "some other small fixes" (to quote actual commits from an open source project I've been hacking on lately).

Of course both things are largely unrelated but I just wanted to point out that there's not a very strong "commit etiquette" in the hacker community as of today, it's not like much of value will be lost by letting kids use emojis in them, and maybe a little could be gained.

> they're mostly harmless.

I don't believe that, the confusion around the meaning of emojis are well established[0][1][2][3].

I strongly suspect that the confusion and vagueness is even more predominant in professional communications than personal. Please consider that everyday the likelihood of someone reading your code who is from a different culture or context is even higher, somethings might seem obvious to us, but that is not necessarily objectively so.

If you think I am making an argument for using plain and simple language and not just avoid emoji, you're right, that is the point.

From a pure economic point of view, considering the arguably nonexistence value emojis provide, any risk or cost is too much.

0. https://www.businessinsider.com/science-reveals-the-most-con...

1. http://fortune.com/2016/04/14/emoji-miscommunication-study-u...

2. http://www.dailymail.co.uk/sciencetech/article-3549376/Frust...

3. https://www.mrporter.com/journal/modern-problems/the-most-co...

Your first 3 links are all referencing the same University of Minnesota study. Your last link seems to be based on the writer’s observations (I did not find it linking or mentioning any study). I’m not even disagreeing with the fact that some emojis can be misunderstood (especially cross-culturally and when they are displayed very differently on devices) but you can’t just link 3 news stories covering the same study as if you’ve found a mountain of evidence to support your claims.

Assuming we're talking about commit messages and such, you're probably right.

But in day-to-day chats they're useful. Text is extremely bad at conveying emotion and nuance. Stuff like humor, sarcasm, irony is really hard to transmit, especially with more people. A well placed emoji/smiley can help.

I agree with this. I'm certainly not averse to dropping a :-) or emoji equivalent when appropriate. But emoji party hats every time a PR is merged, or READMEs covered with emoji, or worse of all, CLIs that use emoji in them are annoying to me and I don't understand the appeal.

> talking about commit messages

I heard that for some folks it makes it easier to find the right commits, unfortunately it's the opposite of being inclusive because other collaborators can become easily distracted by them.

I can't really see how emojis are "vague", or ambiguous. And even if: ambiguity is a great feature in any form of communication, by allowing us, for example, to express criticism early and subtle, defusing social problems before they blow up.

I also think you're placing to much value on some vague notion of "professionalism" which seems to exclude all emotion and any fun.

"Professionalism" in this sense stymies business success by, for example, prohibiting the effective means of communication people choose for themselves with some nebulous argument to appearances.

See my response to sibling comment. Emojis are a very poor language and very culture dependent far more than words in a natural language like English or whatever.

I agree that they are unprofessional. As far as I can determine, some people feel that they make a project or community seem more inclusive or welcoming - goals which I definitely consider worthwhile. But I don't personally feel that they are helpful in this persuit. Who are you trying to be inclusive of, seven year olds?

Outside of your friend group, most of us have been using smileys and emoticons in day-to-day chat for years - the presence of rich emoticons used to set messenger platforms aside from each other - and emojis are simply the latest generation of that. They’re primarily useful for providing some emotional context to some text - and whether displaying emotion is professional or not is really down to personal preference.

Maybe I'm just a robot, but by and large I don't believe that log or commit messages require emotional context. (I do use emoji for some messaging, Slack specifically.)

You sound like a very Serious and Professional Adult, feel free to ignore our Fisher-Price word-pictures.

Reply on news.ycombinator.com