spacesuitman2

>Rather, it only checks for method names and where-clauses such as T: Trait. Types are only resolved in the confirm phase, at which point rustc would have already picked its method.

Not following here, the compiler iterates over the deref-chain and acquires a list of method names, but it also "checks for ... where-clauses", what does that mean? A quick look at the linked probe code indicates what we filter on Self traits and return value traits.

>I see words like “flakes” and “derivations,” and I currently don’t know what they mean.

>So far, I don’t get how it’s deterministic.

To make nix deterministic you can specify a hash in non-flakes (or a git rev) for your dependencies, but flakes make this easier. When you "run" a flake (be it nix build, nix shell, nix develop), nix pulls the latest (if no explicit rev given in the flake.nix already) version of whatever is specified in flake.nix that it can find, and creates a `flake.lock` file that specifies the exact version that was used. This file is very similar to cargo's Cargo.lock, and specifies the exact version that was captured by ref/hash. The next time nix is "run", it uses the lock file to get the exact same version as it had previously.

One can develop a flake.nix locally, install, check if everything works, and alternatively change the refs in the lock file to make everything work. When this is done you can move the nix and lock file to another machine and get the same exact build there (with the exception of architecture differences).

Because you can put flake.nix and flake.lock inside of git, you can also share the exact same dependencies with other people using a repository. Whenever I see a repository using these I know that building will be a breeze because I don't have to do any dependency hunting.

I think he means that employees/contributors exist on both the Russian and Ukrainian side.

>I don't have any particular answers to why string templating has been enduringly popular so far (although I can come up with theories, including that string templating is naturally reusable to other contexts, such as plain text).

This sounds similar to the concept of narrow waists: https://news.ycombinator.com/item?id=30483914

Based and redpilled.

Perhaps it's the same advantage of living in a society like ants or humans. By keeping each other alive we stand stronger against other forces of nature and/or other species of trees or plants.

Been using it since a few months, mainly because it can stop autoplaying all audio/video and no login nagging.

Moderators, I'm attempting to flag this post, but I do not see the flag on this post's page.

Which European countries?

That's equally as bad for the consumer.

For all my searches so far, ripgrep is about 30-100x faster. Perhaps you're on some hardware which ripgrep isn't well suited for.

Have they removed that repo yet that sends base64 IMEI, SIMID,... to zzhc.vnet.cn?

>I have not yet seen a compelling argument for Racket there vs. for instance a parser generator framework.

Racket allows for easy interop between the various languages, so for instance, you can use typed racket from untyped modules. You can import documentation modules in base racket and so on.

With other languages, you have to glue the infrastructure yourself, racket does it for you.

Thank you very much.

Not everyone vapes with nicotine though.

A consistent observation has been that all config languages tend to become turing complete over time.

It's not wasted at all - people are learning and configuring, tweaking and optimizing their use of a computer. I for one really like the fact that Manjaro is an easy Arch for me. Is it wasted creativity now that I can focus on non-distro work since I found my distro?

Besides, who is the author to tell people to not waste creativity. It's remarkable to have this audacity. Even the notion of "wasted" creativity is just not nuanced.

How does this work with allowed website iframes?

If only everyone would just put it in the `.config` dir and be done with it. Predictable. Simple. And without shrapnel in home.

Don't remember to backup. I've had multiple drives fail (within 6 months!), luckily I always have at least 2 copies of my data.

>The secret to staying slim is to not eat more calories than your body uses

This. There are too many people who do not understand that conservation of mass applies to the human body too. Nobody gains 1 kg by eating a single peanut, yet some people claim it's all genes.

This. People hark on 4chan for being bad but to be honest the non-popular boards are remarkably echo-chamber free. People get called out instantly and it's refreshing.

Then why not make two sites?

management.rust-lang.org and rust-lang.org

What an incredibly annoying website, popups, auto-playing videos, loaders that cause the page to bob up and down for a good 5 seconds. Yuck.

What's your version? I'm on 8.2

However undesirable it appears at first, it does prevent the creation of an infinite number of new, incompatible languages. Config languages tend toward turing completeness and just become turing tarpits. That's why I'm asking about using a Lisp which is extendable to its problem domain.

Source on gdb disabling it? Just writing `gr` in gdb enters the guile repl.

Why the need for another new language? Why not just use Guile or Scheme instead?

Because racket has hygienic macros and #lang, and syntax-parse.

I have to agree on you regarding OS threads, although there are places, but they're processes. For long names, most names have an abbreviation like call-with-current-continuation has call/cc, and in any case, you can make your own abbreviation using make-rename-transformer so this shouldn't be an issue

Racket is unlike many other programming languages, firstly it's a lisp. Secondly, it features a builtin language framework that allows you to seamlessly interop different languages through racket. Once you learn racket you realize that most other languages are just macros in racket, or a #lang in racket, and that their unique implementations are mostly quite wasteful, as they make interop hard.