It scrolls smoothly, it doesn’t snap line by line. Although once the scroll animation is complete the final positions of lines and columns do end up aligned to a grid.

Neovim (as opposed to Vim) is not limited to terminal rendering. It’s designed to be a UI-agnostic backend. It happens that the default frontend runs in a terminal.

I don’t know if it’s your cup of tea, but Neovide provides smooth scrolling at arbitrary refresh rates. (It’s a graphical frontend for Neovim, my IDE of choice.)

A credit system is an essential piece of a robust economy

(This is probably explained in the article, but I don’t have a subscription.) The National Ignition Facility (NIF) creates fusion by bombarding a fuel capsule with lasers. The laser beams are reflected many times to build up energy, and to converge on the capsule. There is energy loss during that process so the laser energy that goes into the capsule is a small fraction of the electricity used to fire the lasers. When they say they got twice the energy out, that’s compared to the laser energy going into the capsule, not the energy required to fire the lasers. So its a long way off from a practical power plant, but still important progress.

The purpose of the NIF is to study what goes on inside the capsule - for better understanding, and to figure out how to get the most possibly energy out of a fusion reaction. Once they have figured that out a possible next step is to design a system that delivers laser beams with less input energy. It’s easier to do that after you know the ideal way for beams to interact with the capsule. Or maybe we never build a power plant based on the NIF design, but the findings help to make other reactor designs work.

If I’m doing more than one cracking two together is best. For the last one, countertop.

I get the flat, inside-the-sink idea. But I’d want to clean either way, and I clean the counters more often than I clean the sides of the sink.

For the PaperWM fans, this is a dedicated WM based on the same idea

For some more detail see https://dev.to/martiliones/how-i-got-linus-torvalds-in-my-contributors-on-github-3k4g

Oh, I didn’t know about the Teflon coating. From what I just read virtually all razor blades - both double-edged and cartridge - have PTFE coating. (Where PTFE is a PFAS compound, and PFAS is the family of compounds also known as Teflon.) But there is some hope for an alternative someday. https://www.pcimag.com/articles/111660-a-close-shave

So I guess I would say stick with double-edged. Or maybe electric would be better specifically with respect to water pollution? Since that’s the big issue with PFAS. I don’t know, just a guess.

I did not realize nano implemented syntax highlighting!

Oh right, there are some particular things that are helpful for a deeper language understanding.

Type classes and algebraic types are for sure standout features of Rust that make it better than most languages. Much of my experience before Rust was Typescript, but I have some background in Haskell so I was fortunate to have a head start on these concepts. I haven’t done any Rust interviews - my current role switched from Haskell to Rust after I joined. So I don’t know what interviewers are asking.

None of the prior languages you listed use manual memory management (which was the same for me). And even if you have that background, Rust does some things differently. (Although from what I understand explicitly codifies a number of ideas that experienced C++ devs have in their heads as “good practice”.) I think you’ll want to study up on how memory works. One of my favorite resources for this is Logan Smith’s Youtube channel. Those videos get me thinking about how this stuff I take for granted really works. The first two Rust videos on there, Use Arc Instead of Vec and Choose the Right Option are good ones to watch. Even if you opt not to use Arc<[T]> or Box it’s useful to understand how those differ from Vec and String.

Closures are weird in Rust, and are worth understanding. You have to choose between Fn, FnMut, and FnOnce. Plus there is the move keyword. I love the post Finding Closure in Rust for explaining what’s going on there. (It takes the implement-your-own-version approach which is a genre where I’ve incidentally seen some other gems, like Implementing a simple Promise in Javascript, and The Git Parable for understanding how git really works.)

Another area that is helpful to study is Rust’s implementation of async. It is similar to async as you’ve seen it before, but also different. For example in Javascript when you call an async function like, say, fetch it dispatches network requests right away. But in Rust a Future does not do anything until you call await on it. Learning about async leads into understanding of some more general language features. At the shallower end you learn about functions that return types based on trait, like impl Future or Box> because Future types often can’t be named directly so you have to describe what trait they implement instead. (This is very similar to how you work with functions that return closures.) At the deeper end you learn about working with Pin. You can get a deep dive on that in Pin and suffering by fasterthanlime. All of that guy’s posts are useful, but they are deep plunges so it can take some motivation to read them.

Since I seem to be recommending people to learn from I’ll add Mara Bos’ blog. She’s the Rust Library team lead. Her blog gets into some of the nitty-gritty stuff that gets you thinking about the language on a deeper level. She also wrote a book recently, Rust Atomics And Locks. I haven’t read it yet, but it looks useful.

Hey, you’re on a similar path to me. I’ve been on a Rust job for the past year.

Being a general-purpose programming language Rust can be used in a lot of contexts. The work I’m doing is all API server stuff, which I’m sure you already have a solid background in. There are some niches where Rust stands out that might be worth studying depending on your interest, but none of these are essential to Rust work generally.

• Crypto startups seem to be enthusiastic adopters of Rust. It’s not an area I want to get into personally, but this is likely the fastest path to a Rust job.
• Rust is probably the best language for compiling to WASM for running in browsers, in lightweight server-less functions, and as plugins. That could dovetail with your frontend experience. Although it’s a bit of an uphill battle to argue for WASM over Javascript in these cases.
• Rust makes an appealing choice for embedded programming as a safer alternative to C. This kind of work involves learning to program with nostd, and learning about controlling hardware.
• In non-embedded systems low-level pieces like device drivers are another good candidate for Rust.

Oh this is just the thing for playing bard, and casting “vicious mockery” several times per combat

The justification for invading Iraq was a claim that they were developing nuclear weapons. It was well known at the time that the evidence was flimsy, and that even if true it was a flimsy excuse for an invasion. The main piece of evidence was an intercepted shipment of aluminum tubes that were soon shown to have nothing to do with a nuclear program. (See https://en.m.wikipedia.org/wiki/Iraqi_aluminum_tubes). That one is not a conspiracy theory.

It looks like there is at least one work-in-pprogress implementation. I found a Hacker News comment that points to github.com/n0-computer/iroh

That’s pretty neat! But it seems to me it’s not storage because they’re not putting energy in to get out later. It’s more like mining naturally-occurring potential energy from the Earth’s crust. Probably that potential energy formed millions of years ago when tectonic plate activity pushed the rock up to its present elevation. So - it’s geothermal energy with extra steps.

I’d sure want to be very careful with health-risk assessments. But nickel-63 is pretty low-energy. According to this fact sheet absorbed radiation from exposure to skin is negligible without shielding. And that level of radiation is easy to shield so the battery casing presumably blocks all of it. (Tbf I believe fact sheets like that assume that your dead layer of surface skin cells has a small shielding effect, so the calculation is different if it gets in your body.)

The article also mentioned a possible variation with strontium-90 which is stronger stuff. It’s emissions are 8 times more energetic than Ni-63, and instead of decaying to stable copper, strontium-90 decays to yttrium-90 which emits radiation several times again more energetic than strontium-90. Here’s another fact sheet. (Sorry about using two different sources for fact sheets. I had a hard time finding one source with facts on both isotopes.)

The term “radioactive waste” suggests products from uranium fission, and the isotopes they decay to which can have extremely high-energy emissions, and decay through chains of several radioactive isotopes before finally decaying to stable elements which means extremely long half-lives overall. IMO the comparison is misleading. It’s kinda like comparing one “moderate” air quality day to many days inside a smoke stack.

Thanks for the heads-up!

Yeah, that makes a lot of sense. If the thinking is that AI learning from others’ works is analogous to humans learning from others’ works then the logical conclusion is that AI is an independent creative, non-human entity. And there is precedent that works created by non-humans cannot be copyrighted. (I’m guessing this is what you are thinking, I just wanted to think it out for myself.)

I’ve been thinking about this issue as two opposing viewpoints:

The logic-in-a-vacuum viewpoint says that AI learning from others’ works is analogous to humans learning from others works. If one is not restricted by copyright, neither should the other be.

The pragmatic viewpoint says that AI imperils human creators, and it’s beneficial to society to put restrictions on its use.

I think historically that kind of pragmatic viewpoint has been steamrolled by the utility of a new technology. But maybe if AI work is not copyrightable that could help somewhat to mitigate screwing people over.

That sounds like a good learning project to me. I think there are two approaches you might take: web scraping, or an API client.

My guess is that web scraping might be easier for getting started because scrapers are easy to set up, and you can find very good documentation. In that case I think Perl is a reasonable choice of language since you’re familiar with it, and I believe it has good scraping libraries. Personally I would go with Typescript since I’m familiar with it, it’s not hard (relatively speaking) to get started with, and I find static type checking helpful for guiding one to a correctly working program.

OTOH if you opt to make a Lemmy API client I think the best language choices are Typescript or Rust because that’s what Lemmy is written in. So you can import the existing API client code. Much as I love Rust, it has a steeper learning curve so I would suggest going with Typescript. The main difficulty with this option is that you might not find much documentation on how to write a custom Lemmy client.

Whatever you choose I find it very helpful to set up LSP integration in vim for whatever language you use, especially if you’re using a statically type-checked language. I’ll be a snob for just a second and say that now that programming support has generally moved to the portable LSP model the difference between vim+LSP and an IDE is that the IDE has a worse editor and a worse integrated terminal.

Makes sense. What are you thinking would be better? km/kWh efficiency, kWh capacity, and kWh/h charging rate?

I guess that last one could be kW charging rate. I raised my own eyebrows at myself typing kWh/h.

Then again it’s tough to capture a non-linear charge rate in one number. Maybe the press release could come with an asterisk: “*This is the coefficient of a logarithmic function.” I’m guessing you have something more sensible in mind like time to X kWh, or time to 80% charge.

Do you think people would stand for the technically-equivalent-and-simplified m/Wh instead of km/kWh? Slaps roof of car “Got a lotta meters in this one!”