bobtreehugger

joined 1 year ago
[–] bobtreehugger@awful.systems 8 points 7 months ago

Not to mention a lot of the first part is just honestly beautiful shots of nature, while showing the curve of the earth. There's very little that's dunking on flat-earthers. In fact, focusing on dunking on flat-earthers is something he criticizes other youtubers for in the video.

[–] bobtreehugger@awful.systems 14 points 1 year ago (1 children)

It's tough to debug issues when you can't run on the same hardware directly.

There's a reason that arm support in open source software has exploded in the past few years, and it's because of apple silicon.

I'll agree that it's easier now, with most developers using higher level runtimes, but someone's got to get those runtimes working, and it's much easier to develop if you have a laptop running that hardware.

[–] bobtreehugger@awful.systems 8 points 1 year ago

Why leave paradise?

 

They've done some really good reverse engineering on this project.

[–] bobtreehugger@awful.systems 7 points 1 year ago (4 children)

That line stuck out to me as well -- the law isn't some holy Grail of ethics, it's literally the bare minimum.

[–] bobtreehugger@awful.systems 8 points 1 year ago

Functions are fine, don't move to struct impls unless it makes sense (but do if the functions all take the same struct as a param).

You can go pretty far with modules and functions. Group related functions and move them to new modules. You can also hide functions that are only used inside one of the submodules by just not marking them as pub.

One thing that comes to mind is that if the steps of your algorithm all take and return the same data, you can have a trait that expresses that (possibly one of the Fn traits if you're going to just use functions), and you can define and rest each step separately.

It's hard to give more concrete advice without knowing more about your project

[–] bobtreehugger@awful.systems 2 points 1 year ago

Just FYI -- your test isn't going to run, you need to mark it with #[test].

So if you're used to a language like JS or python, or even Java, you're going to be a bit frustrated at how to mock things in rust. In those languages everything is boxed. In JS or python, because they're dynamically typed, you don't have to do anything special to mock, and in Java you can either play nice and use interfacees everywhere, or else you can do some runtime magic to mock an object of a regular class.

You can do something similar in rust -- e.g. you can have a trait Cat and a struct RealCat and a (or possibly many) struct FakeCat. (There are crates that will help you with this). Then you need to either accept a Box or a &dyn Cat, or make your code under test generic (which can infect the rest of your code if you aren't careful), something like fn uses_a_cat(cat: C) {}

So there's not quite as easy of an answer. You also have several more options, for example you can

pub struct FakeCat;

pub struct RealCat;

#[cfg(test)]
pub type Cat = FakeCat;

#[cfg(not(test))]
pub type Cat = RealCat;

and get a fake (or mock, or spy, whatever test double you'd like) in all test code in your same crate. This doesn't work well across crate boundaries though, and it only lets you provide one double, so it makes sense for that double to be very generic (there are crates to do this for you as well).

So there's not really a one-size-fits-all approach. You have to think about the tradeoffs.

However I think the best overall test strategy (and it doesn't always apply, but it should be preferred when it does), is the same one used for functional programming: just accept and return values. Pure functions don't need mocks, and even impure functions can easily be tested if they don't have other side effects that you need to prevent during tests. Obviously you still need to deal with side effects if your program is going to work, but if you have lots of pure unit tests that don't need any fancy test doubles you can do end-to-end testing for all of your I/O and other messy side effects. Which as I said, doesn't always apply (sometimes you really need test doubles), but it's good to use whenever possible.

[–] bobtreehugger@awful.systems 1 points 1 year ago

And this isn't even the expensive part -- training, this is just inference.

Can't wait for this fad to be over

[–] bobtreehugger@awful.systems 1 points 1 year ago

Bevy makes sense for my programming-damaged brain. I'm definitely not a gamedev, but I've been pretty productive when playing around with it. I'd also call out that it already has an ecosystem of plugins, with things like physics and tile engines, and you can use cargo, which is way better than using some weird storefront to get plugins.

[–] bobtreehugger@awful.systems 9 points 1 year ago (10 children)

This is an especially stupid prepper plan

  1. You're totally safe on a Pacific island, it's not like sea levels are going to rise.

  2. Genetic engineering is totally possible when the vast majority of humanity has been wiped out.

  3. What apocalypse scenario is solvable via genetic engineering? Maybe a super pandemic, but a vaccine is way easier.

The obsession with genetic engineering all comes back to eugenics

[–] bobtreehugger@awful.systems 5 points 1 year ago (1 children)
[–] bobtreehugger@awful.systems 4 points 1 year ago (1 children)

George W. Bush is another example of class privilege that people bring up. But whatever you think of his policies, winning the presidency twice is quite the accomplishment...

Charles II of Spain is another example of noble privilege that people bring up, but whatever you think of his reign, being that inbred and still living to 38 is quite the accomplishment.

view more: next ›