alexvitkov

std::ignore doesn't work in the context of structured bindings. And even if it did, "we already have this" has never stopped the C++ committee from adding something before :)

The issue is about "repetition" - a concept that exists on the syntactic level, and is unavoidable in Go.

To put it in a way you may understand, it's when you have to press keys in the same order a lot of times and you get sad.

Wild that the people who made the language that forces me to type

  if err != nil {
      return nil, err
  }

after every second statement are advising against code repetition.

"The Snitch-mobile"

Nope, this is as straight forward as it gets. There are only two ways not to know if you're failing or acing an interview:

1. You don't know what metrics you're being judged on.

2. You do know but you either can't assess your abilities in said metrics or you can't tell how well you've presented them.

The second one is up to the candidate, not much you can do about that, but if during an interview you have no idea what the interviewer is looking for, that's a terrible interview.

"We don't want you to know you've already failed so we can waste your time for a month in the off-chance nobody better shows up."

Compilers are one of the easiest and most fun pieces of software to test, because you can test very specific behavior without touching the internals at all.

E.g. if I want to test that `*` has higher precedence than `+`, I would write something like this:

    assert_ast_equals(parse_expr("(a*b)+c"), parse_expr("a*b+c"))
    assert_ast_equals(parse_expr("a+(b*c)"), parse_expr("a+b*c"))

You can rewrite the whole compiler if you want, but as long as you have some notion of a "parser", an "AST" and "two AST nodes being the same" this test will keep working.

This is much more powerful than going into the parser internals and comparing get_operator_precedence('+') with get_operator_precedence('*') which is the default thing you would do if you're told to test every function after writing it.

I'm not even going to read this, we all know what it is and we all know it's just the first step in a long series of very shitty changes, expect all new development to be in the "contact us" tier.

Ignorance was maybe excusable the first 15 times, but if you keep falling for corporate owned rug-pull OSS packages in 2024, you deserve what's coming for you.

Weird databases are NFTs for startup founders. You're not too cool for Postgres. Use it.

Flex and Bison are simple enough tools (probably, you never know with GNU stuff) that you should be able to just vendor & compile them as part of the build process if you actually care about reproducible builds.

If you by default treat every GitHub repo as quality production code unless explicitly mentioned otherwise, you're in for a bad time.

> Games that are good, are going to be popular

Games that pass a certain quality bar and were designed with mass appeal in mind are going to be popular.

I've played at least a few live-service games that I consider good, but were shutdown due to lack of popularity. Some of them I can't even find client files for to start working on a server.

Value is subjective - tons of games that are now considered cult classics didn't gain any meaningful popularity on release.

Recently I downloaded a semi-legitimate copy of Photoshop CS3 (from 2007-ish). It made me realize how little the software has changed in the past nearly 20 years, aside from the terrible performance regression.

I'm by no means a Photoshop power user, but the stuff I use (the primary tools, the blending options menu, Image/Adjustments menu, Filters menu) are almost 1:1 feature-wise with the latest CC version.

I haven't tried to open .PSD files from a newer Photoshop, I don't know what the compatibility story is. I haven't ran it on my Linux box either, but I assume it will be easier to get it running than CC 2024.

If you control the font, you control the content as well, I don't see the attack vector.

80/20 rule.

The dumbest possible type inference algorithm...

    let x = value; // typeof(x) is now typeof(value)

... covers 80% of the cases where you'd like type inference. I'd even argue it's way more than 80%.

Surprisingly, this is what C++ actually went for, and `auto` works just fine. Same in TypeScript - make a best effort guess from the value, fallback to `any` no value or type is given.

Having to write out a type every now and then costs me way less time than waiting for the compiler to finish playing minimax against itself in the latent space of all possible programs or whatever.

I apologize - when people mention "memory safe" nowadays 95% of the time they're talking about Rust, I made an assumption.

Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck.

The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler.

Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/d...

Real life castles were designed to withstand a siege, video game castles are designed to give off a castle vibe. Once you've achieved that you stop adding stuff, as anything beyond that just creates problems - you start killing performance, visibility starts to suffer, it's not clear what's interactive and what is decoration, gameplay starts to take a hit as the AI and player start getting stuck in the clutter, etc, etc...

Most people don't care as they don't have deep knowledge of how a castle or a power plant really functions, you only notice oversimplifications in media in the field you work in.

It's also very likely the designers and artists didn't have time to do much research, and the whole thing is based off a Pinterest reference board.

Because rust is a cargo cult. We're nearing 10 years since 1.0 and there's still not a single serious, widely used, large software project to prove its viability. Maybe make one instead of trying to passive aggressively convince others to do it for you?

From LGLP-3.0:

    d) Do one of the following:

        0) Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
        1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

IANAL, this is just my interpretation.

- There's no way to comply with this when developing for a closed platform - e.g. iOS or any video game console.

- There's no way to comply with this if you need to sign your code for whatever reason.

- It's very difficult to comply with this if you have to ship a single binary and cannot dynamically link - e.g. Android with an .apk package.

The "Big Tech used my stuff and now I'm sad" story has happened so many times that it is ridiculous. You should be aware of this possibility before releasing your stuff under a permissive license. And the proposed alternative is often copyleft, which doesn't make you any money and dissuades people from using your project. You need to understand these implications before jumping in.

> your position is ridiculous by only believing that humans are incapable of cooperation without having something to gain from it

I do believe that. They're always a motivation to gain something, even if it's the pride that you've helped financially support a project you believe in.

My worldview is irrelevant though, the issue here is corporate structure, not human nature. It's difficult to convince a company to pay for something that is free, especially when the button says "Donate" and not "Buy". And even if you do, for a high-value FOSS component, the amount paid will never reflect the actual value they gained from it - think YouTube and ffmpeg, Apple and FreeBSD, or any SaaS and Linux.

From https://www.gnu.org/licenses/license-recommendations.html:

> If the version you've created is considerably more useful than the original, then it's worth copylefting your work, for all the same reasons we normally recommend copyleft.

Wouldn't you consider this advice disrespectful to the original authors as well? The FSF is directly telling you to take the existing project, not even your own re-implementation, and take over and GPL it.

Those licenses are all a joke. If I need a library like libcurl for a commercial application, then GPL, AGPL, EUPL and even LGPL are non-starter. MPL-style licenses are fine, but it doesn't really make you any money, it just forces me to publish my patchset for the library (except not really [1])

The solution really is to use a serious license. Add a "if you make more than $X you owe us $Y" clause. Or use a Qt-style dual-license, where your users can buy their way out of the GPL, this way you can keep the moral high ground of using a "FSF-approved license". But putting yourself in a position where your work can be easily exploited and then complaining when it is is ridiculous.

[1] MPL works on a per-file basis. Technically I can extend it the library with a new file that contains no MPL code and won't have to release it. The LGPL has protections against this, is worse in other ways.

If you want billion dollar corporations to pay you then you should probably include a clause "this is free unless you're a billion dollar corporation in which case you have to pay me" in the license.

Ah but then it's not free software and the FSF will frown at you, because billion dollar corporations are people too. Tough luck.

A full memory dump for a game will nowadays often be multiple gigabytes, that's a non-starter.

Even back in the day, Game Maker had a function to dump the state to disk that was intended for game saves. It sucked - turns out there's a bunch of state that you don't want in your savefile - keybinds, settings, even most game state actually.

Save state should be opt-in, not opt-out, and on top of that a VM/memory dump makes it a very big pain to opt-out.

Thanks for the write-up. My biggest fear is not references, overloads or memory management, but rather just the layout of their structures.

We have this:

    sizeof(String) == 24
    sizeof(Option<String>) == 24

Which is cool. But Option<T> is defined like this:

    enum Option<T> {
       Some(T),
       None,
    }

I didn't find any "template specialization" tricks that you would see in C++, as far as I can see the compiler figures out some trick to squeeze Option<String> into 24 bytes. Whatever those tricks are, unless rustc has an option to export the layout of a type, you will need to implement yourself.

If you want to interop well with Rust code, it feels to me like your language has to inherit so many Rust semantics, that I'm questioning myself why I would use it over Rust.

If you're making a new language, just have good interop with C. Most libraries worth using are written in C. Calling into C is trivial* and enforces almost no limitations on what you can do language-design wise.

* trivial, with the somewhat sizable asterisk that you have to rewrite the header files in your language.

Everyone understands a queen is worth more than a pawn. Even if you don't know the exact value of one piece relative to another, the rough estimate "a queen is worth five to ten pawns" is a lot better than not assigning value at all. I highly doubt even 20 year old chess engines or beginner projects value a queen and pawn the same.

After that, just adding up the material on both sides, without taking into account the position of the pieces at all, is a heuristic that will correctly predict the winning player on the vast majority of all possible board positions.

Still, the fact that there are obvious heuristics makes that function easier to train and and makes it presumably not need an absurd number of weights.

The daily Sidebar break!

https://news.ycombinator.com/item?id=40633667

https://news.ycombinator.com/item?id=40644940

https://news.ycombinator.com/item?id=40650811

https://news.ycombinator.com/item?id=40662499

I don't mind the shit take, but please don't use underscores in your domains.

> Any non-trivial engineering or research is a team effort

There's plenty of counterexamples in the software space, to the point where most great software was originally written by a single person - C, Unix, Linux, Git, TeX, Python, Ruby, Perl, SQLite, QEMU...

Most of these now have huge teams maintaining them of course, but the initial research and engineering that was needed to come up with the golden egg is usually a one man show. C designed by committee is COBOL.