Hacker News new | past | comments | ask | show | jobs | submit | LoganDark's comments login

Task failed successfully

> Probably because you know about computers. Nothing to do with your poor security practice.

IME knowing about computers is what causes auto-update to break things. Because you actually rely on the kind of things that it would break.


Oh, this is so sad... Cohost helped us immensely as a system, and it helped us find so many new friends, and we've felt bad for not checking on it recently, just to hear that they're shutting down. I'm actually really sad that this is happening. :(

-Emily


I prefer when the device itself is durable and easily repairable

Even if the device is durable and easily repairable it makes no sense to exercise those features. Those features are basically like insurance.

Presenting to the emergency room...

ShaderToy already has GPU ray tracers and the main problem is branching control flow. When you draw triangles you can give the same exact operations to a chunk of cores and GPUs are very good at that. When you ray trace, or at least when you path trace (multiple bounces per ray), each ray can go in any number of directions, and they diverge very quickly with any kind of reflection or diffusion.

I've had to do this with an electric scooter before. Sometimes the road sensors aren't tuned for very small things... probably because most cars aren't that small.


I always, always forget what `'a: 'b` means, because I remember it always being the opposite of what I think it is, but memorizing that obviously doesn't work because then it will just flip again the next time. It's so annoying.


I always describe it to myself this way - T: Foo means T is a superset of Foo (because it at least implements Foo but most likely more) thus 'a: 'b means 'a is at least as wide as 'b, and possibly wider


I had the same problem until I realized this: for generics and traits T: A means T implements A and it's actually the same with lifetimes: 'a: 'b means lifetime 'a implements lifetime 'b, which naturally translates to objects with lifetime 'a lives at least as long as 'b.


I am reminded of many instances over my life of:

1) Every time I go through a particular door I try to push it when it's a pull door.

2) I notice this and ensconce in my brain that it's the opposite of what I think it is.

3) After a while, my brain actually starts to remember it the correct way around to start with.

4) But my brain doesn't then drop the 'opposite' rule so now I remember it the correct way around, then invert it, thus recreating step 1.

I don't claim this says anything about rust, but I think it does say something about human brains (or at least mine and apparently yours).

My sympathies.


I don't identify human, but you're absolutely right. For me, this also happens with the direction of hot vs cold on faucets/showers. I can never ever understand. Sometimes they're relative to the top edge and sometimes to the bottom edge. Sometimes they are on the wall/sink and sometimes they are on the actual handle. Because everything is always completely impossible to define proper rules for, the only thing I can rely on is "it's different than you thought it was before" but relying on that also doesn't work!


If you think of it as 'a implements b', it makes sense for both lifetimes and (other) subtypes: If lifetime `a` implements `b`, it is obviously valid for `b` (and maybe longer).


I always do `<T, U extends T, V extends U>` etc for generics, but for lifetimes it's `<'a: 'b, 'b: 'c, 'c>` which always trips me up...


You have to first remember what lifetimes are there for in the first place: to indicate that values live at least a certain duration. That is what the type &'a means. Then it becomes clear what the relation 'a: 'b means


In lifetime, subtype means longer lifetime (it's unintuitive). 'a : 'b means 'a is a subtype of 'b, which contains 'b and can be longer.

Rust can improve this by introducing syntax like `'a contains 'b`


It was a good signal to me that you are overthinking into the architecture if that is really required. Rust makes something pretty much impossible in C/C++ possible, but not necessarily easy, and that would be one such example.


> It was a good signal to me that you are overthinking into the architecture if that is really required.

Sure, maybe I don't need to statically guarantee the correct execution of code that could easily just throw at runtime instead, but it sure is a fun hobby.


Lifetime subtyping is normally not much necessary to ensure the correctness, provided that you are working at the sufficiently high level (so, say, std is available) and do have some freedom in the design. It often indicates that you are excessively avoiding heap allocations.


You can't just allocate a Lua coroutine on the heap. Lua coroutines are managed by the Lua virtual machine. So that's one heap allocation "avoided". I don't remember the others off the top of my head but some functions needed to have three lifetimes for various reasons. Not sure if I eventually refactored that out or not, it's been a while. I should get back to it one day when my job isn't nothing but startup crunching


I'd guess tears of joy!


This is why I've always encouraged people to hack my games. Exploits that ruin other players' fun will obviously be moderated accordingly, but if they're just doing cool stuff, I don't want to ruin their fun!


offhand, gggg (4g) has this same outlook; and requests that people who cheat or hack the game merely disable stat reporting (leave the leaderboards alone if you want to cheat).

I should make a list of devs/studios that encourage hacking/cheating in their games. for example, Thomas Gervraud (Brotato creator) put sliders in the gameplay settings that let you set enemy speed, health, and damage stats (up and down!).

Anytime i load up wemod and a game isn't in the database, i fire up cheatengine (i donated, even) - and if that gives me a hard time, i usually request a refund on the game.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: