I’ve only played with it briefly, but I like that Unison is innovating “around” the programming language, i.e. in tooling, deployment, sharing, and so on. It’s a more holistic view of software than I’m used to.
Does anyone have significant experience with Unison that can comment on how it’s working out for them?
https://archive.org/details/plan9designintro begins by describing all of this as the operating system, tools which help you compute better/easier. While it focuses more on OS, it is a very interesting lens which inspires further innovations and encourages thinking about overall workflows.
edit: I just remembered internet archive’s down. The book is Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs. Here is a different link: http://doc.cat-v.org/plan_9/9.intro.pdf
by describing all of this as the operating system, tools which help you compute better/easier
i.e.
innovating “around” the programming language, i.e. in tooling, deployment, sharing, and so on
the introduction to the book presents a rather fresh perspective on computing. Plan9 has nothing to do with this, besides being the medium the author uses after the introduction to explore these ideas, which Unison is exploring in a different way.
I think Unison is, along with Rust, one of the two most innovative languages we have today. It’s an incredible feat of engineering and I really hope it takes over cloud computing in the future. Just look at this ‘PR’ that adds a Discord bot: https://share.unison-lang.org/@haruaokii/discord/contributions/1/changes -they created their own code review app that looks and feels remarkably like a GitHub PR. Wishing them much success.
No more writing translation code between your values and the storage layer. Directly store values and unpersist them later without fear of dependency conflicts or version mismatches.
Many of us could probably have an hours-long discussion about what this entails: tradeoffs between fluently working with data at the language level versus the constraints of networked durable storage under various kinds of workloads. Who might like to share your take on where it sits in the landscape of tradeoffs?
it feels a lol like a smalltalk system or maybe a lisp machine, which is very cool. i wonder if it could benefit from an IDE specifically built for that
not a fan of the haskell-ish syntax, though. i’ve never been good at following code like that
Realizing Slack isn’t a great platform to build a open source community around they finally migrated… to Discord… & Unison Share still requires a MS GitHub account to join/share. It’s a real shame to see it all locked behind these US-based, proprietary services.
That seems a bit harsh. I can’t critique their approach, but they claim to use a public benefit corporation structure as a means to their fund open source software: https://www.unison-lang.org/unison-computing/
It’s not a non-profit and this could be a gimmick, but I listened to an interview with one of the founders and they seemed genuine.
I’m willing to give them the benefit of the doubt for now.
IRC (v3) and/or (gatewayed) XMPP MUCs. These are lightweight, performant, battle-tested protocols that offer the all features needed for chat with lightweight clients too (& doesn’t take literal minutes to ‘sync’).
Otherwise forums, mailing list, & feeds are still better used for announcements & long-running, searchable posts. Letting important conversations get stuck behind the black hole of proprietary chat is a huge problem right now where it becomes impossible to find common answers.
You need to come to terms with the fact that most people dislike IRC and younger devs generally have very little exposure to it, having come of age with tools that are much more sleek and user friendly.
There’s nothing sleek about a some a bloated web UI as the only means of communication.
IRCv3 has most of the minimum required features—including chathistory so bouncer not required. If you don’t like IRC, XMPP was an option that offers more features as well as decentralized self-hosting on lightweight servers. Even the XMPP web clients like Movim run using less resources. Familiarity is not the same as right tool for the job, optimal, or efficient.
Folks like you should keep track that these stable tools are still evolving instead of being locked into the memory of how it was 20 years ago.
And yet, some parts of the Discord UI are peerless. Their text input control does instant unobtrusive live preview of the markup you’ve entered, including proper syntax highlighting and even ANSI SGR escape sequences. Slack’s muddled markup syntax looks like a joke in comparison, and pastebins are blown right out of the water.
This could be done on any client tho if anyone bothers. Gajim & Conversations turns some inline symbols into bold/italic inside the blocks while also keep the symbols visible for clarity/preventing false positives both on entry & rendering. Syntax highlight on inline code is a crapshoot guess—Lemmy generally tries to do this & always gets things wrong. I wouldn’t say this UX is a requirement for a platform—especially not something to lock one’s community exclusively to.
Right, and that’s the problem. Despite being bolted onto a web browser and taking its sweet time to load, Discord is slick once it’s up and running. And it’s also does the Reddit thing of having heaps of diverse communities bundled into the one service. Small wonder it’s grown as much as it has, and become the default option.
For the purpose of community chat for a software project these aren’t required features & not worth hitching your entire project to their whims (see folks complaining about the mobile app redesign a few months ago). You can link if you can link/bridge/gateway if you think this is what is best, but this isn’t the same as exclusively on the platform. I am sure it will do the Reddit thing of “enshitification” before we know it just like all of these free for-profit corporate offerings have. Why build exclusively on these pillars of sand when history tells us this won’t last (see the Unison project moving from Slack, the previous incantation of corpo chat)?
And yet, here we are. We can talk about what people “should” do with their projects until we’re blue in the face, but the fact is that these proprietary chat clients have a slicker interface and that gets users in the door. That the door will probably close behind them doesn’t factor into the decision calculus.
It doesn’t matter whether IRCv3 or XMPP or Matrix or whatever has this or that feature. A performant and slick client that’s fun to use (Discord) or gets out of the way (early Slack, before they bolted the kitchen sink onto it) gets users in the door.
I would prefer open systems to win, but until open systems get better than closed ones, I don’t see it happening. Remember that early GNU tools were superior to the ones bundled with proprietary Unices, because everyone could collaborate on improving the GNU ones but each UNIX vendor had to write their own. That’s the sort of effect we need in the chat space.
I mostly agree with this sentiment at large, but I think the way to get these open options adopted starts by dogfooding it now as flawed but serviceable to inspire folks obviously interested in FLOSS & contribute in some manner to make the experience better. This is how I think you avoid the chicken-egg scenario with users adoption by sticking to a similar software philosophy as your own project where you want adoption & contributions. These projects don’t have investors or VC money, but with enough users dedicating little fixes here & there, it can copy features & eventually outdo.
I think this mostly boils down to me not thinking there is much value in meeting folks, especially younger ones, where they are at in the short term when the long-term goal matches where I would ideally like to be on privacy, sustainability, freedom. I don’t see Discord as exceptional or more than another fad.
Projects are adopting services like Slack and GitHub because they’re in the business of developing a programming language (or whatever else), not a chat service and a forge. If the Free Software™ alternatives get better enough to be considered, they probably will be because of the sympathies towards a thing. But they’re not going to do it themselves; they need to get their work done, and yak shaving isn’t how they do it. If the energy spent telling people to use IRCv3 was instead spent on IRCv3…
Why do you think Slack and Discord are taking over as many open source projects’ communication channels? What do they provide that IRC and XMPP lack? For example, perhaps being able to send multiline messages (vs IRC single-line only)?
Network effects, of course, accelerated by marketing. The usual reason why “objectively worse” technologies win and in general we just can’t have nice things.
IRCv3 has multiline messages & XMPP MUCs have had it from the start. You gotta keep up with the times if you are gonna throw out tired arguments—like you didn’t even bother to look it up before making the claim despite previously calling out this behavior.
They are “taking over” since gamer culture & kids grew up on that platform & continuing to use it when they grew up to learn software (mods & game dev were the first to adopt this Discord-first mentality)—making this decision without thinking about the ethical implications of forcing a US-based, proprietary chat option that’s vacuuming up user data to sell and/or give to the feds, banned in several jurisdictions by the state or via US sanctions, where the ToS is by these corporations instead of the community getting to choose how to operate & moderate itself. Cherry on top is how bloated these clients are while being hostile towards alternate clients (even FOSS, non-profit ones) that could make access broader for low spec devices or high latency, spotty networks with some expectation that everyone is made out of Western money. I don’t think naïvety or sticking to the ‘familiar’ are good arguments. If open source is a good enough philosophy for your project, it is good enough for your tooling around the project—which includes communications. Use gateways or mention unofficial proprietary chat spaces if you want, but do not limit exclusively to. Same applies to the forge too.
According to https://ircv3.net/software/clients, there is exactly 1 (ONE!) desktop client that supports multiline, but that one doesn’t support chathistory, so there’s no clients that support both. There’s absolutely no clients that also support features like replying and reactions that are incredibly popular in discord, and features like forums, voice and video are not even on the roadmap. This is also true of web and mobile clients. Even ignoring clients, the “IRC way” of doing many things is clunkier and less intuitive than what Discord does.
I’m sorry, you’re arguing as if IRCv3 is the present, but it’s not. I’m saying this as someone who hung out in IRCs in the oughties and 2010’s: Discord is a much much much better user experience for so many reasons that I simply don’t have it in me to bother with IRC. If your community is IRC only, I’m not going to participate unless I absolutely have no choice.
The spec is there & the clients are open source so any of this could be implemented with that one Go server implementing basically the whole spec from the server perspective—but interest needs to be there for folks to put time into it. Since IRC is so simple as a protocol there are tons of clients that implement the basics on a lark for learning purposes & were likely never going to be fully fleshed out. As a fallback multiline is normally spit out as multiple messages which isn’t a big deal (as seen in gateways/bridges) unless writing a novel. Sometimes this could be an indicator that the discussion could be better as a forum post or blog entry. I wouldn’t say IRC is my first choice either, but compatibility with it isn’t the hardest thing which is why gateways/bridges are fairly common. That machine mentioned from the ’00s mentioned would have no trouble joining these spaces on dial-up since the path of the protocol is well-worn & worked fine for machines built in the ’90s. These ‘modern web cilents’ web clients will chew up a RAM in the order of GiBs at the turn of a head.
If you think these other features mentioned are key to your user experience (& I would agree they are a definite enhancement—while more likely to be implemented & not just a XEP, with compliance suites being a part of the culture), then you don’t need to move past an extensible protocol from the ’00s in XMPP that is designed to run well on your other machine from the ’10s. For one you can self-host & join rooms from a server you control (see ‘pros for decentralization’). You have replies, you have reactions, multiline, pasting code blocks/images, moderation, beyond-ASCII user & room names, where some clients can even handle voice/video calls (where both proprietary Zoom & free software Jitsi are built with an XMPP backbone). And it all works thru graceful degradation when a feature isn’t supported in client X it still is sensible in client Y (for instance a react being a emoji reply). If I compare this to the yet-to-be-mentioned Matrix where if an Element poll is posted, other clients don’t even receive a message & reply/threading is broken unless using Element. & you can still bridge back to IRC for those that need/want it.
What does Discord offer a software community that isn’t covered? Voice-on rooms? Are these a requirement or even desired for open source? Is it worth the cost of privacy, centralization, censorship in the form of sactions/misblocking accounts from those on high, & the spirit of freedom (the F in FOSS)? I couldn’t even run a lightweight TUI client to save battery/data on the bus even if I wanted since they DCMA’d all projects that tried.
I’m not going to respond to this point by point because it’d take too long and end up getting down into the weeds, but very briefly, even with XMPP these features are all experimental XEPs with lackluster client compatibility (pidgin, IIRC the most widely used client, doesn’t support any of the features I mentioned), and I’d say features like multiline are absolutely essential to having a programming community; how else are you pasting blocks of code into the chat without using a pastebin and redirecting to another site? I can even go on about how useful voice/video/forums are for the average software community on discord; I’ve been in several, have modded a fairly large community and still largely hang out in discord servers.
But that’s neither here nor there; I think it’s undeniable that the UI and UX of both IRC and XMPP is significantly worse than Discord. But let me run you through this: You’re asking the makers of a programming community to do additional legwork unrelated to what they’re working on (like hosting bridges, or in the worst case running their own XMPP server) and switch to a platform that has worse user experience and is missing many features that they might rely on, which most of their users don’t know or have an account for. Even if those users could be persuaded to try out this alternative protocol, they would now have to navigate the minefield of finding a compatible client on their platform that also doesn’t suck and learning new usage patterns such as pasting code into a pastebin first, and if they fail at any of these steps you’ll have to guide them through it. Now remember, they’re doing this to build the community for their small language, and each barrier they add could cost them tons of people. All for… vague and unconvincing moral reasons? Most people are fine with proprietary software, most people are fine with electron apps, most people are fine with accepting a ToS. It’s not like using Discord is supporting a genocide. Even if there are practical issues that come from that, like users being unable to join from sanctioned countries, those are tradeoffs that if they weigh against the downsides of using IRC/XMPP Discord will usually win handily. Shaming them isn’t going to change that.
Also,
I couldn’t even run a lightweight TUI client to save battery/data on the bus even if I wanted since they DCMA’d all projects that tried.
That is not true. Discord hasn’t DMCA’d any alternative clients. There’s even a currently active project for a TUI discord client: https://github.com/ayn2op/discordo
There is literally a neo-Luddite movement with the breakup of Google, moving to dumb phones, leaving Twitter over Musk, leaving Microsoft Windows over Recall, skeptical of the Apple image scanning. Folks are tired of these terms of service, AI scraping, selling privacy. I don’t believe this premise that users, technical & nontechnical, are actually fine with all these things—they are wishing for an alternative.
The basic features you need are there. The enhancements folks mention are hardly dealbreakers (pastebin is only a IRC issue). A decentralized server takes few resources (provided it isn’t eventual consistency like Matrix) & the Share section is probably using way more resources so it isn’t like there isn’t a server folks could join from (technical folks like programmers seem okay on the Fediverse). Client inconsistencies are fine as the best ideas get adopted at large + put in compliance suites. Expecting a single corporation to having anything but profit as a goal over users is naïve—all of these unified, centralized platforms don’t last more than a decade of popularity & Discord will have the same fate of slowly getting worse as Slack or Skype or Google Chat or AIM’s time it the sun.
I think it’s undeniable that the UI and UX of both IRC and XMPP is significantly worse than Discord.
I’m willing to believe that it’s worse for a typical Discord user, but I would deny that IRC worse for me. I prefer the UI and UX of IRC (without needing IRCv3 features) over what I remember of using Discord. (My particular reasons are unnecessary to contest “undeniable”, but two major ones are that I can search old messages much more usefully (with ripgrep) and I can jump arbitrarily far back in the message history by opening a timestamped log file. Yes, this does imply staying connected most of the time.)
I don’t tell projects not to use Discord, though. I won’t bother talking with them on Discord, but I don’t think they need me talking with them.
Have you even used the services you’re advocating for? The server and client support for IRCv3 and XEP features are incredibly spotty. Quit being a partisan slagging on people’s choices and come back when you have a product that works instead of a protocol that isn’t implemented.
So your argument is that it’s purely because of gamer culture and familiarity of a new generation of open source contributors, and not because of any other advantages of the new chat services? Eg, do IRC or XMPP allow me to block abusive users?
Gamers was (& still is) their target audience—many software developers started after wanting to make games or mod games. Yes, the both support kicking & banning.
I don’t mean having to rely on a channel mod to kick or ban someone–I mean can I directly, peer-to-peer, block an abusive user from being able to interact with me or view my messages?
Each Unison definition is identified by a hash of its syntax tree.
Put another way, Unison code is content-addressed.
This idea is powerful. It seems natural to call it content-addressable functions – a term that makes sense to me but not widely used, to my knowledge. However, I wouldn’t describe this as the main “selling point” of Unison, at least not for an organization or team that is looking for an elevator-pitch summary of the value-add.
I would characterize content-addressable functions as one enabler of the downstream value-add. I would probably even grant that this feature is necessary (but not sufficient) to accomplish Unison’s overall goals. It pairs really well with this value pitch:
A new approach to
Storing code
Other tools try to recover structure from text; Unison stores code in a database. This eliminates builds, provides for instant nonbreaking renames, type-based search, and lots more.
I skimmed through that big-idea page and was disappointed to see not event a mention of function normalization or equivalence. If it’s really just a hash of a syntax tree, that means that there are multiple versions of a function that “do the same thing” functionally but might well have very different performance characteristics. How to find them?
Program equivalence is a difficult problem in practice, and impossible in general: that’s one of Turing’s early results. I’ve seen some PL research on canonical forms that might be applicable. I guess they just decided to ignore the issue? Or maybe it’s documented somewhere besides that page.
To point out the obvious, content hashes aren’t for finding [related] things, they’re for naming things.
What you’re saying is like saying there are multiple functionally-equivalent Git commits with different hashes. It’s true, but that’s not the point of Git.
ability KVStore a b where
docs.fundamentals.abilities.writingAbilities.KVStore.get :
a ->{KVStore a b} Optional b
docs.fundamentals.abilities.writingAbilities.KVStore.put :
a -> b ->{KVStore a b} ()
Ability declarations start with the
unique
or
structural
keyword, followed by the name of the ability and any lowercase type parameters that the ability might require. The type parameters here, lowercase
a
and
b
, mean that this store can contain keys and values of a specific type.
am i going insane, or does the syntax described in prose simply not match the given example? is this AI generated??
i mean, yeah, if you go out of your way to write Haskell in the ugliest possible way, it looks pretty bad, but noone writes haskell that looks like that!
I’ve only played with it briefly, but I like that Unison is innovating “around” the programming language, i.e. in tooling, deployment, sharing, and so on. It’s a more holistic view of software than I’m used to.
Does anyone have significant experience with Unison that can comment on how it’s working out for them?
https://archive.org/details/plan9designintro begins by describing all of this as the operating system, tools which help you compute better/easier. While it focuses more on OS, it is a very interesting lens which inspires further innovations and encourages thinking about overall workflows.
edit: I just remembered internet archive’s down. The book is Introduction to Operating Systems Abstractions Using Plan 9 from Bell Labs. Here is a different link: http://doc.cat-v.org/plan_9/9.intro.pdf
What does Plan 9 have to do with Unison?
Nothing. As I wrote
i.e.
the introduction to the book presents a rather fresh perspective on computing. Plan9 has nothing to do with this, besides being the medium the author uses after the introduction to explore these ideas, which Unison is exploring in a different way.
Interesting parallel. Would not have occurred to me!
I think Unison is, along with Rust, one of the two most innovative languages we have today. It’s an incredible feat of engineering and I really hope it takes over cloud computing in the future. Just look at this ‘PR’ that adds a Discord bot: https://share.unison-lang.org/@haruaokii/discord/contributions/1/changes -they created their own code review app that looks and feels remarkably like a GitHub PR. Wishing them much success.
Was this never submitted before? Wild, I’ve seen a dozen conversations on here about it.
I see someone apparently made a Discord API for it a whopping two days ago. Might play around with that.
People have submitted articles on Unison, but not the root site itself. https://lobste.rs/domains/unison-lang.org
Many of us could probably have an hours-long discussion about what this entails: tradeoffs between fluently working with data at the language level versus the constraints of networked durable storage under various kinds of workloads. Who might like to share your take on where it sits in the landscape of tradeoffs?
it feels a lol like a smalltalk system or maybe a lisp machine, which is very cool. i wonder if it could benefit from an IDE specifically built for that
not a fan of the haskell-ish syntax, though. i’ve never been good at following code like that
Realizing Slack isn’t a great platform to build a open source community around they finally migrated… to Discord… & Unison Share still requires a MS GitHub account to join/share. It’s a real shame to see it all locked behind these US-based, proprietary services.
It is at least philosophically consistent with a language and environment apparently designed to sell cloud services.
That seems a bit harsh. I can’t critique their approach, but they claim to use a public benefit corporation structure as a means to their fund open source software: https://www.unison-lang.org/unison-computing/
It’s not a non-profit and this could be a gimmick, but I listened to an interview with one of the founders and they seemed genuine.
I’m willing to give them the benefit of the doubt for now.
What service would you use for the community chat?
IRC (v3) and/or (gatewayed) XMPP MUCs. These are lightweight, performant, battle-tested protocols that offer the all features needed for chat with lightweight clients too (& doesn’t take literal minutes to ‘sync’).
Otherwise forums, mailing list, & feeds are still better used for announcements & long-running, searchable posts. Letting important conversations get stuck behind the black hole of proprietary chat is a huge problem right now where it becomes impossible to find common answers.
You need to come to terms with the fact that most people dislike IRC and younger devs generally have very little exposure to it, having come of age with tools that are much more sleek and user friendly.
There’s nothing sleek about a some a bloated web UI as the only means of communication. IRCv3 has most of the minimum required features—including
chathistoryso bouncer not required. If you don’t like IRC, XMPP was an option that offers more features as well as decentralized self-hosting on lightweight servers. Even the XMPP web clients like Movim run using less resources. Familiarity is not the same as right tool for the job, optimal, or efficient.Folks like you should keep track that these stable tools are still evolving instead of being locked into the memory of how it was 20 years ago.
And yet, some parts of the Discord UI are peerless. Their text input control does instant unobtrusive live preview of the markup you’ve entered, including proper syntax highlighting and even ANSI SGR escape sequences. Slack’s muddled markup syntax looks like a joke in comparison, and pastebins are blown right out of the water.
I say this as a fan of IRC.
This could be done on any client tho if anyone bothers. Gajim & Conversations turns some inline symbols into bold/italic inside the blocks while also keep the symbols visible for clarity/preventing false positives both on entry & rendering. Syntax highlight on inline code is a crapshoot guess—Lemmy generally tries to do this & always gets things wrong. I wouldn’t say this UX is a requirement for a platform—especially not something to lock one’s community exclusively to.
Right, and that’s the problem. Despite being bolted onto a web browser and taking its sweet time to load, Discord is slick once it’s up and running. And it’s also does the Reddit thing of having heaps of diverse communities bundled into the one service. Small wonder it’s grown as much as it has, and become the default option.
For the purpose of community chat for a software project these aren’t required features & not worth hitching your entire project to their whims (see folks complaining about the mobile app redesign a few months ago). You can link if you can link/bridge/gateway if you think this is what is best, but this isn’t the same as exclusively on the platform. I am sure it will do the Reddit thing of “enshitification” before we know it just like all of these free for-profit corporate offerings have. Why build exclusively on these pillars of sand when history tells us this won’t last (see the Unison project moving from Slack, the previous incantation of corpo chat)?
And yet, here we are. We can talk about what people “should” do with their projects until we’re blue in the face, but the fact is that these proprietary chat clients have a slicker interface and that gets users in the door. That the door will probably close behind them doesn’t factor into the decision calculus.
It doesn’t matter whether IRCv3 or XMPP or Matrix or whatever has this or that feature. A performant and slick client that’s fun to use (Discord) or gets out of the way (early Slack, before they bolted the kitchen sink onto it) gets users in the door.
I would prefer open systems to win, but until open systems get better than closed ones, I don’t see it happening. Remember that early GNU tools were superior to the ones bundled with proprietary Unices, because everyone could collaborate on improving the GNU ones but each UNIX vendor had to write their own. That’s the sort of effect we need in the chat space.
I mostly agree with this sentiment at large, but I think the way to get these open options adopted starts by dogfooding it now as flawed but serviceable to inspire folks obviously interested in FLOSS & contribute in some manner to make the experience better. This is how I think you avoid the chicken-egg scenario with users adoption by sticking to a similar software philosophy as your own project where you want adoption & contributions. These projects don’t have investors or VC money, but with enough users dedicating little fixes here & there, it can copy features & eventually outdo.
I think this mostly boils down to me not thinking there is much value in meeting folks, especially younger ones, where they are at in the short term when the long-term goal matches where I would ideally like to be on privacy, sustainability, freedom. I don’t see Discord as exceptional or more than another fad.
Projects are adopting services like Slack and GitHub because they’re in the business of developing a programming language (or whatever else), not a chat service and a forge. If the Free Software™ alternatives get better enough to be considered, they probably will be because of the sympathies towards a thing. But they’re not going to do it themselves; they need to get their work done, and yak shaving isn’t how they do it. If the energy spent telling people to use IRCv3 was instead spent on IRCv3…
Why do you think Slack and Discord are taking over as many open source projects’ communication channels? What do they provide that IRC and XMPP lack? For example, perhaps being able to send multiline messages (vs IRC single-line only)?
Network effects, of course, accelerated by marketing. The usual reason why “objectively worse” technologies win and in general we just can’t have nice things.
IRCv3 has multiline messages & XMPP MUCs have had it from the start. You gotta keep up with the times if you are gonna throw out tired arguments—like you didn’t even bother to look it up before making the claim despite previously calling out this behavior.
They are “taking over” since gamer culture & kids grew up on that platform & continuing to use it when they grew up to learn software (mods & game dev were the first to adopt this Discord-first mentality)—making this decision without thinking about the ethical implications of forcing a US-based, proprietary chat option that’s vacuuming up user data to sell and/or give to the feds, banned in several jurisdictions by the state or via US sanctions, where the ToS is by these corporations instead of the community getting to choose how to operate & moderate itself. Cherry on top is how bloated these clients are while being hostile towards alternate clients (even FOSS, non-profit ones) that could make access broader for low spec devices or high latency, spotty networks with some expectation that everyone is made out of Western money. I don’t think naïvety or sticking to the ‘familiar’ are good arguments. If open source is a good enough philosophy for your project, it is good enough for your tooling around the project—which includes communications. Use gateways or mention unofficial proprietary chat spaces if you want, but do not limit exclusively to. Same applies to the forge too.
According to https://ircv3.net/software/clients, there is exactly 1 (ONE!) desktop client that supports multiline, but that one doesn’t support chathistory, so there’s no clients that support both. There’s absolutely no clients that also support features like replying and reactions that are incredibly popular in discord, and features like forums, voice and video are not even on the roadmap. This is also true of web and mobile clients. Even ignoring clients, the “IRC way” of doing many things is clunkier and less intuitive than what Discord does.
I’m sorry, you’re arguing as if IRCv3 is the present, but it’s not. I’m saying this as someone who hung out in IRCs in the oughties and 2010’s: Discord is a much much much better user experience for so many reasons that I simply don’t have it in me to bother with IRC. If your community is IRC only, I’m not going to participate unless I absolutely have no choice.
The spec is there & the clients are open source so any of this could be implemented with that one Go server implementing basically the whole spec from the server perspective—but interest needs to be there for folks to put time into it. Since IRC is so simple as a protocol there are tons of clients that implement the basics on a lark for learning purposes & were likely never going to be fully fleshed out. As a fallback multiline is normally spit out as multiple messages which isn’t a big deal (as seen in gateways/bridges) unless writing a novel. Sometimes this could be an indicator that the discussion could be better as a forum post or blog entry. I wouldn’t say IRC is my first choice either, but compatibility with it isn’t the hardest thing which is why gateways/bridges are fairly common. That machine mentioned from the ’00s mentioned would have no trouble joining these spaces on dial-up since the path of the protocol is well-worn & worked fine for machines built in the ’90s. These ‘modern web cilents’ web clients will chew up a RAM in the order of GiBs at the turn of a head.
If you think these other features mentioned are key to your user experience (& I would agree they are a definite enhancement—while more likely to be implemented & not just a XEP, with compliance suites being a part of the culture), then you don’t need to move past an extensible protocol from the ’00s in XMPP that is designed to run well on your other machine from the ’10s. For one you can self-host & join rooms from a server you control (see ‘pros for decentralization’). You have replies, you have reactions, multiline, pasting code blocks/images, moderation, beyond-ASCII user & room names, where some clients can even handle voice/video calls (where both proprietary Zoom & free software Jitsi are built with an XMPP backbone). And it all works thru graceful degradation when a feature isn’t supported in client X it still is sensible in client Y (for instance a react being a emoji reply). If I compare this to the yet-to-be-mentioned Matrix where if an Element poll is posted, other clients don’t even receive a message & reply/threading is broken unless using Element. & you can still bridge back to IRC for those that need/want it.
What does Discord offer a software community that isn’t covered? Voice-on rooms? Are these a requirement or even desired for open source? Is it worth the cost of privacy, centralization, censorship in the form of sactions/misblocking accounts from those on high, & the spirit of freedom (the F in FOSS)? I couldn’t even run a lightweight TUI client to save battery/data on the bus even if I wanted since they DCMA’d all projects that tried.
I’m not going to respond to this point by point because it’d take too long and end up getting down into the weeds, but very briefly, even with XMPP these features are all experimental XEPs with lackluster client compatibility (pidgin, IIRC the most widely used client, doesn’t support any of the features I mentioned), and I’d say features like multiline are absolutely essential to having a programming community; how else are you pasting blocks of code into the chat without using a pastebin and redirecting to another site? I can even go on about how useful voice/video/forums are for the average software community on discord; I’ve been in several, have modded a fairly large community and still largely hang out in discord servers.
But that’s neither here nor there; I think it’s undeniable that the UI and UX of both IRC and XMPP is significantly worse than Discord. But let me run you through this: You’re asking the makers of a programming community to do additional legwork unrelated to what they’re working on (like hosting bridges, or in the worst case running their own XMPP server) and switch to a platform that has worse user experience and is missing many features that they might rely on, which most of their users don’t know or have an account for. Even if those users could be persuaded to try out this alternative protocol, they would now have to navigate the minefield of finding a compatible client on their platform that also doesn’t suck and learning new usage patterns such as pasting code into a pastebin first, and if they fail at any of these steps you’ll have to guide them through it. Now remember, they’re doing this to build the community for their small language, and each barrier they add could cost them tons of people. All for… vague and unconvincing moral reasons? Most people are fine with proprietary software, most people are fine with electron apps, most people are fine with accepting a ToS. It’s not like using Discord is supporting a genocide. Even if there are practical issues that come from that, like users being unable to join from sanctioned countries, those are tradeoffs that if they weigh against the downsides of using IRC/XMPP Discord will usually win handily. Shaming them isn’t going to change that.
Also,
That is not true. Discord hasn’t DMCA’d any alternative clients. There’s even a currently active project for a TUI discord client: https://github.com/ayn2op/discordo
There is literally a neo-Luddite movement with the breakup of Google, moving to dumb phones, leaving Twitter over Musk, leaving Microsoft Windows over Recall, skeptical of the Apple image scanning. Folks are tired of these terms of service, AI scraping, selling privacy. I don’t believe this premise that users, technical & nontechnical, are actually fine with all these things—they are wishing for an alternative.
The basic features you need are there. The enhancements folks mention are hardly dealbreakers (pastebin is only a IRC issue). A decentralized server takes few resources (provided it isn’t eventual consistency like Matrix) & the Share section is probably using way more resources so it isn’t like there isn’t a server folks could join from (technical folks like programmers seem okay on the Fediverse). Client inconsistencies are fine as the best ideas get adopted at large + put in compliance suites. Expecting a single corporation to having anything but profit as a goal over users is naïve—all of these unified, centralized platforms don’t last more than a decade of popularity & Discord will have the same fate of slowly getting worse as Slack or Skype or Google Chat or AIM’s time it the sun.
I’m willing to believe that it’s worse for a typical Discord user, but I would deny that IRC worse for me. I prefer the UI and UX of IRC (without needing IRCv3 features) over what I remember of using Discord. (My particular reasons are unnecessary to contest “undeniable”, but two major ones are that I can search old messages much more usefully (with ripgrep) and I can jump arbitrarily far back in the message history by opening a timestamped log file. Yes, this does imply staying connected most of the time.)
I don’t tell projects not to use Discord, though. I won’t bother talking with them on Discord, but I don’t think they need me talking with them.
https://xkcd.com/1782/ :)
Have you even used the services you’re advocating for? The server and client support for IRCv3 and XEP features are incredibly spotty. Quit being a partisan slagging on people’s choices and come back when you have a product that works instead of a protocol that isn’t implemented.
So your argument is that it’s purely because of gamer culture and familiarity of a new generation of open source contributors, and not because of any other advantages of the new chat services? Eg, do IRC or XMPP allow me to block abusive users?
Gamers was (& still is) their target audience—many software developers started after wanting to make games or mod games. Yes, the both support kicking & banning.
I don’t mean having to rely on a channel mod to kick or ban someone–I mean can I directly, peer-to-peer, block an abusive user from being able to interact with me or view my messages?
XEP-0191
https://xmpp.org/extensions/xep-0191.html
I had to dig a bit to find their main idea, which is “each function has a unique hash”.
It used to be their main selling point just months ago
Their docs call it “the big idea” behind Unison: https://www.unison-lang.org/docs/the-big-idea/
This idea is powerful. It seems natural to call it content-addressable functions – a term that makes sense to me but not widely used, to my knowledge. However, I wouldn’t describe this as the main “selling point” of Unison, at least not for an organization or team that is looking for an elevator-pitch summary of the value-add.
I would characterize content-addressable functions as one enabler of the downstream value-add. I would probably even grant that this feature is necessary (but not sufficient) to accomplish Unison’s overall goals. It pairs really well with this value pitch:
I skimmed through that big-idea page and was disappointed to see not event a mention of function normalization or equivalence. If it’s really just a hash of a syntax tree, that means that there are multiple versions of a function that “do the same thing” functionally but might well have very different performance characteristics. How to find them?
Program equivalence is a difficult problem in practice, and impossible in general: that’s one of Turing’s early results. I’ve seen some PL research on canonical forms that might be applicable. I guess they just decided to ignore the issue? Or maybe it’s documented somewhere besides that page.
To point out the obvious, content hashes aren’t for finding [related] things, they’re for naming things.
What you’re saying is like saying there are multiple functionally-equivalent Git commits with different hashes. It’s true, but that’s not the point of Git.
Fair enough. I guess they have “type-based search” for that? Kind of like https://hoogle.haskell.org/ but hopefully more effective.
content-addressed functions solve some problems, but create a ton more, and i can’t find any documentation about how they mitigate those.
like, if i write a function F, then a function G that calls F, then edit F, does G still call the old F?
this seems like you could easily end up with an “append only codebase” that simply grows without bounds…
I’m not fully following. I’ll share my thinking process…
If one function calls another using a hash, there is no ambiguity. (The probability of a hash collision can be made arbitrarily small.)
But writing out a full hash every time you make a function call is not ergonomic.
So there has to be some sort of mapping from convenient names to hashes.
Does the mapping (#3) suffer from being hard to reasonable about? (A) as functions change? (B) with dependencies?
the problem is that changing the hash of a function changes the hash of all functions that call that function.
it seems to work, but i’m honestly not sure how.
am i going insane, or does the syntax described in prose simply not match the given example? is this AI generated??
https://www.unison-lang.org/docs/fundamentals/abilities/writing-abilities/
It now(?) appears to read:
which all maps.
https://www.unison-lang.org/docs/fundamentals/abilities/for-monadically-inclined/#the-costs-of-monads
i mean, yeah, if you go out of your way to write Haskell in the ugliest possible way, it looks pretty bad, but noone writes haskell that looks like that!