jonathrg

(not OP) some ideas: make the <pre>'s not go all the way to out the edge of the window. Make the diff colors and code colors less dramatically different from its surroundings. Increase the contrast of the default text. Use blue for links. Drop the orange

Please remove my UUID 039a69dc-b0a1-4be0-b424-5e45aca8d3fb from the list. I spent a lot of money on it

Would appreciate if someone could summarize the thread here, since tweets after the first are not visible if you don't have an account.

The source of the humor is that what Slotin did is extremely funny. So obscenely reckless.

That's nice, I'll use that next time. Although it always feels kind of bad to write client side validation code because you're going to have to do the same checks on the server side anyway.

C's function declaration syntax is pretty weird and makes the language harder to parse. Most languages have a function keyword.

The channel is free. Repeat each bit 1 billion times and reconstruct the messages based on that

This is just sad to watch

I'm so sorry

a is for array

b is for byte or buffer

c is for character

d is for destination

e is for event or error

f is for file

g is for graph

h is for handle

i is for index

j is also for index

k is for key

l is for length

m is for mode

n is for number-of

o is for object

p is for part

q is for queue or query

r is for reader

s is for source

t is for time

u is for user

v is for value

w is for word

x is for x component

y is for y component

z is for z component

dicts are used internally in the language to look up class and module attributes. They are optimized for this use case. How can it be wrong to use them that way when the very fabric of the language depends on it?

namedtuple is widely used in Python code, especially before the introduction of dataclasses.

I guess I just have to disagree. My experience is that it is robust, and removes an entire category of problems that appear when your state is spread across the back- and frontend.

As someone else mentioned, SSE is a somewhat simpler protocol that achieves the same purpose. Same idea though.

> Mostly just thinking that XHR to mutate (form submissions, etc) and then SSE to send the updated DOM elements would be a good combo

Yes, that's basically the idea.

Parts of htmx were yoinked out of the core library into an extensions repo relatively recently, as part of htmx 2.0. That might explain the relatively lower number of stars. More important than github stars is that it is indeed part of the htmx project and is documented here https://htmx.org/extensions/

It is SSR, in the sense that the server sends HTML over the websocket. HTMX swaps out content based on the element id. Doc: https://v1.htmx.org/extensions/web-sockets/

If you mean SSE, then yes that would work just as well (unless you need the bidirectionality for the client to modify some aspect of the connection after the page has loaded). There is an htmx-sse extension too.

I'm not sure how XHR alone would let you automatically get backend state changes reflected to the frontend. You can poll one or more endpoint, but that's more complicated to get right and less efficient.

But it is simple :) The underlying technology might be more complex, but the library is solid, it's trivial to update any part of the page once you have the libraries set up, and you don't need to write any javascript. Works for me!

I agree that it becomes complex if you have state on the frontend. htmx scales better if you keep all or most of your state on the backend. I've found that using the websockets extension really helps with automatically keeping the frontend in sync.

I have seen some tutorials where emojis are used as metasyntactic variables. Not an improvement

For simple applications, yes. In practical applications you often need to shift the "fixed" point around manually to maintain the appropriate dynamic range.

I think I misread the comment (I thought you meant that 2x improvement seemed like too much, but perhaps you meant the opposite)

Cortex-M4F has an FPU, i.e., hardware floating point support (albeit single precision only). You likely would see a much greater performance drop without it.

How about x, y, f?

OK, Poe's law at work then :)

Does caching help? If so, shouldn't getElementById do the same thing under the hood?

It doesn't clearly come across as a joke.

Integer wrapping on overflow is not just a C thing, it happens at the hardware level as part of ALU instructions. It's actually kind of difficult to come up with a different behaviour that makes sense. Saturating arithmetic requires additional transistors.

> It's still a new C library and it's a little rough around the edges. But it's getting so good, so fast, that I'm starting to view not using it in production as an abandonment of professional responsibility.

What an odd statement. I appreciate the Cosmopolitan project, but these exaggerated claims of superiority are usually a pretty bad red flag.

Sure, an application built in Debug mode with a compiled language is going to be much faster than if you implemented it in an interpreted language. Given how much of the world runs on Python, PHP and Javascript, your zig application in debug mode is probably going to run just fine.

It is a general purpose programming language that should be able to do anything you want, whether it works for you depends on what you want to do, the ecosystem might be lacking since it's a young language. Just try it out!

Although it doesn't have the same level of compile-time guarantees, there are runtime checks to ensure memory safety if you use Debug or ReleaseSafe. You can do your development and testing in the default Debug mode and only use ReleaseFast or ReleaseSmall once you need the extra optimization and are confident in your test coverage.