My dream workspace is a real browser (with all dev tools), with integrated terminal emulator and integrated editor. Editor plugins could be prototyped with web technology and debugged on the fly (like Obsidian plugins). Is there anything like this?

You’ve basically described vscode!

As far as I understand, VSCode browser can't install browser extensions and doesn't even have Dev Tools. For example, IntelliJ IDEs ship with CEF-based browser that has Chromium Dev Tools, but it still doesn't support browser extensions.

Instead you can use https://github.com/coder/code-server, which is really vscode running in your browser. You then get all extensions, etc.

I was being a little tongue in cheek, and my "basically" was doing a lot of heavy lifting. VSCode is electron based, so under the hood it's already doing the heavy lifting. It's got a first class editor, first class terminal, first class plugins developed using web tech, very easily and readily debuggable.

It has a browser built in, which is "just" an iframe, and it definitely doesn't function as a full blown web browser, but it does work for previewing your dev work, and given it's a dev tool it makes sense that the experience would be editor+debugger+tools first, with browser as a second class citizen (rather than chrome with an embedded terminal which would be the other way around).

I built a project to add a terminal emulator to the browser (using a chrome extension): https://github.com/pomdtr/tweety.

I'm working on a `tweety edit` command which open arbitrary files in your $EDITOR of choice in a new tab.

Looks great, I'll give it a try!

No, it does not.

Rust approach to shared memory is in-place mutation guarded by locks. This approach is old and well-know, and has known problems: deadlocks, lock contention, etc. Rust specifically encourages coarse-granular locks by design, so lock contention problem is very pressing.

There are other approaches to shared memory, like ML-style mutable pointers to immutable data (perfected in Clojure) and actors. Rust has nothing to do with them, and as far as I understand the core choices made by the language make implementing them very problematic.

> There are other approaches to shared memory, like ML-style mutable pointers to immutable data (perfected in Clojure) and actors. Rust has nothing to do with them, and as far as I understand the core choices made by the language make implementing them very problematic.

Would you mind elaborating on this? At least off the top of my head a mut Arc<T> seems like it should suffice for a mutable pointer to immutable data, and it's not obvious to me what about actors makes implementing them in Rust very problematic.

mutable pointers to immutable data is the ticket.

We are back to color-sorted M&Ms bowls.

This book is also an accessible introduction to group theory, I managed to work through the first half of the book when I was 15 y.o.

How do you verify that the explanation is accurate? Mathematical definitions can be very subtle.

The answer is you put the top mathematician in the world to do it, easy peasy.

“The argument used some p-adic algebraic number theory which was overkill for this problem. I then spent about half an hour converting the proof by hand into a more elementary proof, which I presented on the site.”

What’s the exchange rate for 30 minutes of Tao’s brain time in regular researcher’s time? 90 days? A year?

For that sort of task: no, Tao isn't all that much better than a "regular researcher" at relatively easy work. But the tougher the problems you set them at, the more advantage Tao will have.

... But mathematics gets very specialized, and if it's a problem in a field the other guy is familiar with and Tao isn't, they'll outperform Tao unless it's a tough enough problem that Tao takes the time to learn a new field for it, in which case maybe he'll win after all through sheer brainpower.

Yes, Tao is very very smart, but it's not like he's 100x better at everything than every other mathematician.

Will Storr would say that the author is playing a status game of virtue.

What's wrong with Zod validation errors?

Embedded CPU vendors not shipping C++ compilers is what usually stops people.

Yup. And I like the implication that Rust is 'cross platform', when it's 'tier 1' support consists of 2 architectures (x86 & arm64). I guess we're converging on a world where those 2 + riscv are all that matter to most people, but it's not yet a world where they are all that matter to all people.

[1] https://doc.rust-lang.org/beta/rustc/platform-support.html

You are misunderstanding what Tiers are. Embedded architectures cannot be Tier 1 which requires running Rust compiler compiled on the architecture itself and testing stuff on with it. Only full desktop systems will be Tier 1, because those are the systems that you can run Rustc and all the nice desktop environments.

However most of the embedded world uses ARM chips and they are Tier 2 like thumbv6m and thumbv7em (there are still odd ones like 8051 or AVR or m68k, many of them lack a good C++ compiler already). They are guaranteed to be built and at the release time the tests still run for them.

I understand your tiers just fine. You are misunderstanding what "cross platform" means. Or rather, you're trying to redefine it to mean "what Rust supports, in the way we want to support it, on the few architectures we care about, because in our view nothing else of value exists".

However most of the embedded world uses ARM chips

My point exactly.

The converging is happening in practice. I’m using a keyboard running RMK for firmware, written in Rust.

In my experience most chips released in the past 10+ years ship with C++ compilers.

Quite frankly I'm not sure why you wouldn't given that most are using GCC on common architectures. The chip vendor doesn't have to do any work unless they are working on an obscure architecture.

IDK about Fil-C, but in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput. The cost of this is increased worst-case latency.

A CLI tool (which most POSIX tools are) would pick throughput over latency any time.

I see this claim all the time without evidence, but it's also apples and oranges. In C++ you can avoid heap allocations so they are rare and large. In java you end up with non stop small heap allocations which is exactly what you try to avoid when you want a program to be fast.

Basically java gc is a solution to a problem that shouldn't exist.

> in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput

If I had a dollar for every time somebody repeated this without real-world benchmarks to back it up...

I wish I could upvote this 100 times

Java (w/ the JIT warmed up) could possibly be faster than C++, if the C++ program were to allocate every single value on the heap.

But you're never going to encounter a C++ program that does that, since it makes no sense.

Entertaining anecdote:

I once worked on a python program that was transpiled to C++, and literally every variable was heap allocated (because that's what python does). It was still on the order of 200x faster than python IIRC.

You also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.

This. The memory overhead kills you in large systems/OS-level GC. Reducing the working set size really matters in a complex system to keep things performant, and GC vastly expands the working set.

In the best cases, you’re losing a huge amount of performance vs. an equivalent non-GC system. In the worst, it affects interactive UI performance with multi-second stalls (a suitably modern GC shouldn’t do this, though).

Depending on the CLI tool you could even forego memory management completely and just rely on the OS to clean up. If your program completely reads arbitrary files into memory it's probably not the best idea, but otherwise it can be a valid option. This is likely at least partly what happens when you run a benchmark like this - the C++ one cleans everything up nicely if you use smart pointers or manual memory management, while the Java tool doesn't even get to run GC at all, or if it does it only cleans up a percentage of the objects instead of all of them.

In terms of programming language development, take a look at Clojure. The clarity of reasoning behind every decision is unmatched.

I second that. Clojure is really a great joy to use. It may take a while to shift into the mindset, especially for someone new to Lisp, but after a while it's an absolute delight.

A great degree of occasional criticism of Clojure typically comes from brief exposure - either from not using structural editing idioms, misunderstanding REPL-driven workflows, or confusion around "the type system". Of course, Clojure being dynamically/strongly typed, doesn't really have a type system in the traditional sense, yet it has mechanisms that provide type-like guarantees, and from pragmatic point-of-view those instruments are incredibly robust.