One may agree or not with codeberg's decision. But it was voted by a majority of the active members.
That's much better than what GH does, which is enshittify its platform and not give anyone a choice.
It's interesting to see how popular it became to port Clojure to new hosts. The post itself discusses let-go and jank, both of which got some discussion here on lobste.rs, and of course before that there were babashka, ClojureScript, and others. I'm happy about that because I personally think that Clojure is an enjoyable, very well-designed language, but it's not something that I would have expected to happen. Functional programming on persistent immutable data structures in a REPL is just a very nice basis to build on. An I know that Clojure was designed as a hosted language, or even as a sort of trick by Rich Hickey to allow him to tick the "runs on the JVM"-box for his dayjob but not have to write Java, but that other users take up the offer and port it elsewhere surely isn't a given. I guess a part of the reason is that Clojure tends to attract quite experienced developers, so high-quality ports to different language just seem within reach for many.
A Clojure that's closer to native is something that I intuitively would have liked to have for a long time, which is why I've been looking at jank for a while. Jolt seems to be fitting a similar niche, and it's exiciting to see a Reagent-style GTK wrapper is already available. Developing GUI apps using reagent / re-frame in a REPL beats anything else I've tried by far, and I certainly hope to try it out for a native app at some point.
It's worth noting that some of the reasons for the port given in the post seem to be disproven or weakened by the benchmarks at this point. Tail Call Optimization for more efficient recursions are explicitly mentioned, but the recursion benchmark is actually 8 times slower on Jolt than on Clojure-on-the-JVM (is there another way to refer to the JVM implementation of Clojure by the way that makes it clear I'm not talking about the language?). Jank similarly is mostly about as fast but a bit slower than Clojure-on-the-JVM, which I think just goes to show how well-built the original Clojure is, and that runtime performance for longer tasks is not an argument against it. Of course this project is only a couple of months old, so maybe there will be more gains here in the future.
I'm curious about the long-term development about these new Clojure dialects, and especially curious to see how the maintenance story ones that use a lot of generated code. I hope it doesn't need the sunken cost fallacy for devs to stay attached to something for a long time, because that just won't be as pronounced if you don't pour in months of hand-typing :)
The final scalar loop would determine the exact index. Whether the mask/ctz path is faster is probably very architecture and workload-dependent. On Apple ARM, NEON has no native movemask and when I looked at what the compiler does, Zig lowers the mask construction to several instructions. I had an agent do a simple four-lane M5 benchmark and scalar rescanning was faster for a failure in lane 0, approximately even for lane 1, and slower for lanes 2-3 (by up to 10%).
I'm assuming that on x86, where mask extraction is generally cheaper, the mask/ctz approach is more likely to win.
The author of that blog post needs to practice their reading comprehension.
They cite this sentence:
"It seems like many ‘vibe coders’ don’t realize that they don’t actually have a community around them."
...and proceeds to rant about it while ignoring the rest of the paragraph which sets that line in relevant context:
"They build projects as if they had, and spend resources accordingly. We see projects having a lot of code activity, heavy CI/CD testing, frequent and large release binaries. Sometimes, it feels like the amount of supported platforms exceeds the amount of actual users."
With the full context, the intent is clear: The problem is resource consumption. Projects that have all of the devops scaffolding and consumes a lot of resources but don't have a matching level of actual use. Codeberg does not have infinite compute, and they are seeing a lot of their resources being consumed by projects that no one is using. The problem is not lone wolf developers and never was, and to rant as if that was the claim is either sloppy reading or disingenuous.
Not all of reddit. The fediverse culture leans tech-oriented. But /r/rust, /r/emacs and /r/guix, yeah. It also has some features like feeds (e.j. https://piefed.social/f/programming) which aggregate different communities (sub-reddits) into one feed. This is useful as one interacts with multiple instances so there are some overlaps between communities. e.j. there are 3 somewhat active /c/rust.
I just saw that piefed requires an account to browse now, which is unfortunate. But I can't blame them after the LLM-induced scrapocalypse.
This is specifically why I specified "higher-level", because of this incredibly imprecise terminology we find ourselves with. C is of course high level, but I've found it much more useful for a long time to separate things into lower-level and higher-level, i.e. not low and high, but relative to each other. This is basically the only useful way to have any semblance of useful discourse around these things for a long time.
P.S. You don't have to specify "In my opinion", C is a high level language, it's not something one can really have an opinion on without changing the definition of "high level". Hence my using "higher-" and "lower-".
Gmail has detected that this message is likely 550-5.7.1 unsolicited mail. To reduce the amount of spam sent to Gmail, this 550-5.7.1 message has been blocked.
Dealing with incoming spam is never the hard part of self hosting email, it’s dealing with large email providers marking your sent email as spam, even if you do all the things you’re supposed to do for sending email.
Your IP address will never get a positive reputation on the volume of email a single normal person/household sends, so if you get unlucky and end up struggling to get into the inbox of people on gmail or whatever, you’re pretty much just screwed.
However, relaying via Amazon SES or a similar service from a less evil company is easy to set up and - at least for me - eliminated all my deliverability issues. But if you’re self hosting for political/data sovereignty type issues, this might not be an acceptable solution.
Tangential to the article, but I think it's so cool: if you find yourself forced to use pure Python, but wishing you could also do fast data processing with SIMD, you'll love this innovative technique by @retr0id.
The summary with spoilers is that SIMD is used in CPython for integer arithmetic, so if you pack your data into big integers, it will use SIMD under the hood for fast processing.
It absolutely does! Even more than others because prefill on local models with “commodity hardware” is very slow. Reusing SSD backed caches is what makes running eg DwarfStar with DeepSeek somewhat realistic today.
The definition of "memory safety" that he uses here is at least worth bookmarking:
"In a memory-safe programming language, memory logic bugs don't give the attacker control over all of memory."
It's far from what I would probably start talking about if a friend asked me what memory safety means, but then it's insightful the more I think about it. This is one of those terms/concepts that are difficult to pin down, anyway.
I'm with them. I've never seen more bike shedding than in the comments here. Obviously, they don't want AI. Neither do I. There's nothing complicated about it.
Fair and noted! I neglected to add an AI usage disclosure to the README like I have for some previous projects, but I've fixed that oversight now.
Sorry for misleading you and anyone else in that regard. I know the sinking feeling of seeing something cool and wondering the thought process behind it only to realize that it was unthinkingly created by a fancy text completion machine... and that's not a feeling I want to be inducing in others.
One may agree or not with codeberg's decision. But it was voted by a majority of the active members. That's much better than what GH does, which is enshittify its platform and not give anyone a choice.
Oh dear god lol what a terrible idea
Congratulations, this is cool!
It's interesting to see how popular it became to port Clojure to new hosts. The post itself discusses let-go and jank, both of which got some discussion here on lobste.rs, and of course before that there were babashka, ClojureScript, and others. I'm happy about that because I personally think that Clojure is an enjoyable, very well-designed language, but it's not something that I would have expected to happen. Functional programming on persistent immutable data structures in a REPL is just a very nice basis to build on. An I know that Clojure was designed as a hosted language, or even as a sort of trick by Rich Hickey to allow him to tick the "runs on the JVM"-box for his dayjob but not have to write Java, but that other users take up the offer and port it elsewhere surely isn't a given. I guess a part of the reason is that Clojure tends to attract quite experienced developers, so high-quality ports to different language just seem within reach for many.
A Clojure that's closer to native is something that I intuitively would have liked to have for a long time, which is why I've been looking at jank for a while. Jolt seems to be fitting a similar niche, and it's exiciting to see a Reagent-style GTK wrapper is already available. Developing GUI apps using reagent / re-frame in a REPL beats anything else I've tried by far, and I certainly hope to try it out for a native app at some point.
It's worth noting that some of the reasons for the port given in the post seem to be disproven or weakened by the benchmarks at this point. Tail Call Optimization for more efficient recursions are explicitly mentioned, but the recursion benchmark is actually 8 times slower on Jolt than on Clojure-on-the-JVM (is there another way to refer to the JVM implementation of Clojure by the way that makes it clear I'm not talking about the language?). Jank similarly is mostly about as fast but a bit slower than Clojure-on-the-JVM, which I think just goes to show how well-built the original Clojure is, and that runtime performance for longer tasks is not an argument against it. Of course this project is only a couple of months old, so maybe there will be more gains here in the future.
I'm curious about the long-term development about these new Clojure dialects, and especially curious to see how the maintenance story ones that use a lot of generated code. I hope it doesn't need the sunken cost fallacy for devs to stay attached to something for a long time, because that just won't be as pronounced if you don't pour in months of hand-typing :)
I was curious and looked into it.
The final scalar loop would determine the exact index. Whether the mask/ctz path is faster is probably very architecture and workload-dependent. On Apple ARM, NEON has no native movemask and when I looked at what the compiler does, Zig lowers the mask construction to several instructions. I had an agent do a simple four-lane M5 benchmark and scalar rescanning was faster for a failure in lane 0, approximately even for lane 1, and slower for lanes 2-3 (by up to 10%).
I'm assuming that on x86, where mask extraction is generally cheaper, the mask/ctz approach is more likely to win.
The author of that blog post needs to practice their reading comprehension.
They cite this sentence:
...and proceeds to rant about it while ignoring the rest of the paragraph which sets that line in relevant context:
With the full context, the intent is clear: The problem is resource consumption. Projects that have all of the devops scaffolding and consumes a lot of resources but don't have a matching level of actual use. Codeberg does not have infinite compute, and they are seeing a lot of their resources being consumed by projects that no one is using. The problem is not lone wolf developers and never was, and to rant as if that was the claim is either sloppy reading or disingenuous.
Not all of reddit. The fediverse culture leans tech-oriented. But /r/rust, /r/emacs and /r/guix, yeah. It also has some features like feeds (e.j. https://piefed.social/f/programming) which aggregate different communities (sub-reddits) into one feed. This is useful as one interacts with multiple instances so there are some overlaps between communities. e.j. there are 3 somewhat active /c/rust.
I just saw that piefed requires an account to browse now, which is unfortunate. But I can't blame them after the LLM-induced scrapocalypse.
This is specifically why I specified "higher-level", because of this incredibly imprecise terminology we find ourselves with. C is of course high level, but I've found it much more useful for a long time to separate things into lower-level and higher-level, i.e. not low and high, but relative to each other. This is basically the only useful way to have any semblance of useful discourse around these things for a long time.
P.S. You don't have to specify "In my opinion", C is a high level language, it's not something one can really have an opinion on without changing the definition of "high level". Hence my using "higher-" and "lower-".
As if to prove the point of over reliance on Gmail: Right now, Gmail is blocking Lobsters password reset emails as spam.
From the logs, via @pushcx
Any idea how we tell Google about this?
Wow very interesting essay on the role of technology in society and what people spend time on. Cannot fathom why this has a vibecoding tag tbh
Dealing with incoming spam is never the hard part of self hosting email, it’s dealing with large email providers marking your sent email as spam, even if you do all the things you’re supposed to do for sending email.
Your IP address will never get a positive reputation on the volume of email a single normal person/household sends, so if you get unlucky and end up struggling to get into the inbox of people on gmail or whatever, you’re pretty much just screwed.
However, relaying via Amazon SES or a similar service from a less evil company is easy to set up and - at least for me - eliminated all my deliverability issues. But if you’re self hosting for political/data sovereignty type issues, this might not be an acceptable solution.
Tangential to the article, but I think it's so cool: if you find yourself forced to use pure Python, but wishing you could also do fast data processing with SIMD, you'll love this innovative technique by @retr0id.
The summary with spoilers is that SIMD is used in CPython for integer arithmetic, so if you pack your data into big integers, it will use SIMD under the hood for fast processing.
I did. If somebody would pay me, I'd do it again.
It absolutely does! Even more than others because prefill on local models with “commodity hardware” is very slow. Reusing SSD backed caches is what makes running eg DwarfStar with DeepSeek somewhat realistic today.
Thanks for the empathetic reply!
For the record, I didn't feel actively misled, even though I'm glad there is now an AI usage disclosure.
Oh good, a post that talks about mail and doesn't try to shove LLMs up y... oh wait.
The definition of "memory safety" that he uses here is at least worth bookmarking:
"In a memory-safe programming language, memory logic bugs don't give the attacker control over all of memory."
It's far from what I would probably start talking about if a friend asked me what memory safety means, but then it's insightful the more I think about it. This is one of those terms/concepts that are difficult to pin down, anyway.
Love it! That's gone straight on the blog. The difference on a mobile browser is dramatic.
I'm with them. I've never seen more bike shedding than in the comments here. Obviously, they don't want AI. Neither do I. There's nothing complicated about it.
Fair and noted! I neglected to add an AI usage disclosure to the README like I have for some previous projects, but I've fixed that oversight now.
Sorry for misleading you and anyone else in that regard. I know the sinking feeling of seeing something cool and wondering the thought process behind it only to realize that it was unthinkingly created by a fancy text completion machine... and that's not a feeling I want to be inducing in others.