Hacker Newsnew | past | comments | ask | show | jobs | submit | CookiesOnMyDesk's commentslogin

It’s covered in the article

>It means the decline you would normally expect in one year would take four years after treatment, giving patients decades of "good quality life", Prof Sarah Tabrizi told BBC News.

>The first symptoms of Huntington's disease tend to appear in your 30s or 40s and is normally fatal within two decades – opening the possibility that earlier treatment could prevent symptoms from ever emerging.


I don’t think this quite answers the curiosity of whether starting treatment e.g. at birth would virtually eliminate morbidity, or whether it only slows the decline once it has started.

Consider that the disease typically manifests in your 30s — does this mean it would begin 4x later (and thus basically never manifest), or that your 15 year progressive decline from ~35-50 would take 4x longer (giving you a normal lifespan, albeit perhaps with some limitations in your later years)?


To me, as an HD widower, it would have meant that my dead wife would had lived until 2043 and had a decade more of a mostly normal life.


two-ple, tri-ple, quadru-ple


>Why can't I just cast the music from my Youtube music app?

Because the YouTube app developers haven't implemented it? Casting via spotify works flawlessly in my experience, whether using airplay or letting spotify discover the speakers. No app hopping required.


> spotify

TBF that's because clicking on a Sonos device in Spotify uses their own special-sauce Spotify Connect, not AirPlay/Cast. So you're basically using the Spotify app as a remote for the selected Sonos device vs AirPlay/Cast which are transmitting (potentially a reference to) the underlying audio stream.


Something like this, depending on how you want your input and output to be supplied.

    public async IAsyncEnumerable<HttpResponseMessage> SendTwelveRequestsAtATimeAsync(IAsyncEnumerable<HttpRequestMessage> requests)
    {
        HttpClient client = new();
        List<HttpRequestMessage> requestsBatch = [];

        await foreach (var req in requests)
        {
            if (requestsBatch.Count < 12)
            {
                requestsBatch.Add(req);
            }
            else
            {
                foreach (var res in await Task.WhenAll(requestsBatch.Select(client.SendAsync)))
                {
                    yield return res;
                }

                requestsBatch = [];
            }
        }
    }


I would not call this trivial. :)


I'd argue that it is a lot easier than doing it with threads!

Promises are a primitive, and async and await keywords in JavaScript is just syntactic sugar around promises (it is sugar around similar constructs in other languages). A promise being just a long running task that will return a result eventually. Being able to grab a promise as an object and pass it around is super useful at times, and it is something I end up using a lot in my JS/TS code.

Because it is a language primitive that is also expressed in the type system, more complex systems can safely be built up around it, in the same way that it is easier to build safe(r) complex systems up around threads in languages that have threads as a primitive. (Rust being a great example here of bringing threads into the language, Java being another early example, though their early attempts were not perfect since we've learned a lot since 1995!)

Async/await and promises are a great example of a technology that makes doing easy stuff easy, and makes hard stuff possible.

tl;dr people need to stop complaining that other multitasking/threading paradigm looks different than their preferred one, each has plusses and minuses and one isn't "better" than others, they just serve different purposes.


He means that the price of the bonds backing the mortgage fall. Since the bonds are fixed interest, when interest rates rise, new bonds at a higher interest rate are more profitable than the old bonds at a lower interest rate. As such the free market price of the old bonds will drop to until the selling-at-a-loss reaches an equilibrium with the expected increased profit from higher interest rates of the new bonds over the lifetime of the bond.

This lets the loan taker buy back their own bonds for less than what they were paid (the loaned amount) when the bonds were issued.


Yup exactly this. If you go to "normal" bonds, there's many articles describing the idea, e.g. https://www.schwab.com/learn/story/what-happens-to-bonds-whe...

But basically:

Say a bond was originally worth say $100 and generated $10 of income in time T (10%). If interest rates rise so that $100 will now generate $20 (20%), then the original bond is worth less to a buyer. If we ignore the time delta, that bond would only really be worth $50 ($50 to generate $10 is the same 20%), so it's half as valuable. (The time change would bring it somewhere in between, depending on how long has elapsed).


If you get a keyboard that is programmable with QMK [0] and/or VIA [1] you can just program any key, or mod+key, to be a macro - and you can even record them on the fly [2].

[0] https://docs.qmk.fm

[1] https://www.caniusevia.com/

[2] https://docs.qmk.fm/features/dynamic_macros , https://usevia.app/


Discord uses 0% CPU (4770k) and 85mb ram on my pc currently, while being in an active call. What would it take for it to no longer be "too bloated" to have idling in the background?


Do you use abbaddon or the official client?


The official client.


Do you use a well named function like and(), or do you use the double ampersand (&&) syntax trick? What about a not() function, or the exclamation mark syntax trick (!)? :)

Every use of operators can be considered a syntax trick until it becomes common, which is what the author hopes will happen to ~~


> Every use of operators can be considered a syntax trick

That's blatantly false for strict languages, like JavaScript. For a function, all arguments are evaluated before the function is evaluated. For operators this is not true. On the and-case, the second argument is only evaluated if the first one evaluates to something true-ish.

You can only use this supposed and()-function, if you pass closures instead of values and not every language has those.


Then we should consider these reserved keywords and run a transpiler on our code that converts those to the unholy && and || syntax that makes the code really hard to read. You shouldn't expect every junior programmer to invest the necessary time to learn the meaning of all this archaic symbol salad.

While at it we should also remove curly braces and go with Basic's if/end if, function/end function and so on.


`&&` and `||` are very well defined (for the better part, there's languages where `||` does more than just Logical OR.), this double-not hack is just a hack, and can be achieved in many more ways. Stop trying to be obfuscatingly clever, the right time and place for that is outside of professional environments. You don't go around applying tricks from Hacker's Delight without explaining them, do you?


Well, surely that comparison is a bit unfair. :) In my books, using `~~` is closer to shit like abusing `[]+[]` to get an empty string, than using `&&` which is its own separate, widely used operator in the language.

You could maybe compare `~~` to something like `if (!someString)` but, again, that's a widely used and way more easily understood pattern.


Not just widely used in this language but in others, and the meaning of & is clear even in English.


This operator is not currently common for intended audience of my code. And also, it's intended meaning is so much less often useful than meaning of other operators, that I don't think it ever becomes common.


&& is a syntax element whereas ~~ is 2.

Further you're using a side effect of ~ to get rounding. It isn't being used for its intended purpose.

I get your point and to some extent agree with it.

It's more in the class of

While(foo++ = bar++)

You can do it, but you're to some extent abusing constructs.

If it becomes widely used then it's acceptable, but if not it deemed as bad code. Or clever, depending on your world view.


This is not the same at all. What OP does is a *hack* to convert some arbitrary value to a number. This should be very explicit, to avoid having 9999999999999999999999999999999999 and 1 more way to do the same thing.


The issue is that it's a JS only syntax trick. Things like x || y, or even !!x work in most languages, so would be readable to someone who has never used JS before and is trying to read your code base. ~~x would be int32(x) or int(x) in most other languages, so it's not going to be something that's universally learned.

Also, there are multiple ways to convert to int (~~ is equivalent to truncate). Why leave it ambiguous instead of using Math.trunc / Math.floor / Math.ceil?


But using the '&&' operator is common enough, while using something like the Javascript void operator would not be, and so would need in a shared codebase a reason for usage other than to try to look smart.


Of course in Perl, a language not exactly immune from "syntax tricks", `and` doesn't always behave the same as `&&` :)

    $ perl -E 'say 1,2,3,4 and 5; say 1,2,3,4 && 5'
    1234
    1235


Not defending it as sensible, but that difference in precedence is deliberate...not an oversight or side effect.


>Every time I start “New Teams,” it asks me if I want to go back to Old Teams

Are you sure you’re not accidentally opening the old Teams application? When you update to new Teams it leaves the old version in place so you have both, and if you open Teams with the new shortcut/application you won’t get prompted to switch back.


I think this was a bug that lasted a couple weeks or so because I had the same exact issue: Open New Teams, get prompted to switch back each time, including the first run (!?)


that's probably just MSFT's lackluster design of a chat application, though.


You probably want to be closer to 7,500 messages/second before Kafka becomes worthwhile.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: