Given that GitHub is a large Ruby on Rails app, I’m surprised we haven’t seen Microsoft doing more to improve the performance of Ruby language given they are one of a small handful of companies that have deep language/compiler talent.
(Don’t take this as me knocking Microsoft. The speed of development on GitHub, VS Code and even Microsoft 365 has been phenomenal.)
Re: Microsoft/Office 365 - I was referring to their development to shift to cloud first strategy. They still haven’t made online collaboration as seamless as Google yet - but given them not wanting to break backward (onprem/file) capability, they are doing a good job.
I do agree Teams is trying to be a jack of all trades master of none at the moment.
It used to be light years ahead of GitHub, but with actions, code spaces, private repos and Jira like stuff being released in GH that's not the case anymore.
IMO you can't go wrong with either GitLab or GitHub nowadays, both are great at what they do.
I think they are still operate pretty much like a separate entity. But yes, I really wish there are at least 2 full time compiler developer at Github working on RubyVM.
Yes but the more the better :). We need to leverage all the resources we could get our hands on. Instead of having Shopify / Stripe funding all the work on JIT and other Core Ruby development.
A dynamically typed language like ruby doesn't sound as the language of choice for processing sensitive transactions without data loss. Ofc possible, but it sounds scary.
Interesting. I wonder how this will interact with StackOverflow.
On one hand, it will tend to give large projects with established communities a centralized location to handle questions which otherwise would be in a StackOverflow tag. Perhaps core developers would be interested in the community management features that Discussions offer, which would be harder to do in a world where questions get delegated to SO.
And potentially linking to the actual version/release that fixes a question would allow maintainers to whittle out the stale/deprecated answers that can bring down the average quality on SO.
On the other hand, it seems like small/medium size projects might suffer from a brain drain effect; if most React experts stop/reduce checking SO, and start/increase checking github.com/facebook/react/discussions, then there's probably less chance at the margin of a React expert seeing something tagged in SO as React,SmallReactLib.
My gut reaction is that it looks a lot like centralization. And centralization almost always wins, and almost always for the worst reasons.
I can easily see peoples questions being buried/deleted/marked as "nofix" or other passive aggressive stuff like that.
I can easily see people who aren't on the project being less likely to have input than they would on SO.
I can also easily see a lot less discovery happening.
But all of these things that make a Q&A into yet another virtual fiefdom are exactly what will make it win out: it will be the developers own little fiefdom; they'll be there more.
I think this is helpful because it keeps the "issues" tab cleaner. It's a place to discuss initial ideas without finding the maintainers on discord or something, to get feedback on whether the idea is worth implementing a PR for or not, etc.Similarly, it can be used for announcements about the project, polls to the community, etc.
All these features infested with emojis and negative space makes SourceHut such a refreshing take at UX/UI that is utilitarian, straightforward, ultra-functional and zero-tolerance for trendy-designer-bullshit. Exactly what engineering tools should be like. Unfortunately, I am in the minority here and most people find the UX/UI of Sourcehut ancient, unadorned and bland - IMO that’s a feature, not a bug. Check it out: https://sourcehut.org/
Kind of a salty take on it. Personally, I appreciate the emojis, they allow a more dense information transfer when used correctly, like when reacting to a chat message.
Similarly, with Github Discussions, each emoji has a distinct meaning and can convey the topic with many less pixels. Ex, I can use a as a replacement for "Feature request", as a replacement for "Bug/Issue", and for "Vulnerability".
Now if you start shoving them as the only way to communicate something, there's your problem.
Strongly disagree and I've noticed this is a common trait amongst developers. I think it stems from the fact they are more comfortable on the CLI and are used to poor interfaces that they more easily justify a sub-par UX. Just look at how many HN "readers" are out there because this site subscribes to the same philosophy
Mild disagree. Emoji aren't that bad, and certainly have their uses; however, most of the time they look dramatically different than the surrounding text, and can be quite distracting. If they're trying to communicate something important, that works fine, but often the important stuff is buried in the text, and the emoji simply hurt the readability.
Also, there's an issue sometimes whereby people who have nothing worthwhile to say thing that adding a few emoji will now make their message worthwhile...
Imagine that this comment were my only contribution to this message thread. Imagine that ten other people commented the same because the community was very engaged. Now, imagine that pattern of commenting across every discussion.
I might argue there is no UI/UX being presented on sourcehut, just the presentation of data in different colors and some buttons. Maybe that's a feature, less is more, I can certainly appreciate it, but the GitHub UI is good and it's why nearly everyone is copying it, like the visibility feature on sr.st.
I noticed the beta version of this feature last week. I like that there's finally a place to ask questions about a project. To do it before you either had to abuse the issue tracker for it, join a Discord server linked in the README, or hope that someone who knows enough about the project is active on StackOverflow to answer you there. All 3 of those not too great options discouraged me from ever asking for help.
Is there a way to learn that an issue has been converted to a discussion using the GitHub REST API?
I'm having problems with GitHub actions attempting to comment on converted issues that no longer accept comments, and the API does not seem to offer a way to identify that an issue has been converted to a discussion.
Back when this first came out I pondered whether I could use it as a replacement for the comment section on technical docs. E.g. rather than putting a Disqus on the bottom of your doc, create a Discussion, and put a link to the Discussion at the bottom of your doc instructing readers to leave comments there.
What are some novel use cases for the discussions GraphQL API? Synchronizing between chat servers and discussions is an obvious usage.
Let's go further.
(Don’t take this as me knocking Microsoft. The speed of development on GitHub, VS Code and even Microsoft 365 has been phenomenal.)