HN user
I couldn’t resist a quick Google search for this.
“Mary Jackson is a world-famous African-American sweetgrass basket weaver. In 2008, she was named a MacArthur Fellow for her basket weaving.”
https://en.wikipedia.org/wiki/Mary_Jackson_(artist)?wprov=sf...
I have to say, that sounds more fulfilling than anything I will ever do. People who become the best at anything are usually truly extraordinary.
Delightful metaphor, I'll be looking everywhere for a chance to use that now!
This whole place only stands up because of dang. Someday (too) soon, AI moderators will be all we have to keep the peace in our forums... and dang is our most precious training resource. I'm grateful he's so transparent in explaining his process.
A lot of comments on this thread seem to feel like the “why” of this matter is settled with an answer of “The men have more experience and are working higher-level jobs. Therefore, they receive higher pay.”
This is not the equilibrium we are aiming for as a society, and the matter is not settled here.
The point of these measurements is not to demand that women are paid more for less work. The point is for us to keep asking “why”, and not just stop after the first one.
“Why are women earning less at the New York Times?”. Maybe the company is just top-heavy with men in leadership roles. This has been floated in this thread as a common cause.
“Why are there more men in leadership roles?”. A few commenters have shared anecdotes of having far more men in their recruiting process. More men applying would help explain more experienced men higher up in the company.
“Why are there more men than women applying?”. We’re getting closer to root causes now. In software engineering, for example, there are just more men in the workforce.
“Why are there more men in the workforce?”. It gets more difficult, but also more important, to investigate the answer at these lower levels. Girls Who Code and similar initiatives are tackling this behemoth cultural problem. It will take years to see the effect of their work, but their success breeds hope that someday, the gap in this New York Times statistic will close a little.
At any of these levels, a company can step in and try and correct the natural bias in their hiring or development pipeline. That is, of course, the most sensitive topic for a lot of us here. Such initiatives should have buy-in from the workforce, and there’s an implication here that the (unionized) workers of NYT do support some kind of intervention.
Their choice, and above all the very measurement of a wage gap, doesn’t need to be threatening to anybody here. It will forever be important to track this number even if we “feel” like the explanations are simple. It doesn’t represent some kind of action the company should be forced to take. It measures where we are on every level of asking “why?”.
Very happy to see more tools like this. There is so much potential for interactive tabs and sheet music with YouTube videos.
I only found out about https://www.soundslice.com recently. I'm not sure how it managed to evade me for years of searching for music resources on the internet... but for anyone interested in sheet music, I can't recommend it enough.
The design of the whole platform is so minimal and beautiful, and having notation synchronized with YouTube is simply brilliant. Built by one of the co-creators of Django, too!
You'll want to reserve ahead on a weekend! They have strict capacity limits, which is why it never feels too crowded.
I'm amazed at how many of us in Los Angeles live here for years and skip this place. It's one of the most beautiful places I've ever been.
Would you be open to mentoring someone curious about doing so?
What a place we live in where someone can see "policing and prosecuting" as "basic government functions" rather than "community building".
This seems like a pretty low price to pay for the huge upsides of safer rides and potentially lower car ownership, on top of the more comfortable experience discussed elsewhere here.
I use shell scripts left and right for all kinds of things in my regular dev workflow. Running tests with various configurations. Complex tmux layouts. Syncing non-got data. I could go on and on. Common Lisp would be an incredible asset for this, as Babashka already is in the Clojure world. The REPL alone makes writing/maintaining these scripts very efficient. Why do you feel like Python must be the choice for everyone?
It features a time-travel database, if that helps!
Clojure has some very expressive destructuring syntax as well: https://clojure.org/guides/destructuring
I see your point here... I was addressing to the feedback loop during development time. Babashka works well for Clojure in a Unix tool pipeline.
It's also possible to compile your JVM Clojure program yourself to a binary with GraalVM for even better performance than Babashka and even faster startup.
Seconded. I'm also a big fan of Aphyr's "Clojure from the ground up" series: https://aphyr.com/posts/301-clojure-from-the-ground-up-welco...
When you get into REPL-driven development, the JVM startup time (which is often under a second for me anyways) is a total non-issue. You don't continuously restart your program to see changes or run tests. You can refresh all your state instantly without exiting.
But before Babashka, that was indeed a barrier to using Clojure in shell scripts. Now we have it all!
I use Helix [0] myself, which has tree-sitter based commands for moving + selecting up/down/forward/back by expressions. These are built-in and require no configuration.
It's surprisingly excellent! Sure, the "language" of paredit features more powerful text manipulation that just simple movement... but combined with the new "jumping" in the latest Helix release [1], it makes for a very impressive keyboard-based navigation system.
[0] https://helix-editor.com [1]: https://helix-editor.com/news/release-24-03-highlights/
HoneySQL is so, so good. It does for SQL what Hiccup did for HTML. Once you start writing with those, it's hard to remember there's any other way.
Check out Biff, it's very thoughtfully made: https://biffweb.com
Soon there will be! https://jank-lang.org
I agree. It's a breath of fresh air in the Clojure world. I'm grateful to thoughtful builders like yourself and borkdude for bringing the language to new heights.
I'll second that the popular tooling, while powerful and reliable, its just not user friendly.
The official Clojure CLI, for example, is just plain confusing, and that's most people's first impression to the entire ecosystem. The config files, while they use the wonderful `.edn` format, are also not intuitive. Newcomers are the most likely people to encounter the most amount of error messages... which are famously difficult to read.
And that's before you even get into REPL configuration, which involves coordination with your editor process, a client process, and a server process. Even if you have a tool like Calva or CIDER managing it for you, you'll still get confused when something goes wrong unless you grok all the moving parts.
Even if you figure that all out, you still don't have Parinfer or equivalents setup yet in your editor. Also, clojure-lsp tends to require some configuration to get working the way you want. And that's before you get started with ClojureScript, which brings the complexity to another level entirely.
Despite all this, I love Clojure. It's an expert's language, even though it shouldn't have to be. Once you learn this stuff, you respect why much of this complexity exists. It's inherent to the amount of power the language gives you.
But doesn't mean we can't make it easier to use and get started with.
And when you're ready to take the fun to the web, look no further than Biff: https://biffweb.com
I'm an advocate for Clojure, and while I believe that the usability speed bumps are more than made up for, I completely agree with you. The awkwardness of Clojure's errors, REPL experience, and build tooling is a dealbreaker for many.
A couple years with Rust has taught me that intuitive errors and tooling will funnel you far enough into language to get you productive, and then you're much more likely to stay. There's just no way I would have stayed long enough to be a Rust professional if it hadn't been for cargo and rust-analyzer.
These "non-language" components of Clojure are just not easy enough to use, and its inhibited Clojure's growth. If, however, you do put in the time to grok these parts, the joy of using the language itself never fades.
If you are new to Clojure and would like to experiment with it in a way that is immediately useful, I highly recommend the Babashka runtime for scripting [0]. It's very fun, approachable, and one of the more polished parts of the Clojure ecosystem.
It's a particularly good entry point because unlike full-JVM Clojure it has a very fast startup time. Newcomers can use any file-watching /reloading tools (e.g. nodemon) that they're already familiar with to work with it interactively.
Hopefully, a enthusiastic user will graduate to using a REPL connection in their editor for a fully interactive setup. But newcomers tend not to do this... its an unfamiliar workflow to most, and can be pretty cumbersome to setup.
I'm feeling a similar disappointment here, although I'm sure this was carefully considered by the Tailwind team.
I've been working with a fully Rust-based web stack, and it's been such a joy. Tailwind compilation causes me to still deal with Node. I'd love to see that go away.
I think Helix by default binds `Ctrl-[` to return to normal mode.
That was more convenient for me, especially as I remap my caps-lock key to CTRL system-wide.
This book has been one of my favorite reads of the year. Thank you for it.
I'm not sure why so much of this thread takes offense to your work. HTMX has been transformational for me. I'm grateful that you persevere.
This is obviously a baseless and naive comment, and I'm glad others have stepped in to call it out. This whole thread is filled with noise like this.
The fact that there are so many strong opinions from people who demonstrate an embarrassingly low understanding of the situation is one of the reasons the problem is so hard to solve in the first place.
I think a lot of us reach for Jinja-style templates so it feels a little more like we're writing bare HTML. But they're of course still just templates, and they need a build step before they become valid HTML.
So it's true, if you're willing to use a DSL embedded in your server language (like JSX), then you'll have the full language tooling available to you. And this probably isn't giving up much over language-specific templates.
A JSX-equivalent for the Rust server-side rendering world would probably be maud [1] or leptos [2].
This is such a great project, thank you for sharing! It seems like you're getting the usual dump of negativity around HTMX... but as usual, not much coming from anyone who's actually tried to build something small/medium-sized. I keep hearing that this stack "would" fall apart in a bigger project, but I never hear any concrete, empirical descriptions of issues that actually do arise.
I'll offer one here... using HTMX usually means you're going to be writing HTML templates, and HTML templating languages don't have much IDE support. I really miss goto-definition etc. when I'm writing Jinja templates.
That being said, I've personally found Rust/HTMX to be a magnificent combo. I personally find writing backend endpoints in Rust to be no more cumbersome than any other language (after becoming comfortable with Rust)... and there's massive gains from the incredible tooling and type system.
I wonder if you've considered using Askama for your templates? It has a Axum integration that cleans up some of the boilerplate around template rendering. There's also an open PR for block fragments [1], which will make componentization of HTML fragments much easier, as discussed in this essay on the HTMX site [2].
We need more projects like this to demonstrate how useful, highly-interactive apps are made with HTMX. I'd encourage skeptics to try the same before writing it off.
[1] https://github.com/djc/askama/pull/824 [2] https://htmx.org/essays/template-fragments/