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

Yeah, but you need energy to desalinate so...

How does it compare to ~3000 L/MWh? I assume it's a rounding error.

edit: Desalination uses 4 kWh per cubic metre of water. That is, it would yield 250,000 L/MWh.


"sharding party"

Man, that made me laugh. I'm using that.


yeah, you haven't lived until you curled in blind rage _cluster/allocation/explain and _cat/shards?h=index,shard,prirep,state,unassigned.reason | grep UNASSIGNED every few seconds; In production party, with tarantulas on your back asking for status, of course.

> We do get compared to Elasticsearch a lot. While we support some of its APIs, Manticore isn't a drop-in replacement.

Thank you for saying that up front. I read a description of your product and the first thing I thought was, "this looks like a potential alternative to ElasticSearch, but it is not a drop-in replacement for ElasticSearch".


Yeah, this title for the article is really terrible. The "why" that scientists are investigating is not why many lung cancers aren't in nonsmokers. The "why" they are investigating is "why are these non smokers getting cancer?". Once smoking stops being such a dominant cause, you put more energy into the other cases.

It would be radon, wouldn’t it?

... well that is irrational

I can’t find any complete numbers (most prevalent factors after smoking would be environmental, and therefore underreported, especially when as hard to detect as radon), but national health agencies tend to put the Radon section second, after Smoking [1,2]. An uncited figure on a Hopkins webpage suggests 30% of non-smoking lung cancer cases are caused by Radon [3]. Among the well-known environmental factors (asbestos, secondhand smoke), it seems to be about equal for risk increase [4]. Given that asbestos and secondhand smoke are on the decline, it stands to reason that radon will tend toward being the top cause, barring a rise in prevalence of one of the disease risk factors (asthma, pneumonia, HIV, tuberculosis).

Of course this is all moot because vaping will be revealed to be the current #1 cause of lung cancer in the coming decades, by a long shot. No citation necessary.

[1] https://www.cdc.gov/lung-cancer/risk-factors/index.html

[2] https://www.nhs.uk/conditions/lung-cancer/causes/

[3] https://www.hopkinsmedicine.org/health/conditions-and-diseas...

[4] https://pmc.ncbi.nlm.nih.gov/articles/PMC6777859/


> Of course this is all moot because vaping will be revealed to be the current #1 cause of lung cancer in the coming decades, by a long shot. No citation necessary.

That isn't obvious or apparent to me at all so I do think a citation would be good to see. Nicotine is definitely a culprit in a lot of cardio-related issues for sure. I think some flavoring agents are the more questionable thing and would be curious to hear about those specifically in relation to lung cancers.


Fair enough. Cancer causation is just so weird, I'm going off the heuristic that stuff in your lungs that your lungs aren't prepared for is probably not great, especially with chronic exposure. And your lungs are really only prepared for air (which includes many things within certain tolerances [0]). The "not great" => "cancer" pipeline is really where the hand-waving comes in, and mostly far too early to tell whether the parts of vaping that are "not great" for your lungs will in fact be carcinogenic for your lungs.

So that being said, I'm mostly going to offer citations for "vaping is not great for your lungs." And that being said, I'm just going to offer citations for "specific parts of vaping are not good for your lungs." But my broader argument is that putting stuff in your lungs is going to be bad for your lungs, and these are just the most obvious ones we've found so far. Unfortunately I won't be able to find a citation for that argument.

So, first, the most recent: a study showing disposable vapes had incredibly high level of toxic metal emissions [1]. The non-disposable Juul et al variously have some concerning levels, but the insane numbers are on disposables, which are largely (entirely?) illegal in the US, at least. Still, they're not illegal everywhere, they were used heavily for several years in the US, and several of the top Google results were redditors complaining about the stupid ban and talking about how to get around it. All of this combines to lung damage down the line, and several of the toxic metals are outright carcinogenic, so lung cancer as well.

A more particular example: popcorn lung is a terrifying name, but pretty restricted risk, given the causing chemical is only in certain flavors, and those have supposedly stopped using it [2]. But again, an example of weird chemicals in your lungs cause weird things, and it'll be decades til we figure out all of them.

And finally, a study showing that vaping plus smoking leads to a four-fold higher risk of lung cancer over smoking alone (yes, they adjusted for age, gender, race, location of residence, prevalent comorbidities, and pack-years of smoking) [3].

[0] I was hoping to make a glib point about even high enough pollen concentration being bad for your lungs, but in fact a recent study suggests that allergies reduce risk of lung cancer! I'm chalking that up to allergies being your body's way of keeping non-air particulates from your lungs, but who knows. https://www.frontiersin.org/journals/medicine/articles/10.33...

[1] https://pubs.acs.org/doi/10.1021/acscentsci.5c00641

[2] Not a lot of research on popcorn lung, seemingly. Note that the name is related to its etiology, not its symptoms. https://www.summahealth.org/flourish/entries/2025/03/a-warm-...

[3] https://pubmed.ncbi.nlm.nih.gov/39210964/


> It isn't, that's why there's a blog article documenting how unexpected it is.

The behaviour is expected for the language design. Whether developers using the language expect it is a separate matter.

The with operator clearly allows someone to break encapsulation and as such should only be used in cases where you aren't expecting encapsulation of the underlying record.

> It's probably worth reading the article:

> "Note that because Value is set after the cloning operation, we couldn’t write a copy constructor to do the right thing here anyway."

It's probably worth reading the entire article, as that quote is followed by: "(At least, not in any sort of straightforward way – I’ll mention a convoluted approach later.)", which presumably was what was being referred to there.

In general, there's a whole ton of gotchyas around encapsulation of precomputed values. That's just life outside of a purely functional programming context.


> The behaviour is expected for the language design.

So, Microsoft meant it. Ok...

> Whether developers using the language expect it is a separate matter.

Really? Perhaps read the 'Principle of Least Astonishment' [1] to see why this is a problem. If I create a new object I would expect the 'init time' properties to be initialised.

> It's probably worth reading the entire article, as that quote is followed by: "(At least, not in any sort of straightforward way – I’ll mention a convoluted approach later.)", which presumably was what was being referred to there.

It's probably worth continuing to read the article. Because the attempt to deal with it required manual writing of Lazy properties:

    private readonly Lazy<ComputedMembers> computed =
         new(() => new(Value), LazyThreadSafetyMode.ExecutionAndPublication);
That's not practical. Might as well use computed properties.

> In general, there's a whole ton of gotchyas around encapsulation of precomputed values. That's just life outside of a purely functional programming context.

Great insight. Let's not run the 'init time' properties for a newly initialised object, just in case it works as expected. This 'feature' can't even be manually resolved by doing post-`with` updates (because often the properties are init/read-only). It makes the whole init-property feature brittle as fuck.

[1] https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...


> Really? Perhaps read the 'Principle of Least Astonishment' [1] to see why this is a problem. If I create a new object I would expect the 'init time' properties to be initialised.

The Principle of Least Astonishment definitely applies. It's a deliberate design choice that unfortunately violates the principle.

> Great insight. Let's not run the 'init time' properties for a newly initialised object, just in case it works as expected. This 'feature' can't even be manually resolved by doing post-`with` updates (because often the properties are init/read-only). It makes the whole init-property feature brittle as fuck.

? I'm not sure I follow what you are going with here, but yeah, in general you'd have to carefully limit all uses of "with" for objects with precomputed values to inside the encapsulation of said objects. Alternatively, as you mentioned, you could just not have precomputed properties.


> in general you'd have to carefully limit all uses of "with" for objects with precomputed values

What you’re describing is incidental complexity. It is not a good thing. We can’t constrain the complexity with language constraints, we have to rely on the programmer following some guidance and never ever making a mistake. In large teams and large code-bases that's a problem. And it's an offloaded problem from Microsoft to every software development team on the planet that uses C#.

The incidental complexity for the average C# developer has increased, whereas a better direction of travel would be toward correctness and declarative features. I would prefer it if the csharplang team worked toward that.


> What you’re describing is incidental complexity. It is not a good thing.

Yes.


Yeah, there's a long and tangled history with UNESCO that spans multiple administrations.

That said, the wording of the statement is... problematic.


Yeah, I remember using untagged unions because the code "knew" which type was the right one to use at the right time and you wanted to save space (and wanted your structures to fit well in registers --and later cache lines).

I suppose that’s what cobol copybooks are; untagged unions, everywhere, all the time, all at once

Just a wee bit.

I'm pretty sure when they got the gold medal they weren't allowed to judge themselves.

As guy named Chris Smith, I really appreciated this story.

Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: