Those guidelines say "Please don't post on HN to ask or tell us something. Send it to hn@ycombinator.com.". That's what the parent commenter should have done.
And "Please don't comment about the voting on comments. It never does any good, and it makes boring reading."; your comment is commenting about voting, and this guideline sets a precedent that boring reading is not desirable.
and "Please don't comment on whether someone read an article. "Did you even read the article?"" which you are doing about the guidelines.
and "Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting." which reinforces the idea that uninteresting comments are not deisable. "The title is bad" is not a very interesting comment.
Pet annoyance recently is seeing people comment "why am I being downvoted? What I said was true" when what they said was arguably true - but also low effort, flamebait, tangent, off-topic, or similar; "it is correct" alone isn't enough. Since this has been annoying me I want to write more, here are examples:
Searching Algolia for 'downvoted': https://news.ycombinator.com/item?id=41039279 which says "Microsoft is like Disney, they steal from others and trounce others for stealing from them. Absurd people." followed by "Sad to see this extremely historically accurate and relevant comment downvoted.". It's arguably true - but also arguably false - but definitely a single line of low effort flamebait. Actually justifying the claim would be better.
And https://news.ycombinator.com/item?id=41027729 - about Kamala Harris "I hate to say it yet I don't think she's polling well because even in 2024 I don't think America is ready to allow a woman of colour be POTUS." reply "You’re downvoted, but you’re correct.". Maybe it is correct, but they could at least argue the case for their claim? Something more substantial than a one line which is basically "America racist"? ("Eschew flamebait. Avoid generic tangents. Omit internet tropes." - guidelines).
and https://news.ycombinator.com/item?id=41008957 CrowdStrike thread -> substantive comment on centralised control and security -> risks of splaying personal valuables out in front of everyone at security -> security tried to screw me because they had to do their job -> I got downvoted "by some swede who doesn't think this stuff can happen"; assuming the downvote is because people don't believe it happened, rather than because it's marginally - if at all - relevant, substantive, thoughtful, interesting.
Can you or someone else familiar with Unison tell us what specific things about Unison feel ahead of its time? I don't know Unison so these things will be a good motivation for me to learn Unison.
Unison tries to swallow the whole elephant all at once, which is probably what the author is getting at.
* `ucm` is like a coding assistant that sits with you the whole time. You don't grep through code to find snippets or anything, you use `ucm`. It does a whole lot more, but that's just the trivial example.
* You need `ucm` because Unison stores code as a syntax tree, not text. This is awesome because versioning/dependency conflicts/rename issues just go away. This is not awesome because nothing else knows how to understand this: other source control systems will just not work.
* It's really trying to drag functional coding into this decade and what we use code for in production. It's not trying to be Haskell which is a great language, but doesn't (to me) feel like it was designed to do something like a simple web app.
* It is supposed to do distributed cloud computing without modification (this smells like where the VC money came from), but again, you have to use their platform because other clouds don't understand Unison.
The list goes on.
Each individual piece of Unison I think is really great. I love the `ucm` model of having an assistant sit next to you the whole time. What I don't love is that there is just _so much_ learning placed on the developer. To understand Unison, you need to understand a lot of what they're doing, a lot of what they are doing is novel, and so you have to eat the whole elephant that they are. I don't know if there was a path where they could have eaten the elephant one bite at a time, but it really makes the onboarding onerous.
For me the biggest limitation is replicating the SQLite across machines. If my app is running on multiple nodes, then we need to write/use some tooling to replicate the database file across nodes. With that comes the problem of figuring out how we want to handle error scenarios like failed replication, partial replication and such other things.
And these are all hairy problems. At that point it might be just simpler to use a centralized Postgres or a proper distributed database.
> You post this as if everyone is supposed to know who Karpathy is or what any of that means...
Firstly, this is HN! If every commenter mentioning Karpathy has to prefix their comment with an intro about Karpathy and LLM, then HN will become a boring read.
Secondly, if you don't know who Karpathy is and what any of this means, it is not all that difficult to search for "Karpathy" and "LLM" in your favorite search engine.
Usually having index.html in /now would behave as if the /now was the page. Other index.extension files (like index.php) might also work depending on the server configuration.
You mean like /now/index.html. Yeah, that could work! Thanks!
But "/now.html" feels "cleaner" to me. I know others might disagree.
If this now thing could support just "/now.html" or even "/now" redirecting to "/now.html", that would be swell! Maybe they already do support it? Hoping to learn from the community if these alternative paths are supported.
/now is cleaner in practice, because it's shorter, matches a (nascent, proposed) "standard", and hides the implementation details.
File path /now/index.html is a fine way to expose your content at /now ... Most webservers will default to config that allows this.
You could replace it in the future with a gigantic web app that is wired into your brain implant to retrieve realtime status. If you use /now.html, you would have to fight the framework to lie about the implementation details, instead of just not specifying them in the first place.
You could also configure your webserver to serve /home/carbonatom/webstuff/dereks-idea/now/new-version-2025.html as /now, if you like. These are the kind of implementation details that a good URL will hide (even if the specific example is a terrible case, the equivalent does happen sometimes!).
What do you want out of support? Listings on the nownownow.com site seem to be done manually, so it shouldn't matter what you make the path if that's what you're going for.
> there's no reason your HTML files have to be named with .html at the end of the filename
How do you know that? Do you know how I use my computer? I need to browse the HTML files lying on my disk with my browser? My OS and browser does not open files that are not named .html on the disk as HTML pages on the browser. So I need them to be .html so that I can browse my pages on my laptop.
> I understand if you are manager/owner you might be running comms via email. But internally all of that went to slack for good reason - lack of history is a feature, not a bug.
I am neither manager nor owner. Just another 1x engineer. 75% of my comms run over email. 25% over Jabber.
Well you are not op to begin with and admit running a chat app which is has 99% chance of having better UX than email.
Email is good for having common interface. In my case it's ~abused in 99% of cases.
Also - you do not mention how much non-comms emails do you receive. While chat apps are fucky in terms of lock-in, lack of interop and tons of other things, lack of spam is nice.
+1
I don't understand why people are downvoting your comment. This title is absolutely a violation of HN guidelines. And a very blatant one no less!
Do people not read https://news.ycombinator.com/newsguidelines.html anymore?