indiv0

I'm having trouble parsing what you wrote. You say that you don't need to have unquestionable authority to use this style of language and then proceed to give an example of an unquestionable authority using this style of language.

Is this basically an Effect System?

Either way I'm excited to be able to generalize over asyncness.

*EDIT*: I now see that they explicitly address this question in the post:

> The short answer is: kind of, but not really. "Effect systems" or "algebraic effect systems" generally have a lot of surface area. A common example of what effects allow you to do is implement your own try/catch mechanism. What we're working on is intentionally limited to built-in keywords only, and wouldn't allow you to implement anything like that at all.

> What we do share with effect systems is that we're integrating modifier keywords more directly into the type system. Modifier keywords like async are often referred to as "effects", so being able to be conditional over them in composable ways effectively gives us an "effect algebra". But that's very different from "generalized effect systems" in other languages.

No only that, but it's perpetually out of stock in most regions as well.

I'm not well versed in queuing theory, but I would assume that's rather the point. The existence of an unboundedly growing queue implies an inability to keep up with demand, so someone has to lose. The most shameless queue jumpers get served earlier because they have the highest priority. Anyone stuck in the queue didn't have a high enough priority in the first place.

From a utilitarian standpoint it makes sense :shrug:

Not to be reductive, but why not `docker run` the sha256 of the last successful stage of the build and run the next command manually?

Because there’s no async fn on traits yet, almost all “async” traits are returning Pin<Box<dyn Future<Output=T>>> under the hood.

Same principle also applies if you’re trying to put a future in a struct (to create a named future). One of the fields will have more or less that type. This is useful for a few reasons (e.g. making it easy to refer to a specific future in type signatures or for writing futures out by hand).

As someone with extensive experience with Rust and a teensy bit of experience in Go I can tell you that I adore Rust for every use case I’ve tried it out for *except* for network services. It works ok for low level proxies and stuff like that; but Python/Flask-level easy it is not.

Meanwhile my experience with Go has been the reverse. I’ve found it acceptable for most use cases, but for network services it really stands out. Goroutines <3

I was expecting some clickbait/spam (the layout of the website has that feel) but this was surprisingly super in-depth and 100% matches up with my experience doing prompt engineering.

There's a fine line between so descriptive that the AI hits an edge case and can't get out of it (so every attempt looks the same) and not being descriptive enough (so you can't capture the output you're looking for). DALL-E is already incredibly fast compared to public models and I can't wait for the next order-of-magnitude improvement in generation speed.

Real-time traversal of the generation space is absolutely key for getting the output you want. The feedback loop needs to be as quick as possible, just like with programming.

1. Don't use the `async` ecosystem.

2. Prefer dynamic dispatch to monomorphization (i.e., use fewer generics).

3. Don't use proc macros (i.e., don't depend on the `syn` crate, even transitively).

Easy to say; hard to put into practice. But that's all there is to it.

They do containerize but it’s not enough. You still need the right drivers and CUDA stuff installed on the docker host, which can be finicky to setup. Not to mention figuring out how to get docker to actually pass the GPU to the container.

Are you boycotting operating rooms while you’re at it? I’ve never seen such an overreaction to such a non-issue before. How do people get to a state where they can unironically say things like this with a straight face?

You’re completely correct, but I think GP’s point is that we need said web developers to chase fancy new framework Flask-Native-Redux-Rust Edition™ to keep momentum going for the language as whole. Which personally I think has some merit.

Personally I think the understated way in which Rust now maintains a death grip on the WASM tool chain and tooling is the answer. Let the web devs have their JS. We can have everything `<canvas>` and below.

Eh I wouldn’t say enormously. The latter two are hyper powerful but hyper rare because how often is a newbie using threads? The former two are just a method call you add to the offending line when the borrow checker complains, and not a moment sooner.

It tells you what’s wrong, you fix it, you move on. It’s no different than forgetting a semicolon in Java.

Nothing needs to be undone after. Either those 4 tools get you a valid program or you made a logic mistake you would’ve made in any other language. Or in Rust sans borrow checker. I don’t see how that’s an issue.

I don’t see how my methods are spurious objections or how I’ve spuriously objected to anything. My methods are tested, tried, and proven to work on a sample of n=1.

All that’s left is government funding and we can start mass human trials next month.

There is an answer to this. Just `.clone()`, `.to_owned()`, `Arc::new`, and `Mutex::new` like a madman. Sure it’s visual garbage. Yes it impacts the semantics of your program. Yes it wastes memory. Who gives a crap? Those four things break you free of the borrow checker while also letting you get a grip on the language.

The docs don’t advocate this approach. Presumably because they favour correctness and understanding over blind hacks. I get why the docs are the way they are but I don’t think it’s worth the blood sacrifice necessary to stay on Mr. Borrow Checker’s Wild Ride.

Note that the above advice is no longer a 100% hammer-fits-all solution because futures and async and pin have unleashed brand new eldritch horrors upon us.

Even if that 80,000+ miles point is true it’s still better than a gasoline car over its lifetime and completely dishonest because who the hell is buying a Tesla and living in an area with 100% coal fired power? Germans?

The “U.S. average energy mix” comparison of 14,800 is much more accurate.

Not to mention the equation gets more and more favourable to EVs with each passing year.

Parallels on M1 here! I followed mitchellh's guide to setup NixOS [0]. He runs an X server on the machine and works entirely within that (minus mail, etc.). I tried that at first then decided against.

I'm now running the machine headless in the Parallels VM, and using VS Code on the host to Remote SSH into the machine. It's absolutely incredible and I highly recommend this workflow. My rationale is here [1].

Fair warning I haven't tried to get any OS other than NixOS installed. Not sure how usable Ubuntu ARM or others are.

[0]: https://github.com/mitchellh/nixos-config [1]: https://news.ycombinator.com/item?id=31101605

Alright, then allow me to explain.

Before, there were a multitude of reasons not to develop in a VM: Poor support for accelerated instructions on laptops; Slow CPUs; limited RAM; slow file-sharing between the host and guest.

The M1 architecture solves most of the issues.

Modern laptops almost universally support accelerated instructions now. This means less overhead, so doing everything entirely in the VM is worth it now. So no more dealing with slow file-sharing.

The speed of the M1 also means you're not limited compared to your desktop. Depending on the benchmark (especially any benchmark relying on CPU cache size), it may be faster on the M1 air than on a 5950X. Even in workloads where the laptop is slower, it is now fast enough.

Running docker containers in a VM on a 16GB *non-M1* machine is untenable. The M1's RAM is not only higher bandwidth and lower latency, but the compression and caching has improved so much that you can fit much more in that same 16GB.

In use-cases where you need more than 16GB, the M1's NVMe disk is so low latency that swap usage is indistinguishable in performance from RAM usage. So the laptop has no memory limit, for practical purposes (though the wear on the disk is increased in this case).

In addition, ARM architectures were a pain to deal with before, so most people emulated x86_64 and assume that you'd still have to do that on the M1. Nowadays, there is no reason not to run an ARM Linux in the VM. Most programs run just fine, and the remaining holdouts are a few Docker containers that haven't been updated. But even those aren't a problem because recent improvements to Docker greatly simplify running x86_64 containers under QEMU.

Combine all of this with the Mac app ecosystem (which has its problems, but is generally OK to use, especially if your other devices come from Apple), improved battery, the return of the good keyboard, and greatly lowered TDP, there really isn't a choice to make anymore.

The remaining reasons not to use it are basically as follows:

1) Compatibility with external devices, or work on embedded controllers

2) Anything requiring significant GPU compute (ML, etc.). But this would likely be done on a desktop rather than a laptop, which wasn't the scope of the question.

3) Disk capacity requirements (though external NVMe over thunderbolt mostly solves this)

4) Extremely multi-threaded work (video editing, etc.) where a desktop CPU outperforms the M1's multi-thread score.

Less pointless now?

Not anymore. Not on the M1s. They're far and away faster than anything but the beefiest desktop. A lua parser benchmark I ran in a VM on my M1 beat my 5950X by a factor of two.

The only remaining limitation are missing some ARM docker containers (which is slowly being solved) and the machines not being suitable for ML (in which case you need a desktop or to rent server time on the cloud).

Just run Linux in a VM! It's my preferred workflow nowadays.

See: https://github.com/mitchellh/nixos-config

https://www.youtube.com/watch?v=ubDMLoWz76U

Only real limitations are lack of ML because no server/desktop-grade GPU and some missing ARM-based docker containers. But the latter is slowly being resolved and the former isn't gonna happen on a laptop anyways.

That assumes a dichotomy of either: everything is allowed, or Twitter blocks things they want to block.

There are other forms of moderation that might be acceptable to people who are otherwise free speech absolutists. Crowd-sourced block lists (i.e. subscribe to a list of accounts marked by other users as spam), with the option to introduce your own exclusions to the list.

Alternatively, a web-of-trust model where you only see tweets & replies from people you follow. Or maybe the people you follow + the people they follow. Or maybe configure it on a per-person basis, if you trust person A's followee list more than person B's.

There are a ton of options. The point is that users don't currently have a choice, and have to deal with Twitter's policies with no opt-out or whitelisting.

That may be one of the effects of reducing moderation, but not necessarily the only one.

It may also reduce chilling effects on good actors. Some speech may be worth sharing but may not currently be shared because of those effects.

"Scrappy immigrant" whose father was a half-owner of an emerald mine in Zambia. I can't think of a more on-the-nose example of the evils of generational wealth.

Eh that's a bit of a different mechanism. If you bootstrap a platform from 0 users with the core concept being a lack of moderation, then you're likely to attract those who have been banned, excluded, or otherwise ostracized from existing platforms. This happens because those who support lack of moderation but still have a choice to remain are likely to remain on the existing platforms due to network effects.

Whereas if you start with the popular platform and progressively remove moderation, you end up with different effects, because you still have the core, non-bad-actor population. That is, if your signal-to-noise ratio goes down, but the absolute amount of interaction with your platform increases, it may still be worth it.

So just ask the other party to give you a salt they generate on the spot? And/or you do so on your end?

You can still get targeted for a direct attack but much less likely to end up caught in a dragnet approach.

He also has an excellent newsletter! For example: https://brandur.org/nanoglyphs/029-path-of-madness

Do you have a blog or a github or something? This sounds really neat.

Luddite but mixed with "Eliezer Yudkowsky" who is a researcher working on the problem of friendly AI (or whatever they're calling it these days). Basically trying to prevent skynet.

The GP is saying that once we have AGI, then "AGI is going to make the human race irrelevant" outweighs "AGI makes software devs irrelevant".

Correction: majority of people who didn’t spend their lives gaming get motion sickness pretty quickly anyways. This is coming from someone with an index running at 144 Hz on a 3090.

I’ve actively been encouraging friends and family to try it and my experience is that motion sickness hits about 18/20 people within 30 minutes of play, depending on the game.

However I’ve noticed that my friends who have played a lot of computer games (in particular fast paced FPS) tend to fare better, and also that the sickness goes away with practice. I used to get it too but now I can beatsaber for literal hours without discomfort.

The headset does make a difference, (my friend’s Vive was particularly bad), but it’s not as great as you suggest. Time and practice are far more important.

Seems similar to plug.dj

More general than just sharing music videos though.

If you got a reverse osmosis filter and thereby worked with neutral water as a starting point, would it be easier to achieve your target ratios? You wouldn't have to account for existing concentrations in the tap water.

Also, I was under the impression that there are two stages for plant growth: vegetation and fruiting. The two stages have different requirements for nutrients:

- high nitrogen, mid phosphorus, low potassium; and - low nitrogen, mid-high phosphorus, super high potassium

respectively. Do you use the same mixture for both stages?