dataangel

I doubt it with a copy-and-patch JIT, not the way they work now. I'm a serious mypy/python-static-types user and as is they currently wouldn't allow you to do much optimization wise.

- All integers are still big integers

- Use of the typing opt-out 'Any' is very common

- All functions/methods can still be overwritten at runtime

- Fields can still be added and removed from objects at runtime

The combination basically makes it mandatory to not use native arithmetic, allocate everything on the heap, and need multiple levels of indirection for looking up any variable/field/function. CPU perf nightmare. You need a real optimizing JIT to track when integers are in a narrow range and things aren't getting redefined at runtime.

> keep counters of how often each block of code runs ... and then any block of code running more than a few thousand times run through a far more complex yet slower optimizing jit.

That's just all JITs. Sometimes its counters for going from interpreter -> JIT rather than levels of JITs, but this idea is as old as JITs.

> the hype currently is for typed or gradually typed languages

So Python with mypy

> (this feature was cool in the 90s, but dreaded since at least 2010)

LOL this is a dead giveaway you haven't been around long. There have been people kvetching about the whitespace since the beginning. Haskell went on to be the next big thing for reddit/HN/etc for years and it also uses whitespace.

Doesn't change parent's point, clearly proves it's possible

The founder's academic work is literally on using games to get people to generate training data for AIs. I watched his lecture on this in ~2007.

Is there any copyright issue with the community editing and republishing as described in the README?

Assuming I did proofs in highschool algebra and geometry courses, is there any tutorial that would make lean4 accessible? I think computer assisted theorem proving could be great educationally, but this post would be complete gobligook to most students despite the title.

TL;DR

- Julia nice for prototyping

- but zero speed up from using GPU

- sometimes faster sometimes slower on CPU

- no plans to use at the moment

Unless you care about packages from lang package managers like pip...

Slows down your gut motility, can't wait for the epidemic of new SIBO/IBS cases.

I find this research to be both ethical and necessary, and I think kernel devs decrying it as wasting their time are missing the point. They demonstrated the whole "with enough eyes all bugs are shallow" security model doesn't really work. If some of the best devs out there fall for bad patches, it can happen to any OSS project (and for that matter for prop code bases too, but there you at least have to go through the hurdle of being hired before your code is considered).

It's very sus but $1M isn't a huge profit by trading standards. If they knew what was coming why didn't they bet more?

globs don't even prevent you from special casing one file to have different flags

Globbing is how you avoid pointless busy work. If there's a file in the directory that shouldn't be built, it shouldn't be there.

> glibc could introduce arbitrary delays, but it generally doesn't.

Yeah it does, that's why gamedevs and hfts don't use any malloc in the fast path, glibc or otherwise.

For the uninitiated what are wild about D lambdas? I'm familiar with C++ lambdas and Python lambdas.

ccache pretty aggressively scans for things like __DATE__ and has direct understanding of compiler flags so instances of bad caching are pretty rare, I think I've only had it happen twice in years of use and once was a GCC bug. Also since ccache supports s3 out of the box now remote caching is pretty fast to setup. Remote compilation is not handled by ccache at all. You need distcc or icecc for that.

Does it still have the issue where it can't be shared between users on different hosts unless they all store their source code at the same path?

It's actually the protobuf design mistake that most adversely affects decoding performance. The original creator who went on to make Cap'N Proto makes the excellent point that it's better to leave the extra bytes and then just slap a compressor that only works on runs of 0 bytes on top. Faster for the same savings. There are also newer schemes from Daniel Lemire and others more amenable to SIMD decoding.

Came here to say this. 100% is too good to be true and it's almost certainly the AI has figured out a signal leak from the camera, image format, room, etc.

Presumably there are open source apps you can install on top of AOSP that let you message and dial though?

That stuff is going to get smacked down by the federal SC hard

> Not so, unsafe code still has restrictions in Rust due to pointer provenance.

That's separate from what I'm referring to. In C++ a float* and an int* can never alias. In Rust f32* and u32* are allowed to. Meaning in a situation where whether they can alias can't be established by provenance (e.g. in a separately compiled function where the compiler at compilation time can't tell where the float and int came from) then C++ is able to use types to rule out aliasing, but Rust cannot.

> If you want to be pedantic -- in theory C++ can never be the fastest systems language possible because of the language's rules about aliasing.

True but the only practical competitor is Rust, and they gain some alias information (mut) and lose other aliasing information (type punning is fully allowed in unsafe code all the time).

You can do that in any C program today

It's not used by any of the major ones, so in practice lots of apps will be broken. I like musl, and I link it for my own stuff but I only have to make sure my stuff works. if I had to make sure everyone's existing stuff worked glibc is the only practical choice.

That is really how I meant it. Using Linux for almost 20 years I've found the most important part of having a working system is being on the beaten path. Distros that do too much exotic stuff spend all their time fruitlessly trying to keep up with porting and end up confined to a small user base of OS geekery enthusiasts.

yes exactly what I meant

So they're basically saying "our system will be better because more things will just work" but then they decided to use nonstandard libc and coreutils so actually getting existing Linux scripts and software to work in this distro will be harder.