davidatbu

I never meant to claim "it's the same thing".

I was just suggesting, if, by "react-like" code, you meant "a UI library that uses a vDOM to transform functionally written code into DOM nodes", Yew fits the bill.

Also, typically, one writes JSX when writing react, not HTML. It's similar with Yew[0].

If you're already aware of Yew, I'm not trying to change your mind. I was just trying to make you aware if you weren't already.

[0] It says so right on the homepage: https://yew.rs/

It's still bad for my use case though. My use case being: (1) figuring out rails magic, and (2) coming up with ways to twist the Rust borrow checker into submission.

> Where HTMX really shines is being able to bring the experience of writing React-like code without a nodejs environment.

FWIW, if that's all you're after, and you've mastered the Rust borrow checker, Yew (a React-like experience), or Leptos (a SolidJS-like experience) might be interesting to look at.

The loudest voices in Rust that I know (pcwalton, steveklabnik, burntsushi, on HN for example) clearly acknowledge that Rust makes tradeoffs.

No one denies that there are "simpler ways to achieve memory safety". Stop-the-world garbage collection and reference-counting are exactly just that. Vale uses generational references, which, IIUC, has both memory and runtime costs when compared to the borrow checker.

Meant to say "... there isn't space ..."

From what I know from skimming the docs and listening to Richard's podcast, their focus currently is on achieving great compiled performance. Plus, from what I can tell, Richard is still a fan of Elm, so I'd guess he thinks there's space for Roc to contribute to the frontend (that last part is pure speculation though).

It is my understanding that roc aims to "bring Elm to the backend", so it does not at all look like a substitute for Elm.

Definitely learnt from that link, thanks!

That still hasn't won me over from prioritizing definitely-memory-safe languages over "fairly-memory-safe" nim tho.

You know: this always tempts me, but I hold back because nim is not memory-safe (or has a clearly delineated memory-safe subset like Rust), and I would rather pick up an actually memory-safe (even if GCed) language even if some perf-cost (like F#, Ocaml, Swift, Vale ..etc).

That would be interesting! You might already be aware. But there's mypyc[0], which is an AOT compiler for Python code with type hints (that, IIRC, mypy uses to compile itself into a native extension).

Wanted to give you a head-start on the lit-review for your students I guess :)

[0] https://github.com/mypyc/mypyc

I also have extensive experience with mypy and pyright, also even going as far as trying to fix a mypy bug (also unsuccessfully). For pyright, the dev was so responsive that I only had to report bugs for them to be fixed (sometimes in a couple of hours).

It's been a year or two since I've touched Python, but back then, Pyright, was way faster, was more feature-complete, had a much more responsive dev team (of 1). It was better literally along every metric: except that it didn't support custom extensions to the type system like mypy did. But that wasn't a huge issue since there were very few extensions, and even the one that was developed by a mypy core dev for sql-alchemy was hopelessly out-of-date, or impossible to get working. So I didn't miss it much.

All this to say: pyright was much better.

Ah, I get what you're saying now. When you said

> "you'd be surprised how many Rust engineers think unsafe somehow 'encapsulates' memory bugs inside the block itself,"

you essentially mean:

> "you'd be surprised how many Rust engineers think that they can use unsafe without regard as to whether they are maintaining Rust's safety invariants by hand in their unsafe blocks."

Yes, I do find that surprising!

I've also used with diesel async for personal projects, and I have ran into no rough edges at all, fwiw.

> [It's not true] that unsafe somehow "encapsulates" memory bugs.

I believe this real-life, 4-year, 1.5 million-line-of-code experiment disagrees with you directly [1]

> In general, use of unsafe in Android’s Rust appears to be working as intended. It’s used rarely, and when it is used, it’s encapsulating behavior that’s easier to reason about and review for safety.

[1] https://security.googleblog.com/2022/12/memory-safe-language...

Since we're both not providing data, I'd be interested in hearing your personal experience on this (if it's not too much of a bother, feel free not to respond!):

What do you do for a living, and do you find GPT-4 helpful for it?

> Subscription? How many people will pay a sub for it?

I'm a programmer, and I pay a subscription for GPT-4 because it's ridiculously worth it.

I'm curious, what do you do that you don't think GPT-4 is worth it?

I'm curious, why would there be doubts?

GPT-4 is incredibly useful, and it's clear there's so much straightforward bits of additional product development on top of it in various verticals that will be incredible productivity multipliers in the respective verticals.

Thanks for the ideas! Separating out presentation crate into it's own crate sounds like a great idea. Re "temporarily stopping rust-analyzer", I came across this trick[0] to make RA use a different build path (trading off disk-space for speed, but I mean, disk space is cheap).

Re: cranelift, I gotta check that out! Thanks for the reminder!

[0] https://github.com/rust-lang/rust-analyzer/issues/6007#issue...

> What's wrong with TypeScript.

I love typescript, but, from my PoV, what I miss in typescript is:

- An actually sound type system: This is a big one. Can you figure out why this[0] is unsound?

- I regularly have to do `as ` assertions, and I know it's not because I'm bad at typescript because it's often the recommended solution from cream-of-the-crop tS libraries for certain issues.

- Traits

- new-types

- Algebraic data types: Option and Result. 'nuff said.

- Pattern matching: :cheff's kiss:

[0]

    export function useSetter<T, K extends keyof T>(
      state: T,
      setState: (n: T) => void,
      key: K
    ) {
      return useCallback(
        (val: T[K]) => setState({ ...state, [key]: val }),
        [key, setState, state]
      );
    }

While I'm usually a no-macros kinda guy, but (I believe) leptos and dioxus provide tooling to hot-reload markup-only changes without (incremental) recompilation. Do you think that would be possible withour macros?

Can I ask: what did you find funny / worth remarking about?

In other words, you are saying that an HTTP server can detect distinguish between when the client is doing `curl $url | sh`, and when the client is doing `curl $url | sh -c 'cat > /tmp/file'`.

I'd love to hear the mechanism that the server would use to do that, if you have the time!

Yes, I do think that the most promising path we are aware of to AGI is exactly the route that OpenAI/Deepmind/Anthropic/FAIR/etc are taking.

In fact, I don't think anyone would disagree with that statement.

> OpenAI is a company that can barely ship a functioning website, or have proper security for basic stuff. You'd not expect this company to be the future of AI, do you?

In case you didn't know: ML researchers are infamous for being bad at traditional software engineering.

That's why, I personally don't think whether a company can "proper security for basic stuff" has much correlation with probability of achieving AGI.

Yeah, I guess we're disagreeing about a very non-concrete proposal, so there isn't much point to our convo :)

Mind explaining why? I just tried it, and it works fine.

Is what you're suggesting that one has to pass that `tokio_context` into every `.await()`? If so, I personally would be in strong opposition, cuz I don't think the verbosity cost is justified, in any of the use cases for async I've come across.

Thanks!

I guess it's more common than what my personal experience suggests (which is that it never happens).

Can't one do `curl $url | sh -c 'cat > /tmp/file'`?

If one is using a function from tokio itself, is it not a reasonable expectation that one should check the docs as to whether the function requires the tokio executor?