davidatbu

I don't know if it's due to my familiarity with Rust, but I find none of the examples cursed or surprising, except the "&* is useful" one. Even for that one, I think the use case of "turning a raw pointer to a reference" actually requires unsafe, and so it's imo a bit misleading to omit that fact.

All this is unlike a language i work with in my day job (and hence one would expect that I'd not find surprising), and yet I find so much behavior utterly baffling: https://dev.to/ben/what-is-the-oddest-javascript-behavior-4d...

Than you so so much!

How bad are the compile times? My understanding is that the compile times are currently bad, and they can't be improved without fundamental changes to the lang/type system.

I'm working on an "offline first" Github client. The things I want to achieve are:

1. Background sync of repo state/PRs/issues/etc.

2. Ability to do "optimistically updates" when creating/editing PRs/issues etc.

The short to medium plan is to implement a CLI interface. But I hope to abstract the core into something that can be compiled to wasm such that a web UI that has optimistic updates everywhere, and is "offline first".

I'm doing this post to see if folks have seen similar projects around, I'd prefer not to build something that's already built.

That ranking of type systems matches my experience a 100% too.

In my experience, in an RoR codebase, the dynamic-ness of rails severely reduces its utility to only enabling better auto-complete (as opposed to also helping out with writing logically correct code).

In typescript, when I do a refactor, or I add a feature, I will code for hours, relying solely on the typechecker for feedback, and then I will manually test, and then write unit tests. (It helps that I use discriminated unions with exhaustiveness-checks, and avoid shortcuts like `any`, to the extent possible).

Such a workflow is impossible with how limited sorbet is in the RoR context.

I'd still choose an RoR codebase with sorbet than without it any day of the week tho.

> The plan is not to support macros.

Gotcha. In every lang I've used a lot, I've found meta-programming (compile-time or dynamic) to be valuable (and often indespensible). I can imagine that a lang like Elm that is domain-specific can do fine without the expressive power of macros, but I struggle to imagine that for a general-purpose lang like Roc.

I'm sure you've ruminated on this, so I'm excited to see how it all pans out.

Maybe a Software Unscripted episode with someone who's written a lot of macros is in order? :) David Tolnay (serde maintainer) would be great!

We have a very similar taste in PLs :)

I'm super keen to see how Roc pans out, because it sits at an (IMO) riveting spot in the space of PL design tradeoffs:

1. The typesystem will be sound, ML-like, and so simple that any code that doesn't interact with external data will not need _any_ type annotations.

2. An aim to make it the fastest managed compiled lang around (faster than golang).

3. Functional.

4. A focus on fast compile times from the beginning (like golang).

5. Serde from rust is essentially a language builtin.

6. Zero side effects, only managed effects (which I think will do wonders for testability and mocking in a compiled language).

What I'm unclear about is:

1. Whether they'll support macros,

2. Whether their decision to build a whole new IDE will take away from the work that will go into an LSP (it will take a lot to pry away neovim from my hands).

It'd be dope if anyone more familiar can comment on the above!

Also, as feedback to Richard Feldman, your podcast is (imo) great marketing for your lang! It's what's made me excited about your PL.

EDIT: Forgot another feature I'm allured by: ability to run programs with type errors (as best as one can).

Like I said somewhere else "sledge-hammer" is _just as fast_ as Vanilla JS in those benchmarks (it's one of the "Vanilla Rust"/bare-bones entries to the benchmark).

Thanks for providing your data point!

If you're having another go, I'd recommend checking out sledge-hammer[0], a wasm-bindgen alternative that the folks behind Dioxus have been working on. It's a faster, but more limited version. Best of luck!

[0] https://github.com/Demonthos/sledgehammer_bindgen

Dioxus is also a vDOM based framework (like React). Leptos is a fine-grained-reactivity framework (like SolidJS/Svelte).

They are both _way_ faster than React, and they are both faster than Vue and Svelte by a larger magnitude than SolidJS is faster than either of them.

That is not because Dioxus/leptos have less features than Yew. I'd actually argue they are more feature-full [1].

For icing on the cake: the most "bare-bones" WASM/Rust based entry to the benchmarks, "sledge-hammer", is as fast as the most bare-bones JS entry.

There are valid reasons for not using a Rust frontend framework (over-the-wire size, compilation speed, ecosystem, ..etc), but execution/DOM-manipulation speed is not one of them.

[1] I've used leptos, and tried out Yew, and have read through the docs of all three.

To me, the benchmarks you linked show that the fastest WASM web frameworks I know (leptos, dioxus, sycamore) are competitive with, or faster than, the JS frameworks most famously associated with speed, like SolidJS and Svelte; and that they are way faster than React.

That doesn't support your statement here, so I was wondering what takeaway you meant to direct our attention to when providing that link.

I'd love to hear more about your experience, because it contradicts what the JS Framework Benchmarks[0] suggests.

Leptos and Dioxus, Rust/WASM frameworks, are competitive with SolidJS, and right out destroy React, when it comes to manipulating the DOM!

So I'd love to hear, if possible, about when was it that you evaluated your WASM based solution, what language and framework you used, etc.

[0] https://krausest.github.io/js-framework-benchmark/2023/table...

I def wanna try that out sometime!

It does sound to me like that is not a consequence of the GUI-ness of VSCode, but just the man-hours that go into making it. In other words, it doesn't sound like that experience can't be replicated in terminal-only editors.

If anyone has experience with remote editing in a terminal editor, but not through an ssh shell (ie, the traditional way), I'm very interested in hearing your experience.

A data point: I'm a plugin-heavy neovim user, and I wholeheartedly testify that familiarity with vi modal editing is incredibly useful when ssh-ing into remote systems, and I don't have my plugins.

As a heavy user of neovim who's been curious about the "noun-verb" approach to modal editing, this link was an excellent read!

I just skimmed the release blog post for Copilot Chat, and I don't see why it can't be implemented in a terminal based editor. Copilot itself was.

No one has claimed that “most library libs are migrating to index based memory management”.

I mentioned two crates that are DOM frontend frameworks, that also are based on fine grained reactivity (and not a virtual DOM). That’s an incredibly specific niche of rust libs.

Because it's still HTML/CSS, just using Rust compiled to WASM instead of JS.

I would say that it's a way to trade compile-time checks of reference validity for runtime-checks of reference validity.

Here's the implementation of "remove a value" [1] from the popular Rust crate that implements this pattern.

It completely sidesteps the issue you are describing because "deleting from array" does not mean "adjust every greater index by one".

However, I'll grant you that using this crate means you have to extend _some_ trust (even if very small) to the crate maintainer to maintain safety invariants, in addition to Rust's compiler maintainers.

But the fact that I could dive into its code (that I've never seen before) in 2 minutes and verify that it is not susceptible to the issue you describe gives me more confidence that auditing+trusting this crate will not be an undue burden.

[1] https://docs.rs/slotmap/latest/src/slotmap/basic.rs.html#395

> array-bounds-checking bugs.

Rust tries very very hard to avoid bounds-checking bugs, because it's central to the safety promise, maybe I'm misunderstanding you?

> either "list was re-ordered, you now have the wrong item" ... "can't compact the list, it just keeps growing even when old items are no longer used" bugs.

I have no direct experience implementing this pattern, but it's good to know that leptos (and others) tend to use one well-tested library that addresses these concerns[1].

> Sure, you no longer have to satisfy the borrow checker - but it was a tool to help you catch bugs, and you've cleverly avoided getting that help.

My impression is that one can perhaps claim "one traded compile-time checks of safety for runtime _panics_ when unsafe things are about to happen", and not that using this pattern exposes one to the same issues that the borrow checker avoids.

[1] https://docs.rs/slotmap/latest/slotmap/index.html#why-not-in...

A great read!

Might be worth pointing out: leptos, a Rust WASM UI library, uses the "store an index (or ID) into some central data structure" idea extensively.

Sycamore, another Rust WASM UI library, has been using arena allocation, but will also be transitioning into the leptos approach in coming versions.

(I believe) this is partly because the borrow checker's enforcement of a tree-like data structures / ownership doesn't always work well with the JS event loop.

I haven't read your blog yet, but I'd be lying if the same thought hasn't crossed my mind :)

As a regular consumer of pg docs, I vehemently agree that they are incredibly detailed, and at the same time, daunting to navigate.

I THINK SO TOO!

I'm 97% sure that just using static analysis to provide all the relevant type definitions and function signatures as context for code completion in LLMs alone will be a massive value-add. I'm literally doing that by hand right now to GPT-4, and it works.

And I think there's more stuff that can be done where one sets up an automated cycle of (1) prompt LLM, (2) type-check completions, (3) construct prompt that incorporates type checking errors, ..etc.

I really think that this, combined with types written with the "make illegal states unrepresentable" philosophy, will be great.

I really wish I had time to work on this myself.

Can you expound upon why Rust is having an identity crisis? Rust's current mission is: "empowering everyone to build reliable and efficient software." It seems like it's hitting that goal to me (for .e.g., it empowered me, a person who's never written serious code in C/C++, to write wasm-based speech recognition reliably and efficiently).

Also, what is the identity crisis that JS is having?

Did you actually shift careers those two times in the past (Ie, change companies/jobs/job focus)? And will you be doing the same when "calling a third" now?

I'm curious, which episodes are describable as "not only programming"? I ask since I can't think of one.