littlestymaar
Joined 9 years ago
Joined 9 years ago
It was merely a “can we please not start a flame war on LLMs and focus on what is relevant to the Rust project itself”.
IMHO LLMs are causing lots of issues in the software world, especially in the open source communities but I don't think Zig's blanket rejection of everything AI-related is a good thing.
(And honestly I don't see why it would have changed given that the hardware has been getting faster in the meantime).
I don't think Dang is responsible of that part, but I may be wrong.
HN used to run on a single server (source: https://news.ycombinator.com/item?id=16076041), and I don't see why that would have changed given that the hardware keeps getting better.
> Why does HN use Algolia for search
Algolia is a YC company, it's pretty much free marketing for their asset.
> That's almost enough to run a 3W device 24x7 for a year. Do you know any old phone or laptop that can serve as a reliable Jitsi server yet draws an average of 3W or less?
You don't need to run it for 24 hours a day, nor do you need it to be the only process running on your machine.
Jitsi is a bit heavy for a phone, but easily fits on an old M1 macbook/mac mini, whose idle power consumption is well below 10W (idle power consumption is what matters, since your machine isn't going to be handling calls all the time). If you shut it down at night, you're almost good. And for any additional service you serve from the machine, you reduce the cost per service further.
Modern computers are fast, and fascinatingly energy efficient.
A website that runs on an infra that could sit in a cupboard under the stairs serving hundreds of thousands of users with very small loading time.
> My friends and family aren't going to be convinced to use a Jitsi instance running in my house
> (where I pay $0.35/kWh).
Using an old phone or laptop as server means you'll end up with a single digit annual electricity bill for that.
That's what I'm saying, it's a general design principle for new developments, but that's it. (And I don't think that's a good one)
> It really isn't about the layout. It got abused for layout
It wasn't abused for layout, it was all about layout in the first place. If it was about data it would never have been possible to “abuse” it for layout, because an heterogeneous table with nested sub tables makes no sense from a “data” point of view. The fact that this was supported from the beginning shows what it was built for.
> but ideally the semantic meanings are useful. I have seen cases where "<strong>" emphasizes it by doing something other than bold for example
But I agree with that. I'm not saying we shouldn't have semantics elements in HTML, I'm saying that pretending that HTML “is only about data” is silly in a world were something like 80% of HTML tags in web apps are <div> and <span> that are here only for layout purpose.
Nope. It's a html tag to lay out data in a table form!
> but it's probably the only element that does such a thing.
<pre>, <b>, <i> all come with an associated layout implication. But the worst offender are <div> and <span>, which carry zero semantic meaning and just means “I'm a block element” and “I'm an inline element”, those are pure layout element. In fact are the ones I'm using as template for my demand of <flex> or <grid> elements.
And html isn't just tags, it's tags and attributes on these tags, and things like hidden, height or width are indisputably related to layout and not to data.
The idea of HTML as a pure semantic layer with no layout consideration may be a general design philosophy for the language, but that's by no way a faithful description of what HTML actually is in practice. And pretending it is, isn't helping.
> completely orthogonal and swappable css.
You're talking about having a single CSS and HTML page for multiple layouts, there aren't the same thing at all.
Pet peeve of mine: there should really be `<grid>` and `<flex>` elements, as well as `<fi>` (flex item) and `<gi>` (grid item) for the child element instead of relying on a div soup with CSS attributes everywhere.