Lvl999Noob

Wouldn't you face the same problem as Dotnet on Windows? AFAIK, dotnet based frameworks and apps suffered from huge performance issues. It might have improved in recent times, I am not actually a windows dev.

If just the end user application is in Lua, then maybe it's fine and the high level language slowdown won't matter. If you want to wrap the low level kernel APIs etc in a high level language as the canonical interface, I would be very skeptical.

I noticed a major problem. If I just keep writing in a single paragraph, the lines don't disappear. I was expecting it to automatically start fading the text once it reached 3-4 lines. As it is, I am afraid of adding new paragraphs because then I would 'lose' what I already wrote.

Edit: adding, it's also surprisingly... slow? I noticed some lag as I moved my mouse around. I don't know if it's because of the website or my browser (firefox) or my OS (Ubuntu) but I don't believe there's any reason for lag here so something should be fixed.

My autocorrect also didn't work. I did get the red squiggles on a misspelling but no suggestions on right click. Again, not sure if it's something wrong with the website or something with my setup (it works fine on other sites).

I am not too into windows dev but I am currently using msvc at work. We are told to import a config file into the installer and it automatically selects all of the components any of our projects will need. Wouldn't that solve the problem too? Just distribute a project level config file and add documentation for how to import and install the stuff.

Are you saying you want foo and bar to completely overlap? And baz and foo / bar to partially overlap? And have lots of unused bits in there too?

My internet providers (both home wifi and cellular) do this. The problem with unlimited slow speed is that it's too slow. I am sometimes unable to open the carrier's own app and pay for a recharge. Either the app just doesn't open or the transaction in the payments app fails.

The dock and monitors aren't mine actually. I got them from work. The work laptop runs windows 11 so the hardware is only tested for windows. I will buy my own stuff when I have to return these and then I will make sure it all works with linux.

What distro / wm / de is good with external monitors, in your opinion? After going through some of the comments on some threads, it feels like external displays are a common pain point across all linux systems.

I recently switched to linux from windows. The only reason I was sticking with windows was because hoyoverse refuses to support linux. I finally decided I need some break from them anyways and took the plunge.

First, I tried to install fedora atomic cosmic. It kind of worked but I could not get it to work with my dock + external monitors at all. Now that I am used to that setup, I can't go back.

Not wanting to spend time figuring it out, I just installed Ubuntu instead. Thankfully, that worked out though it's not perfect. Everytime I turn on my laptop, I need to spend 10-15 minutes turning the monitors on and off until ubuntu recognises them correctly and also sends dp output (it shows the monitor in settings and I can open windows on it but the monitor doesn't actually show anything; other times, it reads the monitor as something nvidia with the lowest resolution).

I tried to install genshin anyways on ubuntu. I couldn't get it to work via wine/lutris. Virtualbox doesn't support gpu passthrough so I tried using virt-manager. The setup was too hard and it didn't work anyways. I gave up on hoyo at this point and install steam instead.

Honestly, ubuntu is rough and Linux as a whole is very rough. But on the whole, I would still pick this over dealing with windows any longer.

Yeah. Certainly felt like that. On the other hand, the content does seem good. It definitely wasn't slop, even if I can't judge how useful it really was (in terms of giving a solution).

You don't. Assertions are assumptions. You don't explicitly write recovery paths for individual assumptions being wrong. Even if you wanted to, you probably wouldn't have a sensible recovery in the general case (what will you do when the enum that had 3 options suddenly comes in with a value 1000?).

I don't think any C programmer (where assert() is just debug_assert!() and there is no assert!()) is writing code like:

    assert(arr_len > 5);
    if (arr_len <= 5) {
        // do something
    }

They just assume that the assertion holds and hope that some thing would crash later and provide info for debugging if it didn't.

My 2c.

The risk of losing one (or both) earbud is a real one. My ears don't tend to keep snug grip on the earbuds so they tend to get loose after I walk a little. With earbuds, this might just be my own singular piece but, there is also the chance that only one of the two would connect to your phone.

On the other hand, the cables get tangled together. I can't walk around with them because the cable gets stuck in the swing of my arms. Connecting them to the phone after a call had already started was a piece of cake though. With bluetooth, I never have my earbuds on when I actually need them and it's too much of a pain to take them out of my bag and connect them.

Whenever it is time to replace my current earbuds, I am gonna go for a neckband instead. It has basically the best of both, imo (I am not that sensitive to audio quality mostly) and the downsides aren't large enough (I'll think of the weight as a neck workout).

Since the human eye is most sensitive to green, it will find errors in the green channel much easier than the others. This is why you need _more_ green data.

You are building everything in CI from scratch so theoretically, it should be completely possible to not need to scan lockfiles and get all the data from their respective sources (OS, runtime, dynamic libs, static deps, codegen tools, build time deps, etc)

Couldn't the compiler optimise this still? Make two versions of the function, one with constant folding and one without. Then at runtime, check the value of the parameter and call the corresponding version.

Personally, I would prefer that the package managers keep their own lockfiles with all their metadata. A CI process (using the package managers itself) can create the SBOM for every commit in a standardized environment. We get all the same benefits without losing anything (the package managers can keep their own formats and metadata and remove anything unneeded for the SBOM from it).

This isn't really something the logging library can do. If the language provides a string interpolation mechanism then that mechanism is what the programmers will reach for first. And the library cannot know that interpolation happened because the language creates the final string before passing it in.

If you want the builtin interpolation to become a noop in the face runtime log disabling then the logging library has to be a builtin too.

I use firefox for three things.

1. The ad blocker. 2. The sense of superiority over the normies (because of the ad blocker) 3. Theming

If adblockers are killed, that removed points 1 and 2. I am pretty sure I can do the same theming in Chrome (I have simple tastes) so that makes 3 a non-factor. And combined with the companies that refuse to make their sites work with firefox, there is no reason not to use chrome. Privacy is a non-factor since my identity is already wholly linked to my google account. I would have to first switch off off there and I am not putting in the effort for that.

I am not the author haha. Just someone who found and really liked that library.

And for the opposite, where you keep your main pipeline in shell but want to use python for some parts of it, there is pypyp.

https://pypi.org/project/pypyp/

It takes cares of the input and output boilerplate so you can focus on the actual code that you wanted python for.

    > seq 1 5 | pyp 'sum(map(int, lines))'
    > ls | pyp 'Path(x).suffix'

The various projects that say something is deprecated but then don't give a removal timeline or keep delaying the removal (or even explicitly say it won't be removed, just remain deprecated) are the cause of this problem.

IMO, any deprecation should go in the following steps:

1. Decide that you want to deprecate the thing. This also includes steps on how to migrate away from the thing, what to use instead, and how to keep the existing behaviour if needed. This step would also decide on the overall timeline, starting with the decision and ending with the removal.

2. Make the code give out big warnings for the deprecation. If there's a standard build system, it should have support for deprecation warnings.

3. Break the build in an easy to fix way. If there is too much red tape to take one of the recommended steps, the old API is still there, just under a `deprecated` flag or path. Importantly, this means that at this step, 'fixing' the build doesn't require any change in dependencies or (big) change in code. This should be a one line change to make it work.

4. Remove the deprecated thing. This step is NOT optional! Actually remove it. Keep it part of your compiler / library / etc in a way to give an error but still delete it. Fixing the build now requires some custom code or extra dependency. It is no longer a trivial fix (as trivial as the previous step at least).

Honestly, the build system should provide the tools for this. Being able to say that some item is deprecated and should warn or it is deprecated and should only be accessible if a flag is set or it is removed and the error message should say "function foo() was removed in v1.4.5. Refer to the following link:..." instead of just "function foo() not found"

If the build system has the option to treat warnings as errors, it should also have the option to ignore specific warnings from being treated as such (so that package updates can still happen while CI keeps getting the warning). The warning itself shouldn't be ignored.

Why not use apt?

Rust's design eliminates data races completely. It also makes it much easier to write thread safe code from the start. Race conditions are possible but generally less of a thing compared to C++ (at least that's what I think).

Nothing is preventing you from writing correct C++ code. Rust is strictly less powerful (in terms of possible programs) than C++. The problem with C++ is that the easiest way to do anything is often the wrong way to do it. You might not even realize you are sharing a variable across threads and that it needs to be atomic.

Why not have a transient client generated ID for idempotency but a server generated ID for long term reference and storage?

Never use someone else's synthetic key as your primary key. If you want ordered keys, even if the API is giving out sequential integers, you should still use your own sequential IDs.

Off-topic, For this kind of pointer casting, shouldn't you be using a union? I believe this is undefined behaviour, as written.

Pure js without typescript also has "types". Typescript doesn't give you nominal types either. It's only structural. So when you say that you "know it's already been processed", you just have a mental type of "Parsed" vs "Raw". With a type system, it's like you have a partner dedicated to tracking that. But without that, it doesn't mean you aren't doing any parsing or type tracking of your own.

Why does "true" parsing have to error out on the very first problem? It is more than possible (though maybe not easy) to keep parsing and collecting errors as they appear. Zod, as the given example in the post, does it.

The difference, in my opinion, is that you received the cli args in the form

``` some_cli <some args> --some-option --no-some-option ```

Before parsing, the argument array contains both the flags to enable and disable the option. Validation would either throw an error or accept it as either enabled or disabled. But importantly, it wouldn't change the arguments. If the assumption is that the last option overwrites anything before it then the cli command is valid with the option disabled.

And now, correct behaviour relies on all the code using that option to always make the same assumption.

Parsing, on the other hand, would put create a new config where `option` is an enum - either enabled or disabled or not given. No confusion about multiple flags or anything. It provides a single view for the rest of the program of what the input config was.

Whether that parsing is done by a third party library or first party code, declaratively or imperatively, is besides the point.

Fwiw, the two feed into each other. I read this same thing somewhere else before and have since tried to not take my phone with me into the bathroom. I started doing that because I would take a lot of time in there. But once I have my phone, if I start reading something a bit too long, I could easily spend 20 mins in there before realising it.

I want an option to give fake permissions. A lot of apps are pretty necessary (due to network effects). I don't want to give my contact or location data to them but they also refuse to work without it, even though they don't it for the stuff I am doing. So just let me provide fake data instead. As far as the app is concerned, it has the permissions it so wanted.

For the current category of LLM based AI, "AI optimised" means "old and popular". Even if you add a layer that has much more details but may be a lot more verbose or whatever, that layer would not be "AI optimised".