You're implying that those who are throwing hissy fits about "master" are aware of bitkeeper documentation and their (wildly unchecked) emotional response to this matter is nuanced enough to take "provenance" of technical terms into account.
Do you even realize how ridiculous these nonsensical "arguments" sound?
Ah yes, the if we change something that would mean we would have to change everything and that would be absurd, so we can't change anything ever argument. Classic.
Making "some people" happier isn't zero cost if the people in question are intolerant lunatics with ideas corrosive to the social fabric. It's one reason why the pendulum is swinging fiercely in the other direction.
TIL "I'm uncomfortable calling it master-slave, can we do main-replica?" is the idea of an "intolerant lunatic" that is "corrosive to the social fabric".
Good Lord, just listen to yourself.
Red-lined districts still shape America to this day and several red states have been rampant on racial districting to screw minority communities. You can't even pretend the history of slavery is in the past in America.
> Computer science would have progressed much further and faster if all of the time and effort that has been spent maintaining and nurturing Unix had been spent on a sounder operating system. We hope that one day Unix will be relingquished to the history books and museums of computer science as an interesting, albeit costly, footnote.
UHH is obviously sound but doesn't go far enough in criticizing the unix disaster.
These days executing random code is standard and if you don't do it you're wierd. Case 1: browsers automatically execute code from random sources. Case 2: People tell you to curl someurl.whatever | sh to install compilers (ie, the only way to use the rust rustc on non-rolling distros). And it goes on and on. It's not really an exception to standard practice to install applications. The only difference here is that it is from an actual human person instead of a corporation. They are at least somewhat trustable, unlike corporations which always have their profit motive to sell you.
Also, if you only run programs that have been approved by a third party organization first you're really restricting yourself.
1. Browsers aggressively sandbox the code they run.
2. If you’re running curl | sh on random urls you don’t trust, you’re asking for trouble.
Running random executables you find online is a good way to get spyware and ransomware installed. I’m not saying that’s the case for re:Amp, but it’s absolutely still valid to tell people not to run random programs they find online.
Clojure is a niche language that (for realistic purposes) is still tied to a single platform, the JVM, which (Clojure, not the JVM) looks more dead with every passing year. It never became popular and it's been steadily losing users. It's also not as general purpose as Common Lisp (ie. not suited for system or lowlevel programming).
If you're going to learn a niche Lisp, you might as well learn Common Lisp or Scheme which have well-specified standards, have stood the test of time and will still be around for decades to come.
Although niche, things are pretty lively in the community. Among other things this year great progress was made on Jank, the native LLVM-based implementation with seamless low-level C++ interop. As part of that work a test suite is being created [0] and now includes runners for all of the major implementations to compare compatibility, next best thing besides a formal specification.
Clojure will be around as long as the jvm. It’s mostly done at the core level, most updates are to leverage new host features nowadays. The rest is happily provided at the library level by the community (which is still very prolific).
And it’s not tied to the jvm per say, look at clojurescript (and derivatives) or the upcoming jank.
It’s far from dead. As much as I like CL, the ecosystem is a bit of a desert compared to the jvm.
The JVM has suffered a fate worse than death: it's become so wildly successful that it's boring. So much enterprise shit runs on Java that it has sort of faded into the background noise of civilization and, like the System/360 (now Z/OS) before it, doesn't grab headlines anymore.
Which makes Clojure extra tempting because there is a bit of a infectious way to get Clojure i to corporations when you are always just handing the ops guys a "Java" we app bundled as a jar but secretly inside it's all Clojure compiled classfiles that work perfectly run on many JVM-based web servers with no additional effort.
I think Rich even alludes to this fact in one of his talks where it would be disallowed to run Ruby/Python/Rust whatever but it's Java then it's a know entity.
Yeeeeah, except we're living in the DevOps era, which means things like "thinking about how this will be built and deployed" is now the devs', therefore the whole organization's, responsibility, and so you have to think about whether your CI/CD pipeline can accommodate, or be made to accommodate, the Clojure compiler, leiningen, et weary cetera.
There's another, orthogonal, aspect: I half-jokingly suggested Clojure as a substitute for one of the DSLs we use at work, and my idea was shot down by a teammate based on the reasoning that Clojure is hard and most of the Java devs (not my team, of course) in the shop are not up to learning it or coding in it. So that's another thing to consider: when you leave the company, who else will be up to maintaining what you produce?
Both of these considerations weigh strongly against attempts to "sneak Clojure in through the back door".
JVM is very much not dead even slightly. They just released virtual threads, which are ridiculously awesome. Also it's not tied to a single platform, clojurescript lets you write clojure in browsers and on node.js, and babashka lets you use clojure in a scripting environment via a single executable
I haven't tried clojurescript but I'm fearful of languages that run on top of other languages or platformks, because of complications that produces for debugging.
How do you debug ClojureScript? Can you modify the source-code while in the debugger? That is a huge time-saver, you debug and see a typo and fix it right away. My preference are influenced by my background in Smalltalk's "live" environemnt: you see the variables, the stack, and can change anything without having to stop the debugging session and then have to go back to the "editor" and then locate the place you (now know) you want to modify, and then start again.
Hm I definitely haven’t tried a debugger! I’m not sure if that’s a PITA to set up. I had a terrible time trying to get a debugger working with typescript on top of node.
Since clojure is so REPL heavy I haven’t felt like I’m missing a debugger too much. But the smalltalk live environment sounds ridiculously cool. I do end up using REPLs to remote programs (even prod lol) pretty often, which is pretty crazy for me coming from a node background
Likely just not a statistically significant enough sample of any of those to justify them even putting them on the chart. Except maybe Dart, and that gets the "curse" of being front-end tech which for some inexplicable reason is underpaid.
Nope. I mostly happily used Python in my previous job for many years, now I'm doing Clojure. There are benefits and drawbacks to each, but I don't know if I'd want to go back to Python. I'm a Lisper (Schemer, really) at heart so maybe I'm biased.
Having said that, I don't think I'd pick Clojure for unpaid (hobby) projects. The JVM is such a hog and I don't like anything related to the Java culture...
I frankly miss the JVM. I work almost exclusively in Rust these days and haven't worked in Java or Scala since 15 years ago, and I do prefer working closer to the metal.... But... The JVM is an amazing mature runtime with a boatload of tooling. JMX, which has been there since almost the beginning, is the kind of thing missing from almost everything other managed runtime I've worked with.
The amount of R&D that has gone into making it execute with good performance, and its overall stability...
Yeah, it's got the curse of being boring.
I do think it is perhaps unfortunate that Clojure is tied so heavily to the JVM, because I actually don't think it gains much from that ecosystem... but it's a product of the time it was first written.
Actually hell. I'm between jobs, I like Lisp, and I miss the JVM. I've never worked in Clojure, but does anybody want to hire me to work in it? :-)
> I do think it is perhaps unfortunate that Clojure is tied so heavily to the JVM, because I actually don't think it gains much from that ecosystem... but it's a product of the time it was first written.
When I was doing more Clojure, I loved that it was on the JVM because it meant I got to use every Java library under the sun. There are tons of battle tested Java libraries that didn't have to be rewritten in Clojure, and getting to use them for approximately zero financial and runtime cost was a HUGE benefit of Clojure compared to other niche FP languages.
Just to counter-balance the inferred conclusion that Common Lisp would not have any commercial usage (sorry, words are important, FUD is too close from hasty wording or hasty conclusions): https://github.com/azzamsa/awesome-lisp-companies/ (example companies using CL today, and yes some pick it for new projects, and yes some hire) (and I don't want to argue if the list is impressive or not: it's some commercial usage :D best,)
> the JVM, which looks more dead with every passing year.
Lol, only dying/dead in the febrile imagination of some HN commenters. The JVM has had some of the most explosive feature activity in the last several years. Java had several million greenfield projects in 2024-25 - among the top 6 greenfield programming languages according to the Github Octoverse.
Wild exaggeration. Wireshark is very limited in what it can do and has gained few if any new power-user features (especially when it comes to extensibility and programmability) in more than a decade of development. The macOS-specific functionality in this very post has been available for years.
Anyone who relies on non-trivial packet capture or processing workflows, ditches Wireshark (optionally reusing dissectors) and writes custom tooling (which is very easy to do).
Even the dissector stuff feels so.. broken? unmaintained? The lua api is very annoying to use and python support was removed over a decade ago. Have not used the C API so maybe thats just what most people use and its good, but for my usecase I usually just want to quickly sketch out a view for a custom protocol that I can see in the UI.
I would absolutely love for someone to write a good alternative to wireshark.
As a constant Wireshark user who's personally thanked Gerald Combs for this tool, we don't need an alternative to wireshark, just some architectural refactors. Many packet dissection fields are embarrassingly parallel, but because some of them can involve previous/future packets, wireshark does all packet dissection in a single thread. So when I scoop up 10M packets it can take 20 minutes for the GUI to load them all with a single core, while 100 other cores on the same machine sit idle.
Once loaded, you have to be super careful. One update to the filter bar, like "!icmp" and you'll have to wait another 20 minutes for all the dissectors to be re-run (for some reason.)
As a previous commenter stated, if you work with Wireshark a lot, you eventually write your own tool for your performance needs. It feels magical to have a 3-page C program sitting over libpcap giving reports in miliseconds that would take wireshark minutes.
FWIW, Wireshark 4.6.0 ships with `sharkd`, which encapsulates all the EPAN dissectors into a simple to use server that accepts JSON-RPC requests.
It is quite easy to write specialized performance tools on top of `sharkd`, and since it has the entire power of the EPAN (including statistics, charts etc.), using `sharkd` is significantly more effective than reading straight from libpcap.
The `sharkd` has been around for quite some while, but until recently one had to build it from source. But now it is included in Wireshark DMG, so it is easier to use.
You're right, and I didnt mean to sound dismissive of the great work that has been put into wireshark. I agree with you on the refactoring comment, and if that's something that can be solved in the current codebase and something I can help contribute towards with donations I would be perfectly fine with this outcome as well.
As it stands though, using the gui bits of the wireshark family of tools is just painful, and slow (as you stated)
Sadly proprietary, but the core of it was to open a file with pcap_open_offline() [0], and then calling pcap_next() from a loop and reading a few bits out of the packet buffer. With NVMe disks, the information I needed was instantaneous for a 10M packet file.
And I know with certainty that it did not work when I wrote my previous blog post about this, back in 2021.
So, from what I can see, the specific functionality to dissect Darwin metadata in pcapng captures, from macOS' tcpdump, has not been "...available for years.".
I think it is not an exaggeration to say that without Wireshark, so much of modern computing would never have been developed and we would be stuck in the past. The amount of visibility it gives is immense. I have used it for years, decades now.
Disabling Nagle's algorithm should be done as a matter of principle, there's simply no modern network configuration where it's beneficial.
reply