The truth about 'breakthrough' drugs - <AUTHOR> https://www.washingtonpost.com/news/to-your-health/wp/2018/07/17/the-truth-about-breakthrough-drugs/ <comment><USER2> Looking at the original paper, the author does the analysis looking at breakthrough drug trial design, but doesn't really talk about what it means.

Of the 46 drugs approved under breakthrough designation, 25 were for oncology. The FDA often allows for a lot of flexibility with trial sign in oncology due to the high unmet need.

The author mentions a lack of trials being double-blinded, having a placebo or active comparator and clinical outcome vs. surrogate marker.

All of this is quite common outside of the breakthrough drug designation. Nothing new here. Double-blinding a trial isn't as big a deal when what you are measuring is not impact by observer bias (tumor size). In addition, if you're measuring a surrogate marker (that is an accepted proxy for clinical outcomes), you don't need a comparator arm.

I don't think any of these findings should be all that surprising or concerning.

<comment><USER3> > if you're measuring a surrogate marker (that is an accepted proxy for > clinical outcomes), you don't need a comparator arm

Why is this the case? Wouldn't there be concerns that a study population might be different from the general population and thus require an internal control?

<comment><USER2> Here is a good example of FDA guidance on the issue.[1]

FDA acknowledges that FVIII levels can serve as a proxy for clinical outcome (reduced bleeding episodes) in hemophilia A.

Our understanding of what is "normal" in FVIII blood levels is such that a single arm, surrogate biomarker study is sufficient for approval.

[1][https://www.fda.gov/downloads/BiologicsBloodVaccines/Guidanc...](https://www.fda.gov/downloads/BiologicsBloodVaccines/GuidanceComplianceRegulatoryInformation/Guidances/CellularandGeneTherapy/UCM610801.pdf)

<comment><USER3> Could you help by pointing out where they talk about not obtaining baseline/control data? After a quick glance, they only seem to mention using a within-subject design.

<comment><USER2> Sorry, misread your reply. Yes, they do an internal baseline/control, but don't have a control arm (either placebo or active comparator) in the trial.

That was the focus of the JAMA article.

</comment></comment></comment></comment></comment><comment><USER4> Sketchy stuff. The two drugs that come to mind are Xigris [0] and Celebrex [1]. There is so much money to be made and so few incentives to be rigorous in the trial process. It's no surprise we get cases where big pharma companies cook the books on efficacy and go to great lengths to ensure there is a market for their latest "blockbuster."

[0] [https://en.wikipedia.org/wiki/Drotrecogin_alfa#Marketing_con...](https://en.wikipedia.org/wiki/Drotrecogin_alfa#Marketing_controversy)

[1] [https://en.wikipedia.org/wiki/Celecoxib#Fabricated_efficacy_...](https://en.wikipedia.org/wiki/Celecoxib#Fabricated_efficacy_studies)

<comment><USER5> The unintended consequence of the onerous FDA approval process is that only a few extremely large players have the resources to develop and bring new drugs to the market. Therefore they need to make a lot of money back to cover their costs.

On the other hand, in earlier times we had a lot of drugs that were in the "snake oil" category, making a lot of claims but doing nothing at all (or that were actually harmful).

<comment><USER6> IMO the only criteria should be safety. Medicine doesn't have to work for everyone to be useful for a lot of people.

<comment><USER7> A great many drugs are grossly unsafe if you even minorly exceed the clinical dosage threshold, but are still regularly used by people because we haven't found better replacements.

A much larger set of drugs fall into a gradient of "as far as we can tell you'll just excrete it if you take too much" to "it's probably not _good_ if you unnecessarily take it, but it won't really be detectable in 4 weeks" to "oh god why would you ever prescribe that".

So if we were purely grading on safety, we'd be out quite a lot of pharmacology.

</comment></comment></comment></comment><comment><USER8> Sam Peltzman writes about this in "Regulation of Pharmaceutical Innovation"

[https://www.amazon.com/Regulation-Pharmaceutical- Innovation-...](https://www.amazon.com/Regulation-Pharmaceutical-Innovation- Amendments-Evaluative/dp/0844731285/)

And does a statistical evaluation of the effects of the FDA regulations.

</comment><comment><USER9> the entire FDA approval process was heavily gamed before, and is probably even more heavily gamed now. i'm talking about companies specifically starting drug discovery -- without anything in hand -- targeted at diseases where there is the reputation for the FDA playing loose with the approval process for whatever reason. fewer regulatory issues translates cleanly into more profit.

as the author points out, the incentives are always in favor of doing a bad job with regard to efficacy and trial design. a company that can produce a really great and well-proven drug is not going to make more money than a company that produces a shitty drug that is also approved for the same condition.

in fact, with the right marketing efforts, the execs would even see similar sales figures for both of these hypothetical drugs. hence why more is spent on marketing than R&D.

<comment><USER10> The "whatever reason" is that the level of long-term side effects that can be tolerated depends on the disease being cured. A drug that cures a previously fatal cancer should be approved, even if there are some long-term side- effects, because it's better than death. A drug that treats hair loss or heartburn needs studies to make sure that serious long-term side effects are extremely rare.

Testing for rare long-term effects requires a huge sample size, and billion dollar clinical trial budgets.

Teams do decide, early on, to try to discover drugs for serious diseases or common diseases, depending on how much money they think they can raise. Usually only proven teams can raise the huge amounts, so most pharma startups target serious niche diseases hoping for approval under the orphan drug program.

</comment></comment><comment><USER6> The FDA recently granted MDMA their 'breakthrough therapy designation'.

[https://maps.org/news/bulletin/articles/429-maps-bulletin- sp...](https://maps.org/news/bulletin/articles/429-maps-bulletin- spring-2018-vol-28-no-1/7256-breakthrough-therapy-designation-streamlining- the-path-to-approval-spring-2018)</comment>


A Vote for Younger Presidents - <AUTHOR> https://blogofjake.com/2020/07/08/a-vote-for-younger-presidents/ <comment><USER2> NO, NO, NO. You're timing is wrong. We all need to get behind Biden despite his advanced age. What's at stake is way too important to divert the conversation away from our goal: to save the Republic.</comment>


Steve Crocker on the History of RFCs - <AUTHOR> https://spectrum.ieee.org/tech-history/cyberspace/todays-internet-still-relies-on-an-arpanetera-protocol-the-request-for-comments <comment><USER2> The title is misleading: the piece covers far more ground than that.

I was fortunate to work for BBN briefly in the late 90s, and I visited their computer warehouse hoping to steal a hard drive for an old server. I regret not having a camera, because they had some pretty cool old hardware, including several long-obsolete IMPs.

That warehouse could easily have been converted to a museum; I hope someone preserved the hardware.

</comment><comment><USER3> I see the same approach being rarely applied today, most protocols are done by regimented groups of competitive people that just want to see their idea being standardised, the result is often complex and inefficient constructs.

I do see the folks of the PJON project being the few trying to replicate the approach and the development environment described by the author: [https://github.com/gioblu/PJON](https://github.com/gioblu/PJON)</comment>


Prometeus - The Media Revolution - <AUTHOR> http://www.youtube.com/watch?v=xj8ZadKgdC0 <comment><USER2> I LOVE THAT! What a brilliant piece to launch thier talents. Bravo! ;-D

</comment><comment><USER3> That is really cool.</comment>


Announcing Rust 1.28 - <AUTHOR> https://blog.rust-lang.org/2018/08/02/Rust-1.28.html <comment><USER2> I've been studying Rust on and off in the past 3 months. There are a few things that I find annoying, they are somehow discussed in the issue tracker, but it's not clear to me what the priorities are to land them:

* Partial borrow. I can't borrow a field of a structure and then reference another field. I can't cite how many times in a few weeks I've been forced to rethink and split my structures just to work around this, making my code harder to read and write for no good reason than working around this limit of the borrow checker.

* The Rc/RefCell/Box dance is very verbose, when you just want to share a reference to some long-living object within other long-living objects. Worse than verbose, it also causes a runtime overhead because of the RefCell.

* No simple way to declare non-const global objects, like something as easy as a global HashMap of constants strings to constant integers. I'm a little spoiled from Go's excellent support of init functions (both compiler-generated and manually written), but this is something I really miss in Rust. lazy_static! is a workaround which is harder to use and forces the code to be thread-safe even if no threading support is necessary (that is, I can't use my non-thread-safe classes in a lazy_static).

* In generic code, there is no simple way to represent integer types. You need to use the "num" trait which breaks the "as" operator causing big pain and less readable code (as it's normal to covert between integer types).

* No integer generic parameters. We have to use the "typenum" crate which ends up causing less readable code and generates C++-like error messages.

* PhantomData is awkward, it absolutely sounds like something the compiler should handle, not the programmer.

* "Wrapping<u32> \+ 1" doesn't compile, but is there a good reason why it does not? I really wish Rust added wuNN/wiNN native wrapping types, or evolved in a way that I can write the same code with "u32" and "Wrapping<u32>" (another example: "as" doesn't work). Right now, it seems like the solution is half-baked: it tries to use the generic to avoid adding a native type, but the code that users must write is more bloated compared to native types.

<comment><AUTHOR> It can be hard to get a hold on so many features, I hear you. Some of this is Rust, some of this is your perspective vs. Rust's perspective. Here's what I have for you:

* Partial borrow.

The status of this is unclear. It does work in many cases. It's complicated. I would push back a little on the "no good reason" though, but this is gonna be long so I'll leave it at that.

* Rc/RefCell/Box

Yes, this is painful, but that's because shared ownership is painful. Rust is pushing you away from a certain kind of architecture. Many people think this is a good thing...

* No simple way to declare non-const global objects

That is lazy_static. But

> forces the code to be thread-safe even if no threading support is necessary > (that is, I can't use my non-thread-safe classes in a lazy_static).

This is perceived as a good thing; if you code changes later to use threads, you're not hosed.

If you want something that's not for multi-threading, then don't use something that can be used with multiple threading! TLS is probably what you actually wanted here.

* In generic code, there is no simple way to represent integer types.

We went through three versions of these traits, and were not happy with any of them. It's a tough problem.

* No integer generic parameters

This is coming; the design work has been accepted, and now it's on to implementation. It's expected in nightly by the end of the year and probably stable early next year.

* PhantomData is awkward, it absolutely sounds like something the compiler should handle, not the programmer.

The compiler _could_ try to infer variance, but that means that if your code changed, you'd have a breaking change. In general, around interface boundaries, Rust requires you to state what you want.

It's even less awkward than what came before it, for what it's worth.

* "Wrapping<u32> \+ 1" doesn't compile

Rust is pickier about numbers than many langauges; 1u32 + 1u8 doesn't compile either. Many people find this valuable; you don't have to memorize complex promotion rules, and you always get the semantic you asked for.

<comment><USER3> Re: non-thread-safe items in lazy_static, you can also wrap them in a mutex within just the lazy_static so the struct only uses synchronization when it actually needs to be thread-safe.

<comment><USER4> That removes the Sync requirement, but still requires Send, so doesn't completely resolve the requirement for thread-safety (e.g. Rc can't be stored).

</comment></comment></comment></comment><comment><USER5> I have to say, the Rust compiler's commitment to nice error messages makes it a pleasure to work with. It is also cool to hear about the GlobalAllocator trait stabilization. I'll have to check out what the embedded-Rust space has been doing in this area!

<comment><USER6> Yes, it's nice to see improvemed error messages. I read many people loathed what the borrow checker threw at them.

<comment><AUTHOR> I'd like to mention that along those lines specifically, a lot of people have talked about NLL in terms of "the borrow checker accepts more of my code", but it also produces _way_ better errors. See the "Diagnostics" section of [http://smallcultfollowing.com/babysteps/blog/2018/06/15/mir-...](http://smallcultfollowing.com/babysteps/blog/2018/06/15/mir- based-borrow-check-nll-status-update/) for an example that I ran into in real code. (It's niko's blog but I supplied him with this example)

<comment><USER6> I think pouring more time and money into the error messages will pay out in the long run.

Messages like that make coding low-level stuff fun again.

</comment></comment></comment></comment><comment><USER7> A summary of what is new:

\- Global allocators

\- Improved error message for formatting: provides a specific reason why it is invalid

\- Library stabilizations: NonZero number types

\- Changes to Cargo: src directory can not be modified

<comment><USER8> Global allocators are nice, but what would be really helpful in some performance intensive applications is to specify an allocator for a collection.

<comment><AUTHOR> That work relies on this work; that's coming!

</comment></comment></comment><comment><USER9> After two versions where performance has been unchanged I once again see a little bit of performance improvement with this version in my pet photo camera raw decoding benchmark. 1.28 is ~1% faster than 1.27 and nightly seems to be ~1% faster than 1.28 again. Don't know if there have been LLVM updates or if work on the rust compiler itself has helped. In total, since version 1.17 I'm measuring almost a 25% improvement in CPU intensive code. I need to make a more comprehensive benchmark easy to run by everyone (many different kinds of files, fully automatic running, etc).

<comment><AUTHOR> Due to an upstream LLVM bug, we had to remove some information about aliasing; that bug was fixed and this was re-enabled in this release. That _may_ be what you're seeing.

</comment></comment><comment><USER10> The NonZero type reminds me of something else I'd like to see in Rust; ranged integers. By which I mean integers that can only represent a specified range of numbers.

This is not so much for optimization but for type safety (i.e. avoiding bugs).

<comment><AUTHOR> We'd like that too; it's likely to fall out of const generics, which are looking likely to hit stable sometime early next year.

<comment><USER11> With const generics ranged integers would be implemented as a user specified check.

How viable would it be to implement an optimization step which seeks to minimize the number of these checks?

<comment><AUTHOR> I'm not entirely sure what you mean, exactly. As far as I know, all of the usual optimization passes would already be working to minimize them.

<comment><USER12> Rust could emit LLVM range metadata for ranged integers. IIRC, it already does so for enum discriminants.

<comment><AUTHOR> That seems quite good!

</comment></comment></comment></comment></comment></comment><comment><USER13> Good times! And to those that like me enjoy a good dead trees-based book to learn a language, the Rust Book (from NoStarch publishing) arrived yesterday at my door :)

[https://nostarch.com/Rust](https://nostarch.com/Rust)

<comment><USER14> I've been reading the O'Reilly book but I'll look at TRPL next. BTW I'm read this on Safari: Steve, do you know how publishers/authors get compensated for Safari books? Are there just normal royalties or is it somehow negotiated in a bulk rate?

EDIT: Steve answers a semi-related question in [1]

[1] [https://www.reddit.com/r/rust/comments/8u0ggw/trpl_is_releas...](https://www.reddit.com/r/rust/comments/8u0ggw/trpl_is_releasing_on_amazon_without_customer/e1bwffl/)

<comment><USER15> I don't know how far in you are, but I would suggest reading TRPL first. I read the Programming Rust book first, but I found TRPL a much better introduction. I wish I had done them in the other order. Maybe read TRPL first, and then go back to PR.

<comment><USER16> I completely agree and I did the same thing. I own dead tree variants of both and TRPL approach immensely helped grokking the language whereas the Programming Rust book feels more like a reference book for dives into concepts.

</comment></comment></comment></comment><comment> ainar-g I wonder, why is it NonZeroU8, NonZeroU16, etc instead of something like NonZero<u8>, NonZero<u16>, etc?

In theory, in the future, when Rust supports constants as template arguments, one might even add a const argument, the value that should be used as "null". E.g. if my u8 never reaches 255, I could use something like Never<u8, 255>.

<comment><USER17> Can anyone brief what NonZero even is.. or rather, it's application? From the sounds of it, it's literally just a u8 _(or w /e)_ that can't be zero.. but what use case does that have?

<comment><AUTHOR> Let's take an enum, like Option:

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

Under the hood, this is a "tagged union"; Rust has to have enough space for the T, but also for a tag, to say which variant is the current one.

If T is a NonZero type, then we know that zero is never a valid value. That means that instead, Rust can use the zero value to mean the None case, and any other value to be the Some case, completely eliminating the extra tag, and reducing the size of the Option.

This is a good example of a "zero-cost abstraction"; an Option in this case has absolutely no extra associated overhead at runtime.

Note that these optimizations aren't specialized for Option; they apply to anything that has this kind of shape.

<comment><USER18> Is NonZero* special cased by the language? If for instance, I had a preexisting binary interface where 0 through (2^n - 2) is valid, but all bits set is the invalid case, can I explain that to the compiler as well?

<comment><AUTHOR> Yes, it is. The case you're talking about is pertinent to the above discussion on why it's NonZero* vs NonZero<T>; you cannot currently inform the compiler in your case.

</comment></comment></comment></comment></comment><comment><USER19> Now that users can switch out the global allocator, the next step may be to change the default allocator for Rust programs from jemalloc (which, note, is only the default on some platforms) to the system allocator. This has been blocked on stable global allocator support in order to make sure that users who find that jemalloc is superior for their program have a recourse to avoid performance regressions; ideally switching to jemalloc (or tcmalloc, etc.) should be well-facilitated by Crates.io.

As for the rationale behind moving away from jemalloc as a default, the tracking issue is here: [https://github.com/rust- lang/rust/issues/36963](https://github.com/rust-lang/rust/issues/36963) (TL;DR: lower maintenance burden, easier cross-compilation, smaller binaries, better system integration (including packaging), and the ability to use Valgrind).

<comment><USER20> In case of FFI, if C & Rust are using the same allocator (say the system allocator), does it mean that memory allocated by C can be freed by Rust and vice-versa?

<comment><USER12> Yes.

<comment><USER3> Many types in the standard library do not consider it sound behavior to have their allocations freed by functions other than their own destructors:

[https://doc.rust- lang.org/std/boxed/struct.Box.html#method.i...](https://doc.rust- lang.org/std/boxed/struct.Box.html#method.into_raw)

        After calling this function, the caller is responsible for the memory
        previously managed by the Box. In particular, the caller should properly
        destroy T and release the memory. The proper way to do so is to convert
        the NonNull<T> pointer into a raw pointer and back into a Box with the
        Box::from_raw function.

I would guess that this might become a fun latent footgun in crates.io code -- everyone writes their unsafe code in a way that Just Works under the default allocator, but then things break down in confusing ways when enabling alternative allocators, which should be safe to do even when using external crates.

<comment><AUTHOR> That's already true in cases; for example, I've seen FFI code that has a use- after-free bug in it, but because of the different way that the allocator works on different platforms, on OS X it "worked", but on Linux, it segfaulted.

</comment></comment></comment></comment></comment><comment><USER21> I'm pretty happy about the GlobalAllocator stabilization. Now you can run Massif and Heaptrack on rust code without switching to unstable!

</comment><comment><USER22> I want to expand my knowledge but don't know whether to invest in learning C++ or Rust. Both look like they have interesting concepts, but Rust is new and not yet widely used, and I hear C++ is easy to break in confusing ways. (I have cut Go out of the picture because copying and pasting code is the first thing you learn not to do in school, but all the Go leaders say you have to do this since they don't want to implement generics, so I don't trust their judgment on language design.)

<comment><USER23> If you're trying to expand your knowledge, then waffling over which thing to learn is just procrastination.

<comment><USER24> No. By that logic, you could as well open a random page on Wikipedia and start learning new stuff. Choosing to study a certain technology in depth carries with it a high opportunity cost in the form of your time.

<comment><USER25> They are almost equivalent choices in terms of return of investment. C++ is used almost everywhere. Rust will allow you to write programs with less bugs and similar performance to C++.

The opportunity cost of figuring out which one is better can often be higher than just trying out both choices. [1]

[1] [https://xkcd.com/1445/](https://xkcd.com/1445/)

<comment><USER24> > _They are almost equivalent choices in terms of return of investment._

Someone who asks whether they should learn C++ or Rust probably doesn't know this – otherwise, they wouldn't ask.</comment></comment></comment></comment></comment>


Ask HN: Why is it so difficult to get great insights from data? - <AUTHOR> <comment><USER2> 1] You are not measuring the "important" phenomena

2] Measurement error obscures the signal

3] Missing data

4] Data coming from disparate parts of a system may not have been collected at the same unit of analysis

5] Domain experts may have really good mental models of how various factors relate to each other so when you do analysis of data it mostly confirms what the experts already know and is therefore "not very insightful"

6] Too many variables, not enough cases

7] Data sparsity

8] Necessity to combine the skills of a researcher with those of a domain expert (both of those elements can have at least moderately steep learning curves)

9] Time pressures - great insights that arrive too late for action are useless

10] Combinations of any or all of the above

</comment><comment><USER3> ...it's not?

Do you have an example?

<comment><AUTHOR> Well, in business, it seems that most deciders have difficulties to find the real important insights in their data. Dashboard are nice, but they often don't reveal the really relevant stuff. They show you only what you know, but no interesting data patterns. I wonder why this is? Is it a tooling issue, a skill problem, ...?</comment></comment>


Ask HN: What can a startup expect to spend on hosting? - <AUTHOR>

Hey, I'm curious about what kind of money a "healthy" startup can expect to spend on hosting in the first year(s).
I say healthy because I am not assuming full on hockey-stick growth, but enough that you are clearly on to something.
I'm planning to use AWS, but I am open to other suggestions and would love to  hear some comparisons with other services.
Thanks! <comment><USER2> Impossibly vague question + the price will rarely have anything to do with a startup being a "good idea" and may not even correlate to growth.

<comment><AUTHOR> Fair point. Assume a vanilla Rails app, with RDS for the Database. Perhaps a configuration something like this:

[https://medium.com/@jatescher/how-to-set-up-a- rails-4-1-app-...](https://medium.com/@jatescher/how-to-set-up-a- rails-4-1-app-on-aws-with-elastic-beanstalk-and-postgresql-66d4e3412629)

<comment><USER2> If you don't really know what you're building or how you will build it then you don't have the information you need to figure out how much it will cost to host. It's anywhere from $0 upwards.</comment></comment></comment>