1.1.1.1 is simply a free DNS, 1.1.1.2 blocks malware, and 1.1.1.3 blocks both malware and adult content. It's a service that does exactly what it's supposed to do.

Simply removing the GIL and running 10,000 threads seems very unlikely.

I've been hacking professionally for 30 years and I know what to look for. Anthropic's report is garbage. Period.

Compared to what? What gives you all that, and what prevents you from having it with tables?

Javascript arrays have functions for all of that, so if you use something like React and renders your table from data arrays then it's all pretty trivial. I guess the point is that if you have to use JS to do those manipulations, then at some point it's going to be easier to just the React(/Vue/Svelte/etc) approach than manipulating the table yourself using the API described in the article.

Frameworks that make development easy are inherently inefficient. If performance is priority, then you better sort it yourself.

countless plugins for use in countless frameworks. We should have all that built-in by now. like we finally have a functioning date picker.

I'm pretty sure they're talking about reference counting that depends on the arguments, not about optional arguments or invalid argument combinations.

C and Python automatically concatenate string literals, and Rust has the concat! macro. There's no problem just writing it in a way that works correctly with any indentation. No need for weird-strings.

  " one\n"
  "  two\n"
  "   three\n"

Personally, I'd rather prefix with `\\` than have to postfix with `\n`. The `\\` is automatically prepended when I enter a newline in my editor after I start a multiline string, much like editors have done for C-style multiline comments for years.

Snippet from my shader compiler tests (the `\` vs `/` in the paths in params and output is intentional, when compiled it will generate escape errors so I'm prodded to make everything `/`):

    test "shader_root_gen" {
        const expected =
            \\// Generated file!
            \\
            \\pub const @"spriteszzz" = opaque {
            \\    pub const @"quadsprite" = @import("src\spriteszzz/quadsprite.glsl");
            \\};
            \\
            \\pub const @"sprites" = opaque {
            \\    pub const @"universalsprite" = @import("src\sprites/universalsprite.glsl");
            \\};
            \\
            \\pub const @"simpleshader" = @import("src/simpleshader.glsl");
            \\
        ;

        const cmdline =
            \\--prefix src -o testfile.zig src\spriteszzz/quadsprite.glsl src\sprites/universalsprite.glsl src/simpleshader.glsl
        ;

        var args_iter = std.mem.tokenizeScalar(u8, cmdline, ' ');
        const params = try Params.parseFromCmdLineArgs(&args_iter);

        var buffer: [expected.len * 2]u8 = undefined;
        var stream = std.io.fixedBufferStream(buffer[0..]);
        try generateSource(stream.writer().any(), params.input_files.items, params.prefix);
        const actual = stream.getWritten();

        try std.testing.expectEqualSlices(u8, expected, actual);
    }

They aren't comparing those crimes. You don't get to pick and choose where laws should matter based on whether you personally like the item being banned. Your "bad guys will do it anyway" argument doesn’t hold.

The point is obviously that the counter is centralized, and it relates to the previous example where is no concurrency. The need for synchronization when sharing data across threads is mentioned just below that.

In the right place, but maybe at the wrong time. You can expect +1 and always be right, when the value should be +10.

The __LINE__ macro, like all other macros, is expanded during the preprocessing of the source code and is not handed to the debugger in any way.

Yes... And debuggers that implement line numbers, generally work by taking that information as part of the preprocessing stage. And the #line and __LINE__ macro/directive were implemented _for debuggers_ when originally created. They were made to be handed over to the debugger.

If you simply compile and run, the debugger won't have __LINE__, no. But it also won't have line numbers, at all. So you might have missed a bit of context to this discussion - how are line numbers implemented in a debugger that does so, without access to the source?

No, the debugger does not get involved in preprocessing. When you write "a = __LINE__;", it expands to "a = 10;" (or whatever number) and is compiled, and the debugger has no knowledge of it. Debugging information, including the mapping of positions in the code to positions in the source, is generated by the compiler and embedded directly into the generated binary or an external file, from which the debugger reads it.

The __LINE__ macro is passed to the debugger only if the program itself outputs its value, and the "debugger" is a human reading that output :)