xmcqdpt2 (u/xmcqdpt2)

xmcqdpt2 commented on Claude for Chrome anthropic.com/news/claude... · Posted by u/davidbarker

brookst · a day ago

“Easily” is doing a lot of work there. “Possibly” is probably better. And of course it doesn’t have unfettered access to all of your private data.

I would look at it like hiring a new, inexperienced personal assistant: they can only do their job with some access, but it would be foolish to turn over deep secrets and great financial power on day one.

xmcqdpt2 · 16 hours ago

It's more like hiring a personal assistant who is expected to work all the time quickly and unsupervised, won't learn on the job, has shockingly good language skills but the critical thinking skills of a toddler.

xmcqdpt2 commented on Clojure Async Flow Guide clojure.github.io/core.as... · Posted by u/simonpure

puredanger · 10 days ago

Clojure's focus on immutable data and pure functions side-step a lot of the trickiest issues with virtual threads. It's often not hard to isolate the I/O parts of your program into flow processes at the edges that can be mapped to the :io pool using virtual threads.

xmcqdpt2 · 9 days ago

The trickiest problems with VT aren't due to mutability. Mutability is problematic with any kind of concurrent programs.

The difficult problems are execution problems like pinning. There are plenty of existing concurrency libraries on the JVM (Cats Effect, clojure async, Kotlin coroutines, RxJava, quarkus, etc etc). The promise of VT is that you will no longer need those for scheduling and execution of work (whether that's tasks, fibers, coroutines, actors etc.) This only works if you use VTs throughout, not just on IO pools.

xmcqdpt2 commented on Clojure Async Flow Guide clojure.github.io/core.as... · Posted by u/simonpure

gf000 · 10 days ago

> can hang your program forever if the singleton definition suspends

I am no expert on the topic, but this seems like a very edge case scenario, that is not trivial to reproduce on even the linked bug ticket. Do you think it really is that big of an issue?

xmcqdpt2 · 9 days ago

It's really not hard to reproduce,

- vt1 locks lock1

- vt1 suspends on lock2

- n VTs attempt to initialize a singleton that requires lock1, so they all suspend within pinning class init.

- you release lock2.

- all platform threads are pinned, so vt1 can't run and you hang forever.

There is no lock inversion and progress would have been entirely possible with platform threads, even with just one.

It happened on our system because we have parallel streams that all access the same singleton at the same time, which is fairly easy to do (you have lots of parallelism, you have a map operation that needs a value from your singleton and that's it.)

The solution is to never suspend while in a static block, but it's hard to generalize because... any method may suspend, and there is no way to know that it will because of colourlessness. And also the singleton pattern is common, often involve accessing expensive resources or IO (and suspending) and doing so with class init lock is recommended and common,

https://shipilev.net/blog/2014/safe-public-construction/#_sa...

In our case this involves scala's object {} which is a singleton defined using class init. Kotlin probably works the same way.

xmcqdpt2 commented on Clojure Async Flow Guide clojure.github.io/core.as... · Posted by u/simonpure

robto · 10 days ago

I've been meaning to try this out, from my read it's a declarative way to get some structured concurrency. I work in a codebase that heavily uses core.async channels to manage concurrency and you really need to pay close attention to error handling. When you're spawning new threads you need to set up your own custom machinery to re-throw errors on a chans, close chans, and it looks like core.async.flow is a way to do all of this declaratively.

Just like `core.async` itself was a frontrunner of Virtual Threads on the JVM, I view `core.async.flow` as the Clojure version of the upcoming [0]Structured Concurrency JEP. I do wonder if it will use that under the hood once it becomes stable, the same way `core.async` is planning to move away from the `go` macro to just have it dispatch a virtual thread.

[0]https://openjdk.org/jeps/453

xmcqdpt2 · 10 days ago

We've been looking at virtual threads in a project at work and what we found is that it is quite difficult to adapt existing code to run with virtual threads.

For example, class initialization pins a thread so any singleton defined in the standard, recommended Java way (using a static inner instance of an inner class) can hang your program forever if the singleton definition suspends. And because they worked really hard on making async colourless, there is no way to know that a method call will suspend. This is a known issue with a workaround if the suspend is due to a network call,

https://bugs.openjdk.org/browse/JDK-8355036

which is useful for some applications (web servers). Figuring out that this is why my program was hanging required quite a bit of work too. We are still frustratingly far from the ergonomics of Go concurrency (all threads are virtual threads, hangs automatically panic).

xmcqdpt2 commented on Mostly dead influential programming languages (2020) hillelwayne.com/post/infl... · Posted by u/azhenley

Qem · a month ago

If we assume peak Perl was in the 00s, say 2005, an impressionable teenager of ~15 learning by then probably will keep using it for the rest of their life, even in absence of uptake by new people. Assuming a lifespan of 85, I estimate this day won't arrive before the 2070s.

xmcqdpt2 · a month ago

I was that teenager and I still think Perl is very neat but I don't think I can write it anymore without lots of doc reading.

xmcqdpt2 commented on Mostly dead influential programming languages (2020) hillelwayne.com/post/infl... · Posted by u/azhenley

duskwuff · a month ago

Forth was neat, but it was a bit of an evolutionary dead end. I'm not aware of any significant concepts from Forth which were adopted by other, later programming languages.

xmcqdpt2 · a month ago

Did Forth inspire the stack-based VMs of python and java? I don't know about that part of CS history well, but a very large proportion of all code runs on stack based byte code interpreters.

xmcqdpt2 commented on Mostly dead influential programming languages (2020) hillelwayne.com/post/infl... · Posted by u/azhenley

DrNosferatu · a month ago

The (literal) first and foremost ASCII descendant of APL was MATLAB.

I feel that the article should have made this a lot more clear - as so many people code along the APL -> Matlab / R (via S) -> NumPy family tree.

xmcqdpt2 · a month ago

Didn't they take their array programming from Fortran? The Fortran, numpy and matlab array syntaxes are basically identical, down to broadcasting and reduction rules.

xmcqdpt2 commented on Preparation of a neutral nitrogen allotrope hexanitrogen C2h-N6 nature.com/articles/s4158... · Posted by u/bilsbie

xmcqdpt2 · 2 months ago

The best part is the Methods section, which opens with

> Warning! Silver azide and halogen azides are extremely hazardous and explosive. Such compounds should be handled with utmost care and only in very small quantities (<5 mmol). Appropriate safety precautions (blast screens, face shields, Kevlar gloves, soundproof earmuffs and protective leather clothing) are necessary. Make sure to eliminate static electricity before handling. It is also crucial to avoid friction and light exposure and prevent any contact with metals during sample handling to ensure safety.

That is, please do the synthesis in full armor, in the dark and don't touch anything more than strictly necessary.

Also wear ear protection, because it's still going to go bang.

I like the green energy twist in the intro too. "High-energy materials" is an euphemism chemists engaged in weapons research like to use. I went to some conference talks about high energy materials before, and research presented at those talks was always funded by various defence agencies. But maybe that's just a North American thing, this particular group only acknowledges funding from the innocuous Deutsche Forschungsgemeinschaft.

xmcqdpt2 commented on Magistral — the first reasoning model by Mistral AI mistral.ai/news/magistral... · Posted by u/meetpateltech

rafram · 3 months ago

Is the number of em-dashes in this marketing copy indicative of the kind of output that the model produces? If so, might want to tone it down a bit.

xmcqdpt2 · 3 months ago

We don’t have em dashes as punctuation in French —- commas are usually used instead —- so we get overly excited about using them when we can —- everybody likes novelty.

xmcqdpt2 commented on Magistral — the first reasoning model by Mistral AI mistral.ai/news/magistral... · Posted by u/meetpateltech

adventured · 3 months ago

A similar sentiment existed for a long time about Uber and now they're very profitable and own their market. It was worth the burn to capture the market. Who says OpenAI can't roll over to profitable at a stable scale? Conquer the market, hike the price to $29.95 (family account, no ads; $19.95 individual account with ads; etc etc). To say nothing of how they can branch out in terms of being the interaction point that replaces the search box. The advertising value of owning the land that OpenAI is taking is well over $100 billion in annual revenue. Amazon's retail business is terrible, their ad business is fantastic. As OpenAI bolts on an ad product their margin potential will skyrocket and the cost side will be modest in comparison.

Over the coming years it won't be possible to stay a mere 6-12 months behind as the costs to build and maintain the AI super-infrastructure keeps climbing. It'll become a guaranteed implosion scenario. Winning will provide the ongoing immense resources needed to keep pushing up the hill forever. Everybody else - except a few - will fall away. The same outcome took place in search. Anybody spot Lycos, Excite, Hotbot, AltaVista around? It costs an enormous amount of money to try to keep up with Google (Bing, Baidu, Yandex) in search and scale it. This will be an even more brutal example of that, as the costs are even higher to scale.

The only way Mistral survives is if they're heavily subsidized directly by European states.

xmcqdpt2 · 3 months ago

I think the jury is still out on Uber. They first became profitable in 2023 after 15 years of massive losses. They still burned way more money than they ever made.