off-topic

yuhan 2026-06-10T09:46:33.833929Z

same ~ I often find myself wishing for the opposite, that we could have clojure.string fns available in the kitchen sink by default. Feels somewhat arbitrary why the re-* family "deserve" inclusion but not something as useful as str/includes? or str/join πŸ˜…

ray 2026-06-10T12:47:27.586679Z

I am going to Brazil in the summer (last two weeks of July and all August ... yes lucky me πŸ•ΊπŸΌ). Anyone know any folks over there that is aligned with (eg #C03S1KBA2 and #C0B7Q4XRM1U)? (yes I have asked in #C055AMK5Y but it's quite quiet - they're all on Telegram πŸ€·πŸ»β€β™‚οΈ and I am on that forum too. So anyway, I thought I'd expand the search here).

neumann 2026-06-10T17:28:40.916869Z

Where in Brazil?

ray 2026-06-10T17:35:42.116749Z

SP, Sao Jose de Rio Preto, Rio, Ilhabela, Belo Horizonte (for a music festival)

πŸ‘ 1
emccue 2026-06-10T13:07:30.783829Z

Hot take: automatic transitive dependency resolution where you declare 1 dependency and get N others automatically from any number of authors was a mistake

πŸ’― 4
borkdude 2026-06-10T13:11:14.626439Z

vendor lib ftw?

emccue 2026-06-10T13:12:06.052419Z

I don't think that's a solution either. In the background I'm doodling on something where I'm trying to think this through. The only thing I'm convinced of is that the current lack of friction in expanding your transitive dependency tree is unideal

emccue 2026-06-10T13:13:00.492149Z

Open to suggestions (and generally want to hear what people think a solution would be)

2026-06-10T13:18:22.606959Z

you know, that is one of the benefits of the vim/neovim plugin ecosystem: you have to manually specify all dependencies so it leads to folks either vendoring or avoiding dependencies in general

emccue 2026-06-10T13:24:25.606939Z

(specifically vendoring increases the friction of adding a dependency but it doesn't change the nature of what a dependency is. Copy pasting a folder with source code instead of pulling it over the network or as a compiled artifact doesn't change the fact that you are dependent on an outside party to develop and maintain that software. I agree that part of a solution needs to be adding more friction, but I don't think that's it)

borkdude 2026-06-10T13:29:21.028239Z

paying? ;)

borkdude 2026-06-10T13:29:33.361849Z

yeah, let's pay for all the OSS you use. great idea :)

πŸ’― 1
πŸŽ‰ 1
ray 2026-06-10T13:31:26.736909Z

write everything yourself from scratch. Simple.

πŸ˜„ 1
borkdude 2026-06-10T13:32:06.971899Z

me /scratches head

emccue 2026-06-10T13:34:39.072099Z

It's not not on the list of options

ray 2026-06-10T13:41:37.720459Z

get it from someone else | write it yourself | ??? please say ???

Ben Sless 2026-06-10T13:49:17.547809Z

You could make a point for paying for a forge per usage. Multiplex over trusted providers and rev-share model?

emccue 2026-06-10T13:55:21.866959Z

@raymcdermott I think there are two related problems. One is that when you get a library from someone else that person is basically always an unfunded volunteer. The other is that it is extremely easy to end up depending on hundreds if not thousands of those unfunded volunteers. In fact it is made very easy to do so

emccue 2026-06-10T13:56:06.833479Z

Whether those two problems have the same solution or intersecting solutions I cannot say, but I'm currently approaching it from the perspective of the second one

ray 2026-06-10T14:02:17.237799Z

so is it an issue of funding? You will only trust if the other person is "funded"?

emccue 2026-06-10T16:16:43.073569Z

It's one dimension.

emccue 2026-06-10T16:18:21.971879Z

When something is not funded directly it's subsidized. Say if you have a "decent tech job" that subsidizes hobbies. "How can this person afford to keep doing this?" And "to what extent can I trust that they are operating in good faith, will align with my interests, ..." Are all related questions

ray 2026-06-10T17:05:16.484929Z

Good luck fixing capitalism. I'm with you ✊🏼

Ben Sless 2026-06-10T17:08:15.066089Z

Working As Intended (TM)

seancorfield 2026-06-10T17:09:46.122079Z

I've been writing OSS since the early '90s -- sheesh, about 35 years! -- and it had never occurred to me that paying OSS developers should be a thing, until Cognitect/Nubank starting reaching out to offer GitHub sponsorships. I sponsor several projects that I use on a daily basis (although at least one of those should be sponsored by my employer since I use it at work, rather than in my OSS stuff, grumble, grumble).

Alex Miller (Clojure team) 2026-06-10T17:11:45.408389Z

Nubank has been paying about $250K/year https://www.cognitect.com/blog/2020/12/15/sponsoring-open-source-developers to open source developers. it's a good idea. more companies should do it.

πŸ’― 1
πŸ™ 1
πŸ™πŸΌ 1
πŸ™Œ 2
Alex Miller (Clojure team) 2026-06-10T17:12:50.976929Z

in addition of course to actually paying many people to work full- or part-time as employees on open source

seancorfield 2026-06-10T17:13:19.655249Z

Yeah, I think that's awesome. And Toyokumo. And Clojurists Together. It makes a big difference to those of us on the receiving end -- makes it much easier to justify continuing to work on these projects and to respond to bug and feature requests.

Alex Miller (Clojure team) 2026-06-10T17:14:14.648329Z

if everyone using open source supported those making it, it would be a different equation for sure.

πŸ’― 7
Alex Miller (Clojure team) 2026-06-10T17:37:09.332039Z

if Maven Central was pay per download with "royalties" going back to the developers, imagine how that would change the dynamics

2026-06-11T11:18:05.216759Z

ship the compiled artifact and use tree-shaking to reduce code duplication kek