olodus

I agree, Journalists should pick fights, but I would prefer if they built up their arguments a bit better than this.

I am one who is not familiar with the author previously, and from what he brings up I am highly inclined to agree with him, but I have to agree I became more sceptical to his arguments when all he brings up to support it is one very sparing data point (that graph feels very misleading). Give me data on how the kernel support has changed over time. Give me data on how the foundations income has changed over time. Not showing me any of this makes me very sceptical. Would showing this data not support the authors point?

Oh cool, didn't know that. Thanks.

Oh wow that is a really interesting test solution. That would be an interesting thing to add to all zig tests (I know they already have the testing allocator and good valgrind support but I don't think that tests/simulates oom).

I love things like these that use existing tests and expand the to just test further thing in already covered flows. We have done similar things at my work where we test expansion of data models against old models to check that we cover upgrade scenarios.

Yeah I agree with you on this. This might have been the CEO too proud to not go back on his strong words against revenue share. That said the alternative they presented is a really stupid alternative. I don't think anyone has argued that Unity shouldn't be able to make money or increase their fees if necessary, but they should have followed their word on "stay on the terms you signed up to" and not do such a crazy version of fee increase as they did (install fee is a really stupid metric and that the install fee didn't have a roof was really bad).

I agree with the article that it might be misleading to measure the rubble against US Dollar or Euro as not as much trade is done in those currencies in Russia currently. That said, if you measure the rubble against the ruppie or yuan instead, for example, the rubble has also weakened quite a bit. Weird that the article doesn't do that comparison... Strange...

Oh, now you got me started aswell. There are so many good ones.

k.ong - cool word, don't know what it would be for. Maybe the home of the mascot of the K language (I don't think K has a mascot from what I know but they should have one).

whats.wr.ong - find a therapist site.

Much harder to figure out any on '.ngo' I feel...

Was about to ask the same question (though didn't know when he died).

Ok then, I'll get back to these when we finally have been able to convince the government that the current copyright length is obscene or when they have entered public commons - whichever is earlier (don't make me bring the mood down by suggesting which one I think will come first).

Last time I looked at it they had experimental support for binary diffs (not just lines). That was quite a while ago though, they have probably gotten further now.

People might feel like it is too verbose, but I think it is good to have the clarity. I write C at my day job and I have no problem with the 'verbosity' if it provides clarity of what happens. What I want is the compiler to help if I ever forget who owns a particular data value and miss to clean it up. For that linear types are perfect. I also prefer their simpleness over Rust's affine types which easily gets very complicated (see the difference between theirs and your borrow checker). Linear types gives me an easy way to define basic "state machines" for how to handle the data using types and then verifies that I implemented them correctly. That is kinda all I need. Feels like a good "get shit done" language.

I disagree with you about 'no type inference'. I understand why some swear by type inference, but personally I prefer the complete clarity it provides to avoid it. If writing those characters annoys you, have tooling help you with avoiding that.

Yes, the compiler will remind you if you haven't cleaned up a value of linear type.

The 'no destructor' rule follows the 'no hidden flow' design, similar to Zig. Some doesn't like it, but personally I prefer it.

Sorry for my ignorance, but are any of these anti cheat drivers open source? I get that making them public would simplify for a cheater wanting to find ways around it (or a malicious actor to exploit them), but it would also go a long way towards users feeling sure of the fact that the driver isn't violating their privacy in other ways than necessary for detecting cheats during a game. Furthermore, if they are so much single-focus as the article argues then it should be easier for the companies the secure that what they open sourced is safe and can't be exploited.

Oh how nice, we Europeans get the non-beta version without those pesky privacy bugs :)

I am a total obfuscation noob. How far does their DPI go? I am guessing Tor and stuff have tried hiding it inside lots of different protocols and file types (I think I read something about that at some point). Is it to the point of hiding it as part of a html doc (like under a specific tag or something). At what point do we move towards having executable Javascript generate the encrypted text which then is decrypted?

I am someone who loves learning new languages (written advent of code in lisp, Haskell, APL, Erlang, zig...).

I have thought for a long time to try out Raku as Ive never tried Perl and it feels like the modern version might be easier to get into as it maybe avoids some of the baggage.

Is this true, or do I miss something by skipping the original?