earenndil

That's not exactly the same. What you're referring to is the library ABI for the c++ standard library. Every library which can be linked to dynamically has its own ABI. The language ABI, on the other hand, describes how every library's ABI is defined, describing things like layout and name mangling. So if, for instance, the language ABI were amended to say that class members are arranged in alphabetical order in memory, then capacity_ will always be at offset 0, data_ at offset 8, and len_ at offset 16; if you change the order of declarations then, the library's ABI won't change. But if the library were compiled with an old compiler that targeted the old ABI, then it would put data_ first, followed by len_, then capacity_. So if you then compiled a new piece of code with a new compiler targeting the new ABI, but linked against it the library, there would be a mismatch.

You can use shmem instead of sockets, which is pretty fast. Not as fast as a direct call, but pretty good; good enough for most purposes.

Maybe. Java is quite fast, but for very different reasons than APL; I don't think it would transfer that easily. Part of the reason APLs are so fast is because the interpreter and all the code fit in cache; my copy of k is 76kb. I don't think there's a chance you could get that with the jvm. APL also relies heavily on SIMD, and I don't know how well-supported that is on the JVM.

> And have it run at the speed of c

Unlikely; clojure runs on the jvm (or on top of js), and interop with c is slow.

Hence 'when errors are rare'.

Probably go or d.

> Another thing is difference in handling invalid code. A traditional compiler front-end is usually organized as a progression of phases, where each phase takes an unstructured input, checks the input for validity, and, if it is indeed valid, adds more structure on top.

Is this true? The way the d compiler does it is to make a special ast node type called 'error', which allows it to avoid this problem. I have also gotten error messages from c compilers that indicated they were doing something similar.

Now, in the d compiler, this is not a panacea, because erroneous code can cause erroneous error messages about unreachable code, but it generally works quite well.

I don't believe it's common to embed application scripting code within c source files, no.

They let you upload matrix data to the gpu, but all functions like glUniformMatrix4fv() really do is upload a 16-vector into gpu memory (and optionally reshuffle its layout). The shading languages also have matrix primitives, that's just sugar.

Solution: make the portions of a company that deal with/offer E2EE and those that don't separate entities.

The bits that are E2EE don't need immunity because they don't make CSAM available online. The other bits get immunity because they don't do E2EE, which is fine, because that's the way it currently is.

I really don't see the point of this.

Cyclone was definitely there. Sadly no longer maintained, and not at all practical to get working on modern systems (I did some work on it, then gave up).

It's unclear that you really need to convert to matrices before sending off to the GPU. [1] finds that quaternions are faster; I find that questionable (does it scale?), but it shows that the two are comparable.

1: https://tech.metail.com/performance-quaternions-gpu/

GPUs don't have dedicated matrix hardware anymore, making it questionable whether you really need to convert your GA structures to matrices first. [1] finds that quaternions are faster than matrices on modern hardware; I find that questionable, but it at least shows that they are comparable.

1: https://tech.metail.com/performance-quaternions-gpu/

A borrow checker is currently in development for d, and pattern matching has been pseudo-implemented with metaprogramming.

Maybe. I think that's less likely than syntax error, for two reasons.

#1, if you look in index.php, there's a < on line 228 and a > on line 258, correctly rendered. Granted, the < is part of a <=, which weakens that argument.

#2, if you look at the surrounding code, $user > 0 makes logical sense given what the code is doing (and assuming 0 represents an invalid/nonexistent userid, which I believe it does given that facebook userids increase monotonically).

> There is also a bit of schizophrenia going on, with the "new" ideas and the "old" ideas clashing in some places. For example, they claim that you can run D without a GC (the new), but apparently a good chunk of the stdlib requires the GC (the old), so you're stuck.

AFAIK this is somewhat intentional; they don't want to make any hard compatibility breaks, so there's a long deprecation period for any 'old' idea. There's also a lack of manpower to renovate libraries; e.g. there's no good xml library.

Regarding GC, it's IMO not a huge problem. The GC is really not a problem for most applications, and for those where it is, you can simply avoid GC allocations in inner loops (GC only runs when you allocate from it).

For a fuller analysis of this, see 'Jeff Bezos, Jack Ma, and the Quest to Kill eBay' - https://medium.com/s/story/jeff-bezos-jack-ma-and-the-quest-...

Game code doesn't need player interaction either to hotreload. See this section of a talk by Bret Victor for some inspiration: https://www.youtube.com/watch?v=PUv66718DII&t=10m42s

Consider two websites: website A and website B. Website A places no limitations on passwords except that they all have to be from the base64 character set, and be 1-30 characters in length (inclusive). Website B says all passwords must be at least 8-30 characters long and contain one number and one special character.

Technically, there are 1556820866911379157697368408533647424628560378091278400 possibilities for a given password from the first site, and only 1553740989173808677121103544993503115087947728215015424 for the second site. That's only 0.2% fewer total passwords. However, consider that the typical user's password is probably 6-8 characters and contains only lowercase letters; that means that most users from the first website have only 217167790528 possibilities, while users from the second website--even assuming they only go the bare minimum of 6 lowercase characters + one special character + one number--have 345985669120 password possibilities, which is about 60% more. And that's with the artificial base64 limitation; if you open it up to the full complement of 30 special characters it's significantly more.

To be fair, reddit was originally a usenet clone.

All array languages (apl and its derivatives).

Raku (perl6).

Maybe back then, but nowadays I'm pretty sure java is a lot faster than tcl.

I thought whatsapp was erlang?

Won't the screen-framebuffer be on gpu? Also, virtual memory shouldn't really matter.

Anyway:

    $ ps aux|egrep -i '(xorg|fvwm)'|awk -c '{print $2}'|xargs sudo pmap -x|grep 'total kB'
    total kB          808332  124808   86204
    total kB           64920   15724    2984
    total kB           61656   14428    2400

...huh?

My window manager is currently taking about 65K of RAM, and X is using ~800K.

Granted, I run a pretty lightweight setup, but a 'normal' ship can't be 4 orders of magnitude higher, can it?

You can use exfat and it will fit.

Is giving away that much of your privacy really worth $20/year? That's 0.02% of a regular software development salary. Two hours of work at minimum wage.

DXVK is not intended to be merged into wine. It's written in c++, and prioritizes usability over accuracy.

I highly recommend looking for a bowl-shaped keyboard as the second priority after split. Kinesis advantage is popular, and similarly priced to the keyboard.io. There are also maltrons, if you're willing to shell out a little extra dough. There was also a project to make a bowl-shaped split keyboard you could 3d-print at home. I can't remember the name.

I was also very excited about the moonrim, a project that portended to go a step further and change the hands' orientation, so they would face inward instead of down. Sadly, it ended up not taking off.

Agreed. SDL2 is one of the few libraries I've used that I can honestly say is well-designed.