Mounting challenge to brain sex differences - <AUTHOR> http://sciencebulletin.org/archives/9423.html <comment><USER2> I work in a area related to this: neural aging. Many of my collaborators are constantly looking for gender differences in the basal brain and WRT the aging process.

They are encouraged to do this by a semi-recent NIH policy strongly encouraging experiments to include both genders because of a perception that females were being left out of biological research. I don't think that is true, because for example NCBI GEO samples are virtually equally balanced between M/F, but hey, NIH has to play along with politics to some extent to get funding.

So once investigators have gone to the trouble and expense of including both genders in an experiment, they will naturally do the analysis comparing genders. They will perform lots of comparisons, sort the p-values, and declare some differences. And to provide a fig leaf for readers concerned that our time is being wasted, they will say these differences which are probably often statistical artifacts, are "important" for some nebulous, rarely explained reason.

This is not to say there are NO differences. In the context of aging, female humans live several years longer than males on average, and there are some biological reasons for that. It's just that it beggars my imagination to think that core biological processes unrelated to reproduction would have vast differences between genders. Evolution, it should be remembered, predates gender by a long time. More importantly, if we are trying to understand core biology, we should be focusing on the main effect IMO rather than the relatively minor gender differences.

<comment><USER3> "Evolution, it should be remembered, predates gender by a long time."

1\. Good point - gender is 50 years old (first used in 1963).

2\. What about other, non-human organisms? If we leave humans out of it, there have to be significant differences in brains between sexes of different species.

</comment></comment><comment><USER4> That article has some kind of hasty judgement, saying that because a tiny brain structure is equal in men and women it is evidence for the whole brain being the same...

Yet what about other obvious evidence of the differences, like the fact that men brains are usually obviously heavier? Or the differences in overall distribution of grey and white matter? or that many neurological disorders, like aspergers syndrome, have different symptoms depending on the sex?

</comment><comment><USER5> I didn't read the actual study, but from the article they are basing this on the amygdala size being bigger but the male brain also just overall being bigger.

My question is: What rules out the bigger size itself (irregardless of overall brain size) causing differences? Perhaps, the ratio of amygdala size to brain size does not matter but rather just the absolute size.

<comment><USER6> _> My question is: What rules out the bigger size itself (irregardless of overall brain size) causing differences? _

ideology

</comment></comment><comment><USER7> They are demonstrating that they didn't find difference. Not that none exist. They do exist, and this is easy to verify with the Piaget Water Level Task.

The task is simple. Draw a cup like |_| and then the same tilted perhaps 30 degrees. Hand the pictures to someone and ask, "If they are both half-full of water, draw the water line." Conduct this experiment on 5 random adult friends of each gender.

With extremely high probability, you will now have very strong evidence that there are very real brain sex differences. No demonstrated ones that seem particularly important to me, but clearly they exist.

(I first encountered this as part of a pair of questions, this one and another which women got and men didn't. I thought it was BS, a month later gave this one to my then girlfriend, and have never again found the other. Incidentally there is no difference on performance in this one until puberty. Interestingly the odds of success for gay/trans people are between straights, suggesting that their brains tend to be mixes of "normal" in more ways that one.)

<comment><USER8> Can you share the expected results? I don't have 5 random adults with me right now. ;) And Google does not turn up anything useful (only paywalled papers).

<comment><USER7> Around 90% of men find the task trivial. About 70% of women can't do it.

Additionally women who can't do it when presented with the same task years later remember that there is a trick, but have trouble remembering it and still can't do it.

I have never met a programmer, male or female, who found the task anything other than trivial. I have no idea why, and no idea whether this fact may be correlated with the gender imbalance in programming.

<comment><USER9> Did you specify about 30 degrees because the trivial method fails if the tilt is too large?

I see a trivial solution, but it only works if the ratio of the water height before tilting to the diameter of the cup is greater than the tangent of the tilt angle.

<comment><USER9> OK, I've done some reading on this, including a several year old blog entry on this topic by the person who brought it up here [1], and it looks like I misunderstood what is required to consider the problem solved. I took it as requiring that volume, shape, and orientation of the water all be correct in the tilted cup, and assumed that people who fail are probably getting shape and orientation right but are not getting the volume right.

Apparently, the failure mode is typically to get the shape and/or orientation wrong, and you pass if you get them right. Volume doesn't have to be right.

[1] [http://bentilly.blogspot.com/2010/08/piaget-water-level- test...](http://bentilly.blogspot.com/2010/08/piaget-water-level-test.html)

<comment><USER7> Exactly.

The whole challenge is, "Can you remember that water should be horizontal to the horizon?" Remember that, and you pass.

</comment></comment></comment></comment></comment></comment><comment><USER10> I wonder what the transgender community has to say about this given their efforts to prove that there are differences.

</comment><comment><USER11> TLDR; Evidence is piling up that the male brain / female brain concept is nothing more than a myth.

<comment><USER12> That's a terrible synopsis of the linked information.

_They_ say ([http://www.sciencedirect.com/science/article/pii/S1053811916...](http://www.sciencedirect.com/science/article/pii/S1053811916307431)) that as the male brain is 10% larger in the studies covered by their meta- study the fact that the male amygdala, a small portion of the brain, is 10% larger in those studies means it can be normalised out and we can say that the male and female amygdala are not different.

This might be the worst reasoning I've ever read in a scientific paper.

Presumably the full study has fine structure detail comparisons that show that the male amygdala is merely an enlarged version of the female one, that there is no additional smaller structure in one than the other (which would be strange, meaning male neurons/blood vessels/etc. were larger, which would itself be a difference that warranted study).

FWIW the highlights make the reverse claim implicitly as it says male amygdala are 10% larger but their brains are 11-12% larger. That would give the conclusion the male amygdala is smaller as proportion of brain volume. So, the quoted figures contradict the conclusion just within the abstract, that seems like bad form.

The abstract says:

>These values correspond to less than 0.1% larger corrected right AV [amygdala volume] and 2.5% larger corrected left AV in males compared to females.

2.5% isn't even possibly significant though right, like the "we share 99% of our DNA with chimps" statistics [however misguided they are].

Now, sure the amygdala could have identical function in human males and females, but this study doesn't seem to move any closer to that conclusion if the highlights and abstract are representative.</comment></comment>


Effective Coding Standards - <AUTHOR> http://codeahoy.com/2016/05/22/effective-coding-standards/ <comment><USER2> I agree with the main thrust, that coding standards can help to make code readable, might help to highlight dubious or buggy code, and should be (machine) enforceable...

...but at the same time, I do not agree that rules can be neatly divided into "fact" and "opinion."

In fact, I would go so far as to say the _reason_ we have so many conflicting standards is precisely because we cannot agree on what is fact and what is opinion. And that's OK.

As a case study, I give you "Miss Manners' Guide to C++", which eventually was published as "Taligent's Guide to Designing Programs: Well-Mannered Object- Oriented Design in C++" [[http://www.amazon.com/Taligents-Guide-Designing- Programs-Obj...](http://www.amazon.com/Taligents-Guide-Designing-Programs- Object-Oriented/dp/0201408880)]

That document started as a simple set of do's and don'ts. It was, as the OP might have put it, "full of author's own opinions and personal coding style." But it was also the agreed-upon style for the project ("Pink") and had utility.

Another classic example is Hungarian Notation. I suspect you would find a number of people passionately supporting and others vehemently denying its usefulness.

For this reason, maybe calling them "coding styles" may be nearer the truth.

<comment><USER3> It's about being able to maintain the software for next 3 years. Sure people have opinions but sometimes it's better to agree to disagree and have the discipline

<comment><USER2> Hmmm, I wasn't saying one shouldn't use coding style guides. Quite the reverse. My point is that it is not whether any particular guideline is "factual" or "opinion," but whether one can get teammates to abide by them.</comment></comment></comment>


Take That, AP Style! Court of Law Rules the Oxford Comma Necessary - <AUTHOR> https://thewritelife.com/is-the-oxford-comma-necessary/ <comment><USER2> IANAL but it seems to me Oxford Commas should be used in legal documents.</comment>


Why Niches are Better - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2007/03/the_china_probl.html <comment><USER2> From http://www.paulgraham.com/startupmistakes.html:

"3. Marginal Niche

Most of the groups that apply to Y Combinator suffer from a common problem: choosing a small, obscure niche in the hope of avoiding competition."

\---

Usually the problem isn't that the market is too big, it's that the company is too scattered in focus. If you know your product well and you know its target, big playing fields are not a problem. You can be a small niche player and still be all over the place in delivery.

<comment><USER3> The best way to build a company is not by going after an existing category, but by creating a new category you can be first in. In the struggle for life, no two startups can occupy the same position. If they try to do so, one company will drive the other to extinction.

Now this does not mean that you can go ahead and invent some "obscure niche". A startup that serves a market too small and of little interest may never gain the traction to reach a tipping point.

Competition is a good thing. It takes a George Foreman to make a Muhammad Ali. Strong competition validates the smaller player. I will go as far as to suggest that without Digg, Reddit would've had a difficult time gaining wide angle attention from the blogosphere. However, competition should be avoided where it makes sense. In other words, don't consciously look for it.

</comment></comment><comment><USER3> All business is a niche business. Startups must put a conscious focus on segmenting their market to a small but sustainable size. I have emphasized the significance of this in my earlier articles:

http://www.readwriteweb.com/archives/6_startup_lessons_2007.php http://m4th.com/Articles/Article.php?Article-Title=Anatomy-of-a-Successful- Social-Network

</comment><comment><USER4> isn't one of the things that makes the US good for startups the fact that we have one large unified market? If you only read this post you might think it would be better to start in a European country. I guess the takeaway would be, you can turn your limitation (relatively small home market) into a strength (use your niche)

<comment><AUTHOR> I think what makes the US a good market is that is has a large general market, which is strong because its size produces more opportunities due to bigger niches not due to sheer size and certainly not due to homogeneity.

</comment></comment><comment><USER5> Absolutely agree. Not to say that something bigger can't grow out of the niche. You see that all the time.</comment>


Meat Is Horrible - <AUTHOR> https://www.washingtonpost.com/news/wonk/wp/2016/06/30/how-meat-is-destroying-the-planet-in-seven-charts/ <comment><USER2> I agree that meat farming, at least in the factory-style, is horrific. But this solution seems like it might make things worse.

If there's a meat tax, then farmers will have an incentive to cut even more corners, which might lead to even more cruel conditions.

Instead, maybe it makes sense to set a price floor for any operation over a certain number of animals. (IE, if you have more than 200 animals on your farm, you can't charge less than $10 a pound or something).

<comment><USER3> I think that government mandated minimum quality of life for the animal. Space, roaming, feed, water etc.

<comment><USER4> That would be good and humane way to reduce beef production and increase prices to reduce the demand but it would be costlier for government than setting up new tax.

Maybe we could do both? Tax the beef and use the money to enforce minimum quality of life for animals?

Even manufacturers could be not that upset because they could significantly increase price per unit.

Only group that would be angry could be beef consumers at least the ones that prefer quantity over quality and/or can't pay for quality.

<comment><USER3> I don't care about the price of beef - I only care about the animals living life free of needless cruelty.

I am not even convinced that it will be more expensive - the US is vast, there is lots of stuff to graze, instead of disposing of the manure it will be used as fertilizer and so on.

<comment><USER4> Wouldn't you want less animals to be exposed to necessary cruelty? Higher price can help with that.

</comment></comment></comment></comment></comment><comment><USER5> Countries should cease trying to increase their populations at the expense of quality of life. This is but one example of many where quality of life suffers and Soylent Green diets are suggested to accommodate the infinite growth crowd. I have a better idea - rather than creating a society that looks like some dystopian nightmare, we simply keep populations in check with the environment.

<comment><USER6> Countries with balanced or decreasing populations can't compete economically.

<comment><USER7> Sure they can because the others will starve to death eventually.

<comment><USER8> Or they will be welcomed in your country as refuges.

<comment><USER7> Absolutely! We have unlimited resources here in Sweden!

</comment></comment></comment></comment></comment><comment><USER9> I'm sceptical about this, for a couple of first-year-physics reasons.

1\. Matter is conserved. Before carbon can be farted out of a cow, it has to get in to the cow from somewhere else. I expect most of it was in the atmosphere a year beforehand, then got absorbed by pasture grass and eaten. So this year's farts will end up in next year's cows, and aren't like fossil fuel emissions.

2\. Methane decays to carbon dioxide in a decade or two, so today's methane emissions are not really a worse problem than today's carbon dioxide emissions.

<comment><USER10> 1\. The CO2 issue is not that the cow eats carbon and its manure turns back into CO2. The issue is the land use changes and fossil fuel-derived energy used in the production and transportation of feed. Because the feed to usable meat ratio of beef is somewhere between 7:1 to 20:1, this is significantly more impactful than other foods.

2\. CH4 may not have a long half-life, but it has 29x the warming potential of CO2. Methane is thought to contribute about 20% of the current anthropogenic greenhouse gas forcing. Because of the anticipated positive feedbacks from warming, this is very important indeed.

<comment><USER11> >CH4 may not have a long half-life, but it has 29x the warming potential of CO2.

To be clear, methane has 451x the heat trapping ability, the 29x figure is the 100year impact that takes into account the methane breaking down.

<comment><USER9> Thanks, that makes a big difference. Apparently you can't trust newspapers even on the orders of magnitude for these things.

</comment></comment></comment></comment><comment><USER12> The title should read "Industrial Farming is Horrible". Industrial crops aren't much better for the environment.

<comment><USER13> My data-free immediate thought was, '...but industrial meat farming uses N times as many resources [land, water, petrochemicals] to produce the same number of nutrients/calories...'

Now I am interested if this is in fact true. I have certainly heard this argument made, and it is often alluded to e.g. in describing the problem in China of producing enough meat to satisfy an increasingly affluent society (the subtext being, 'with the same constrained resources').

Going to poke around a bit...

<comment><USER13> TL;DR: it is in fact true. Best would be vegetarian diet; failing that, eliminating beef is a huge win.

QED if you are not vegetarian and have no interest in being, the 'greenest' thing to do is to reduce or eliminate beef consumption.

[http://ajcn.nutrition.org/content/78/3/660S.full](http://ajcn.nutrition.org/content/78/3/660S.full) is glum.

(I looked at resource usage, not the ethical side; fwiw I'm an ethics- motivated vegetarian myself.)

<comment><USER14> In my experience, out of the commonly-eaten meats, beef tends to be the priciest anyway.

<comment><USER15> It's also one of the best for you to eat, assuming it's grass-fed.

<comment><USER11> Source for that? I've never heard of any beneficial effect of red meat consumption.

</comment></comment></comment></comment></comment></comment><comment><USER16> >It may be delicious

Not to me, but let's see.

>2 degrees carbon budget limit

Woo... 2 degrees. We can totally consider establishing settlement in Mars but God forbid there is 2 degree change in climate on earth. It will be uninhabitable. NOT.

>Agriculture consumes 80 percent of water in the United States.

Oh yeah, because we were otherwise going to drink the river... or maybe it disappears when it is used in agriculture. Except it doesn't. Water is the most recyclable resource there is.

>carbon output from food production has increased by 47 percent from 2000 to 2012 — that's an increase of 150 million tons of carbon dioxide

Except carbon that is emitted to the atmosphere doesn't stay there. It's called carbon cycle. If we are producing more meat, we will also have to produce more food for the animals... which comes from plants... which take CO2 from the atmosphere to grow.

You're fooling nobody. Don't get into our kitchen.

<comment><USER17> There are also carbon emissions from producing ammonia fertilizer.

<comment><USER16> Yes, in which hydrocarbons, mostly methane, which is a biproduct of fossil fuel production, (which either has to be used or released to the environment), is used for getting the Hydrogen. If it's used, CO2 is emitted, which is much better than releasing CH4 to the environment.

<comment><USER17> Yes, methane leaks are a huge problem. But is it really accurate to consider methane etc used in ammonia production as waste?

</comment></comment></comment></comment><comment><USER18> Could some countries realistically just phase out (outlaw) most classes of meat production and consumption? IMO that's much more interesting than any taxation/disincentivization scheme.

<comment><USER19> No, for the same reason they couldn't phase out alcohol and drugs

<comment><USER20> I think public education could be enough here. Obviously, a campaign to reduce beef consumption would be far more successful than one to reduce or eliminate meat consumption. I eat meat and like it. I'd struggle to cut out all of it, but I could easily see myself making beef a thing to have at restaurants or special occasions only. More than happy to stick with chicken, pork and lamb (which I think is far more popular in Australia than the US?).

</comment></comment></comment><comment><USER21> I feel like this problem would solve itself if livestock producers were encouraged (read: mandated) to move from factory farming to more traditional ranching. Lower density of livestock, more humane conditions, at least some carbon offset from pastures, etc. Prices might go up, which will likely hurt low-income carnivores, but that'll be the case with the proposed taxation approach, too.

</comment><comment><USER22> This isn't about meat, but rather farming methods.

<comment><USER23> Well, not really. meat is horrible in many ways, and the very few systems that aren't bad for the environment won't scale.

If all pasture was magically turned into carbon sinks (in my home country about 5% of natural pastures could be called carbon sinks. in some countries it is almost as high as 30%) we would still have to cut our meat consumption considerably - and that would be for sustaining the meat consumption of today and not meet the growing consumption in Asia.

</comment></comment><comment><USER24> Hum, Some people still think that they are made of gold?</comment>


Impulsive Rich Kid, Impulsive Poor Kid (2015) - <AUTHOR> https://priceonomics.com/impulsive-rich-kid-impulsive-poor-kid/ <comment><USER2> Just a reminder: This article is an ad for a web crawler/content marketing service. The purpose of the article is to be viral. Data is selected and presented to that end. See especially "The Tragic Data Behind Selfie Fatalities" which charts data from a particularly poor Wikipedia list and what appears to be a google search.

<comment><USER3> I say this every time pricenomics gets upvoted - they only do content marketing. I don't understand how people don't get it.

</comment></comment><comment><USER4> CBT aka mindfulness these is just good tool to have overall. I have had my share of bad experiences at my job from automaticity and adaptive, impulsive response. Here is what I learnt from being mindful:

1\. When faced with making a choice, you _remember_ more vividly how the bad choice hurt you last time. 2\. Put it another way, that promise I made to myself after that big mistake is harder to break. Pertinently, the reasons that justified the promise and the benefit of keeping it are also _more lucent_. 3\. I tend to separate/check my emotional responses connected to a thought connected to bad memories.

I could preach shorter sermons, but once I start I am too lazy to stop...

<comment><USER5> I was going to challenge you on saying that CBT is the same thing as mindfulness.

Then I thought about it, and I think this is pretty insightful. CBT says there's a split second after the stimulus where you get to choose how you will think about the stimulus.

That's an awful lot like mindfulness, at least from a big picture standpoint.

<comment><USER6> Additionally, "mindfulness-integrated CBT" is a thing.

<comment><USER7> Yes, it's called DBT.

</comment></comment></comment></comment><comment><USER8> This is a cognitive blind spot for human beings - I am not sure if there is a name for it.

Some examples:

"The steelers were winning the whole game - they only lost because of that fluke fumble in the end zone when time ran out..."

"I was prepared and on-track for that job interview - if only the A train hadn't had a malfunction that morning and made me late..."

"If I hadn't taken that wrong step at the end of the trail, I wouldn't have torn my ACL ..."

These are bad conclusions.

Both teams played by the same rules and then time ran out and the other team won and _it doesn 't matter how they won_. Future predictions should be based on the win.

You were late to the job interview because you're a person that screws times up. That's much more useful information than anything you could have contributed at the interview.

I tore my ACL because my ACL was weak and was waiting to tear. If it hadn't been that step, it would have been a different one at a slightly different time.

This insistence (I am, myself, guilty) to look for exceptionalism in results rather than accept the obvious data that are being shown to us is something we need to become aware of - and avoid.

<comment><USER9> Actually, what you're proposing is a cognitive blind spot that is indicative of depression. I forget what the name of it is, but taking every minor setback or chance occurrence to be indicative of a fundamental, unchangeable character flaw is a symptom of depression.

<comment><USER10> I believe this is the psychology field of attribution theory, in particular _fundamental attribution errors_ [1].

From the article, the parent's "alternate conclusions" seem to be regarded as cognitive biases, while the "bad conclusions" are more objective and psychologically healthy.

So congrats, rsync, if you're "guilty yourself", you're in good psychological shape, according to wikipedia :)

[1] [https://en.wikipedia.org/wiki/Fundamental_attribution_error](https://en.wikipedia.org/wiki/Fundamental_attribution_error)

</comment></comment></comment><comment><USER11> > 1\. Recognize when their automatic responses might get them into trouble,

> 2\. Slow down in those situations and behave less automatically,

> 3\. Objectively assess situations and think about what response is called- > for.

I recently realized I have insecure attachment and have been working on overcoming it. The process I use is somewhat similar:

1\. Recognize when you feel anxious or insecure.

2\. Ask yourself what is causing it.

3\. Either fix it or accept it.

<comment><USER12> > 1\. Recognize when their automatic responses might get them into trouble,

> 2\. Slow down in those situations and behave less automatically,

> 3\. Objectively assess situations and think about what response is called- > for.

Some martial arts training teaches that. The more defensive martial arts, such as aikido, focus on that. Training in a defensive martial art might help impulsive kids. It teaches them that lashing out blindly is a quick way to lose, and that there are much more effective responses to an attack.

</comment></comment><comment><USER13> Pop psychology is the sweetest psychology.

</comment><comment><USER14> The moral lesson is to educate kids.

<comment><USER15> Educate them with what values?

<comment><USER16> The values which have, in the past, produced desirable outcomes.

<comment><USER17> That's begging the question.

Unless you state what you think are desireable outcomes, your statement means nothing

Tautologically speaking, your statement just says "Do the things that we think are profitable."

<comment><USER18> > _Unless you state what you think are desireable outcomes, your statement > means nothing_

Only if we start as some kind of visitors from Mars who don't know the earthly ways.

Else, the "desirable outcomes" are pretty much agreed upon, at least for most people: keep mentally and physically healthy, study, get a good job, support your family, be good to others, don't be a criminal (as in TFA), etc.

<comment><USER15> >Desirable outcomes are pretty much agreed upon

I disagree.

> Keep mentally and physically healthy

Some families I know argue profit above all things, comfort above all things. Morbidly obese families, for example, do not feel that physical health is an important value.

>Get a good job

I know families that value finding welfare loopholes to facilitate a non- working lifestyle.

>Support your family

I know people that very much _do not_ value supporting their family

>Be good to others

ISIS members do not value being good to non-Muslims. (they do not agree with your values)

>Don't be a criminal

Members of gangs generally completely disagree with this.

Somehow the person you're replying to is being downvoted for suggesting, essentially, that "people believe different things are important." Are we going to seriously argue against that?

</comment></comment></comment></comment></comment></comment><comment><USER19> Thought this looked familiar. It's from 2015, and was covered here before[1].

1: [https://news.ycombinator.com/item?id=9866632](https://news.ycombinator.com/item?id=9866632)

<comment><USER20> Thanks; added.

</comment></comment><comment><USER21> Needs 2015 in the title. "Published Jul 8, 2015"

</comment><comment><USER22> I don't think that these impulsive people do a single wrong thing that lands their in jail.

Rather, they are a constant nuisance to everybody around them, and eventually it gets them in trouble. What they get locked up for is probably not their first transgression.

They might not be criminals but they actively decrease quality of life for everybody involved. The kind of behavior people tend to leave with high school, and they should have left ever sooner.

I wonder if therapy will help them avoiding behaving like a bad apple, not just avoid getting caught with their eventual out-of-bounds act.

<comment><USER23> I don't think you fully understand what growing up in a terrible neighborhood entails. They aren't so much "a constant nuisance to everybody around them" as they are acting like many who are around them.

When you grow up in the hood and your father is gone (dead, in jail, never in the picture) and your mother is on crack and all of your friends and siblings are in gangs and/or on drugs and/or selling drugs, changing your destiny is a difficult proposition.</comment></comment>


Speech API for American English Local Dialect - <AUTHOR> Are there any APIs that can translate general English speech into American English's local dialect?<p>I had been looking for it but somehow I still could not find it among services provided by Amazon Web Service And Google Cloud <comment><USER2> Google's Speech API has a new TTS that can be tuned to match a voice with just 5 minutes of data. The Mozilla DeepSpeech/TTS devs were discussing the research paper about it in #MachineLearning on Mozilla IRC.</comment>


Blocking the high: one man's quixotic quest to cure addiction - <AUTHOR> http://mosaicscience.com/story/blocking-the-high <comment><USER2> This is absolutely amazing. Pez-dispenser-like abdomen implant that modulates the dosage of Naltrexone which, as the article suggests, "takes the high out" of opiates. Trick the body and voila, freedom.

"Methadone you always felt medicated, albeit subtly," says Dowsett, referring to the opiate given to injection users that is supposed to control cravings without inducing its own high. When he's on naltrexone, though, Dowsett says all that goes through his mind is: "God, I'm free."</comment>


The Trouble with Teaching Rape Law (2014) - <AUTHOR> http://www.newyorker.com/news/news-desk/trouble-teaching-rape-law

<comment><USER3> All seems reasonable enough, except for showing a documentary about child- abuse in class without even having the basic human courtesy to warn people of the contents.

If people can't wrap their heads around why that might be an unpleasant experience for certain people, then I find it hard to take their other opinions seriously.

You'd think, if the topic was at all important to them, which they repeatedly claim it is, that this utterly minor concession to logic and reasonableness might not be worth taking a stand against, yet apparently their right to spring upsetting material onto students without warning trumps their desire for well-educated lawyers.

How can there possibly be a political divide over this? I don't get it. My best guess is something like climate change, where people have to ignore reality because they don't like the policy responses that it points to.

<comment><USER4> > except for showing a documentary about child-abuse in class without even > having the basic human courtesy to warn people of the contents.

I didn't get the impression that the author disagrees with that. I guess just mentioning the fact that it's a documentary about child rape would do the job (rather than just hitting play, which I'm pretty sure they don't do).

As far as I'm concerned the article could have been written without mentioning that particular example.

<comment><USER3> I got a completely different message from that paragraph than you did. I just went back and read it again, and it seems even harsher and more callous the second time around.

The author clearly disagrees that advanced warning of potentially sensitive topics is warranted, which is a strange stance to take if the plan all along was to give advance notice when the topic was incest/rape/child abuse.

<comment><USER4> That interesting. I've read it a second time as well and I still don't get it. (Just to be clear: We're talking about the paragraph starting with "Something similar to the 'second rape' concept," right?)

> The author clearly disagrees that advanced warning of potentially sensitive > topics is warranted [...]

Are we talking about the documentary or any class on rape law in general? I think he would disagree with warning his students any time they talk about violent crimes (presumably that comes up a lot), but not disagree with warning them when he shows a documentary that contains very graphic descriptions of such crimes.

<comment><USER3> The key bit for me was the fact that students asked (after they'd seen the video) that they be given warnings about that kind of content. Which seems to imply that no warning was given. The rest of the paragraph seems to be the professor making the argument that giving such a warning would offend their principles in some way and that they have no intention of providing this courtesy in the future either.

</comment></comment></comment></comment></comment><comment><USER5> Ironic that the pseudo-psychology of 'triggering' is being used to coerce those who experienced trauma into a state of perpetual victimhood. Rather than dealing with their experiences via safe discussion and exposure and eventually moving beyond them, they are urged to see themselves as irreparably damaged and fragile; to alter and censure their own identity, behaviour and the behaviour of others.

<comment><USER6> In addition it is failing to give today's students the tools they need to handle tomorrow's victims

</comment></comment><comment><USER7> Disgusting, PC nonsense getting in the way of education on an important subject.

</comment><comment><USER8> > Trials often included inquiries into a woman's sexual history, because of > the notion that a woman who wasn't virginal must have been complicit in any > sex that occurred.

I thought it was to counteract arguments that an apparently virginal woman would not engage in such sordid behavior, therefore making it apparent it must have been rape - when she had in fact engaged in such acts and they would not have been out of character in the least.

There is this claim that sexual history will hopelessly bias the jury, therefore should be banned - but they seem quite happy for other biases - <USER2> that women don't aggressively engage in casual sex or that young girls have no concept of sexuality - to stand and influence the outcome.

</comment><comment><USER9> The page just does not scroll on my phoone's Chrome browser.

Waited for the page to fully load, swiped my finger. Nothing.</comment>


Measuring high voltage in millimeters and other HV probe tricks - <AUTHOR> https://hackaday.com/2016/12/08/measuring-high-voltage-in-millimeters-and-other-hv-probe-tricks/ <comment><USER2> > Most of my work these days is below 30kV,

Oh. Good. "Most".

I figured 2kv/mm back when, using scavenged neon sign transformers and coat hangers for probes. The graph in the article is enlightening.

That i survived making and living with bare wire Jacob's Ladders says something about my teenage years. To this day I cant decide if it says something good or bad, however.

Further enlightenment: [http://teslamania.delete.org/frames/longarc.htm](http://teslamania.delete.org/frames/longarc.htm)

</comment><comment><USER3> Curious... If I need to measure 70kV, but HV meters go up to 40kV, can I put two meters in series?

<comment><AUTHOR> Theoretically, yes, but only if the HV meters are ideal resistors. In practice, voltage ratings cannot be added for good reasons.

The safe and legal way is building a separate HV probe for the meter, internally, it can use a resistor divider. The individual resistors will have a much lower voltage rating, and still, they cannot be added, you don't get a new rating by connecting them in series. But you can test and certify the unit as a whole, so the probe itself gets a new input and output voltage rating.

Another example is oscilloscopes. Almost all scopes are only rated for CAT II measurements, which meant it's only safe to use the scope to measure the voltage inside an appliance plugged in an outlet that is far away from the electricity entry panel (even when the working voltage rating is the same, different Categories [0] have different overvoltage handling ratings for unexpected transients, the closer to the entry, the higher it needs to be). Technically, you cannot even use an oscilloscope to measure the AC lines directly - it requires CAT III certification (yeah, most people keep breaking this rule). However, what you can do is building a standalone, differential, active HV probe as your "input front-end", and design and certify the probe to handle the hazardous voltage, in this case the oscilloscope only samples its safe output and acts as a data acquisition and analysis system.

[0] [https://en.wikipedia.org/wiki/Measurement_category](https://en.wikipedia.org/wiki/Measurement_category)</comment></comment>


Clojure/Conj 2017 – Opening Keynote by Rich Hickey [video] - <AUTHOR> https://www.youtube.com/watch?v=2V1FtfBDsLU <comment><USER2> No one in this thread is yet talking about the content of this talk, which I think is interesting. Rich is doubling down on dynamic typing. As the world is gradually moving to more statically-typed languages (Rust, Swift, Go, Elm, Purescript, Typescript are all popular tools that come to mind), Clojure remains in the embrace of dynamic typing, and this talk is an interesting look at the perspective of why that is, and adds perhaps a little bit to the debate between static and dynamic typing.

I admire Rich a lot, but I also admire John Carmack, and it is apropos that yesterday another comment was shared on another post here [0] about _his_ opinions on static typing, and how in just a few years (his talk was in 2013), the industry as a whole has made considerable changes in its opinions of static typing; according to his talk, in 2013 most of the industry was still not convinced of the benefits of static typing.

[0] [https://news.ycombinator.com/item?id=15460604](https://news.ycombinator.com/item?id=15460604)

<comment><USER3> I think its a mistake to directly compare the experiences (and conclusions) of these two exceptional programmers.

Rich Hickey explains at the start of his talk where he is coming from, what the context of his development work, and he calls it "Situated Software". His background and the context for his development is building information systems in organisations where the rules are messy and no doubt change often. One of the things he calls out explicitly in his talk is the messiness of dealing with the "Two for Tuesday" rule in one of the systems he worked on. He also spoke about how different working in that domain was, to doing compiler development.

John Carmack's experience and domain expertise is building high performance game engines. I'd argue this is closer to compiler writing in the sense that it is a much more rigid problem than say having to serve the needs of an organisation whose requirements may change often and in seemingly arbitrary ways, and usually on a tight deadline.

I am not trying to elevate one domain over the other. They are different kinds of problems, and have different kinds of limitations and constraints applied to them. As such I don't think its any surprise that the priorities for each of these developers is different.

Choosing between more dynamic or more static approaches without considering the context in which you are working in, is a mistake.

<comment><USER4> This is an outstanding point. When watching this talk, I got the distinct impression that Rich has simply worked on a very different class of problems than the ones I have worked on. As we all are wont to do, we extrapolate our experience to the whole universe. But that's not always the right thing to do.

I would say that for the most part, a statically typed language can do the same things a dynamic language can do, but not the other way around. Another commenter mentions the Any type, but I don't think that's it. It's maps. Rich wants to be able to combine maps with a union operation, take subsets of keys, etc. And that is exactly what maps afford. I'd rather work in a language like Haskell where I can use strong types when I need them and drop down to untyped maps when I need them than a language like Clojure where all I ever have is the maps.

Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you. I'd rather work in a language where my compiler can help me this way than in one where it can't.

<comment><USER5> _" a statically typed language can do the same things a dynamic language can do, but not the other way around"_

It's interesting you'd say that, as I'd consider the opposite to be true. There are functions that are trivial to write in a dynamically typed language, but are hard to statically type. For instance, the `assoc-in` function in Clojure.

 _" Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you."_

You don't necessarily need static typing to give functions some form of type signature or specification.

<comment><USER6> I also find the opposite to be true, as you do.

The human mind and human problems, operate more like a dynamic language. To put it in a simple, silly example: When i tell you to "cut something with a scissor", the scissor doesn't specifically cut paper; there are many things that can get cut by a scissor. Or when you take a pot, put it over the stove and boil water, you do it and the pot is not specifically designed to boil water, the pot can heat anything; so you can say that many operations (verbs) in real life do not get performed in a "static typing" way, but in a "dynamic typing" or at least "duck typing" way.

<comment><USER7> Both of those examples are trivially modeled with typeclasses (java style interfaces will also cut the mustard here too).

Your paper example I would have a "Cutter" and "Cuttable" type classes to describe things that cut and can be cut. In languages like Haskell this only involves a couple extra lines of ceremony over writing a "cut" method on each type.

The pot example is even cleaner with types and show the power of them. I'd have a Pot typeclass that can heat things. I'd have a liquid class for all liquids that water implements and finally a boil free function that takes a pot and a liquid. Exactly as expressive but now with compile time checking.

<comment><USER8> All this is covered in Rich's talk. Your Cutter and Cuttable are different from my Knife and Cuttablito. When your program needs to talk to outside world, it all becomes messy.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> > "SPJ in an excellent series of talks lists these advantages of types... the > biggest thing left out of clojure..."

> "The biggest merit he says is in software maintenence, and i really disagree > with just a lot of this. it's not been my experience; the biggest errors are > not caught by these type systems; you need extensive testing to do real- > world effectiveness checking."

I think Rich is dead wrong on types not providing good tools for _software _maintenance__.

He is attempting to discredit types because they do not catch _all_ errors, or the toughest errors; that's fine, I don't agree with people that would say types do that for you.

I think dynamism is great for speed of development and flexibility; but my impression about trying to debug and maintain clojure code is that one has to spend time tracing back the source of errors and shape of maps (pre-spec).

Those issues are somewhat mitigated by having a good type system, and what you loose on the flexibility going with types, is a trade that I think returns much more that what you give up.

<comment><USER6> > _" The biggest merit he says is in software maintenence, and i really > disagree with just a lot of this. it's not been my experience; the biggest > errors are not caught by these type systems; you need extensive testing to > do real-world effectiveness checking."_

I think I fully agree with Rick Hickey on this, and I have mentioned the same before here in HN. The biggest and most serious errors are not caught by the (statically checked) type systems.

I agree that simple type errors that, on a dynamic system without compile-time checks are not caught, will be then caught at runtime and you will say "oh, i need to get back and correct this, damn it". But this is a minor annoyance, that takes small time compared to the bugs i'm mentioning in the previous paragraph; bugs that can take days to be resolved.

<comment><USER10> What kind of errrors do you think are not caught with static typing? Usually people who say this aren't familiar with languages that have type classes...

<comment><USER6> > _What kind of errrors do you think are not caught with static typing?_

Citing awj's post above:

 _" Some of the biggest errors are subtle failures in the implementation of business logic."_

Other examples:

\- bumping into unkonwn bugs of a library you are calling \- implementation of an external (library) function behaving differently than the documentation \- various memory leak problems \- locking issues \- race conditions

etc

<comment><USER10> >"Some of the biggest errors are subtle failures in the implementation of business logic

Static typing can prevent errors in business logic.

>various memory leak problems - locking issues - race conditions

All are bugs that static typing has had tremendous success in preventing. Have you any experience in a HM like type system?

<comment><USER6> > _All are bugs that static typing has had tremendous success in preventing._

Please do elaborate, it could be a great post.

But If you mean to say that locking issues can be prevented because you can apply STM (software transactional memory) by using suitable Monads, then, well, i can also have STM in a dynamic language, even applying it by wrapping code in an "atomic" context (i.e. see the STMX library for Common Lisp) so the statements contained within are performed atomically (and thus guaranteed to work or either roll-back.)

As for memory leaks, Haskell (if that's the HM language you had in mind) automatically manages memory, so I would guess this isn't a problem at all. However, automatic management memory management is orthogonal to "static vs dynamically typed".

Thus, i'm curious, and yes, i don't have enough experience with HM-type languages, which should be the way to go if one wants to use static typing...

<comment><USER11> > i can also have STM in a dynamic language

How can you roll back failed transactions without explicitly typed effects?

<comment><USER9> Clojure tracks and rollbacks the STM-bound variables according the STM rules; it is not intended to prevent you from doing other effects inside those transactions; you are supposed to have an understanding not to do that in the transaction blocks.

It helps a bit that most clojure datastructures are immutable/persistant by default.

<comment><USER11> In other words Haskell's STM prevents bugs that Clojure's merely supposes the programmer not to have written.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><AUTHOR> I submitted this link before I had watched the whole thing. As someone who has only dabbled in Clojure I think there are a lot of interesting ideas in there but found the type-system bashing pretty off-putting.

I am now watching his "Simple Made Easy" talk [1] after I have heard it recommended on a few functional programming related podcasts. Again really interesting stuff but I encountered another cheap shot at typed functional programming ("You can't use monads for that! Hurr hurr hurr").

Given how well received these talks seem to be by people that enjoy programming with advanced type systems I would have have really expected a more balanced discussion and some acknowledgement of the trade-offs between dynamic and statically typed functional programming.

[1]: [https://www.infoq.com/presentations/Simple-Made- Easy](https://www.infoq.com/presentations/Simple-Made-Easy)

<comment><USER2> The new Conj talk is certainly an interesting look at one man's (or one community's) look at static typing. However, as much as I admire Rich, some of the points he made don't resonate with me, particularly the one about how compile-time checks to catch minor bugs in syntax are not a particularly useful feature of static typing. I certainly disagree. As someone who writes Clojure all day long right now for a living, I am constantly dealing with runtime errors that are due to minor typos in my code that I have to track down, and this time would be greatly saved by having a compiler tell me "on line 23 you looked for :foo keyword in a map but you meant to type :foobar, so that's why that was nil" and many other similar woes.

I love Clojure but I really miss static type checks.

The other item in his talk I do not agree with, he says (slightly paraphrasing) "in static typing, you can pattern match on something 500 times but if you add a case, you have to update those 500 matches to handle the new case, when really they don't care about this new case, only the new logic needs to consume this special case, it's better for the producer to speak directly to the consumer". Well, in languages like OCaml, Swift, Haskell, it is a feature that pattern matches much be exhaustive. This prevents bugs. In most cases, I'd expect that if I add a case to an enum, the chances are good my existing logic in pattern matches should know about that. Maybe not all, but a lot of them will. It's nice to have the compiler guide you to those places.

I certainly like how fast I can write programs in Clojure, and I like the minimal amount of code that makes refactoring and rewriting fairly straightforward since there is not a lot of time investment in the existing number of lines, and I like the incredible elegance of Clojure's approach to functional programming.

But I do miss having much greater compiler assitance with typos, mis-typed argument order to functions, mis-typed keyword names, etc. Would really save a lot of time.

<comment><USER12> > As someone who writes Clojure all day long right now for a living, I am > constantly dealing with runtime errors that are due to minor typos in my > code that I have to track down, and this time would be greatly saved by > having a compiler tell me "on line 23 you looked for :foo keyword in a map > but you meant to type :foobar, so that's why that was nil" and many other > similar woes.

i wonder if this is because it really takes a quantum leap in one's development style between <insert your previous programming language> and clojure/<insert your favourite lisp>? as long as your environment allows for effortless evaluation of code you're writing, you'd be getting this feedback no slower than the edit/save/compile/retry cycle.

<comment><USER2> If your typos are triggered by UI events, then you often won't see these problems until interacting with your UI (I work mainly in Clojurescript). Further, these typos may not get noticed at all for a long time if a code path is never taken. Of course, that's what unit tests are for. But writing tests takes time also. I'm not sure it's worth the trade off to spend the time writing those tests that I could spend writing in a more statically-typed language that would catch some things that tests wouldn't be needed for. (Besides, writing tests for UI stuff is pretty hard).

I am griping, really, because I cannot stress enough how nice it feels most of the time to write Clojurescript. But in complex projects, there is not doubt that a lot of time gets spent on things that wouldn't need to be spent if the language had even a very basic type system to back up the syntax for some things.

<comment><USER13> My team recently settled on TypeScript instead of ClojureScript, as TS is the safer bet, more familiar, more consistent with the existing project's tooling, etc. But man... I've taken a handful of files and written them in both TS and CLJS. CLJS is just so much shorter and elegant. I sometimes think we made the wrong decision.

<comment><USER14> ClojureScript is great with Reagent or re-frame... If you write Angular use TypeScript. If you use React, ClojureScript! It's a match made in heaven.

<comment><USER13> Yeah. I've built toy apps with re-frame, and really liked the way the code looked. But my team is pretty Jr other than me, and I wasn't sure if ClojureScript would work well for us as a team. VS Code is our editor of choice, and it is just really a good environment when paired with TypeScript.

Also, my experience with Rails really has me fearful of doing any serious, big work, in a dynamic language.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> Rich is always a great speaker. Sometimes he gets a little esoteric and you hear all the monad loving neck beards giggle in the audience. Then again, he invented a lisp that runs on the JVM. Usually though he is very pragmatic and real-world. I love how often he says things like "the type checker in my compiler doesn't matter to the users of my program" or, "the perfect, most beautiful search algorithm doesn't matter if it can't fit into a web page and work when your user hits enter"

So... even if you don't care about Clojure or functional programming I'd certainly suggest listening to some of Rich's talks. He's a very sharp guy but his format is very friendly.

</comment><comment><USER16> I have been to a local Clojure conference once. Most of the guys who started practising Clojure was inspired by Rich Hickey's functional programming talks. I'm wondering how many such BDFL inspire users to adopt something new just with talks!

<comment><USER17> I didn't even know about Rich Hickey talks and "Simple made easy" when I decided to start learning Clojure. I came to conclusion that I needed to learn a Lisp after learning Emacs and dubbing in writing small elisp functions. I had no idea and was really surprised when I found out how awesome Lisp can be, so I looked at the current state of Lisp at the time. And then after learning a bit of Clojure and Clojurescript and seeing things people were building with it, I quit my job. I really wanted to use Clojure full-time. Never in my life I ever before have had this urge to learn a language and build things with it.

</comment></comment><comment><USER12> are people without a degree in type systems even allowed to express their opinion on dynamic vs static? because if their opinion is automatically viewed as inferior whenever a person with a degree chimes into a discussion, isn't dynamic typing stuck in the limbo of not having competent defenders and the only path for a defender to become competent is to spend years of their lives learning the opposite thing?

i think (as a person without a degree in type systems) that relative success of Erlang and Clojure are a testament that pragmatic approach works, and that is not in any way evidence that static typing is inherently bad or can't work.

<comment><USER18> Relative success? In what sense? As far as the jobs market is concerned Erlang/Elixir and Clojure have failed to make an impression. Ok, Wallmart, Bleacher Report etc. but search Indeed.com by job title and you'll get what I mean.

<comment><USER12> that's why it's called "relative", isn't it?

Erlang and Clojure are undoubtedly a success for me in terms of productivity.

Erlang is undoubtedly a success in a telekom industry since 90s, where extreme reliability is a basic requirement. isn't static typing promoted as a path to achieve reliability "once it's compiled"? go figure.

imo, that majority of developers are being indoctrinated into false-OOP paradigm is rather unfortunate historical curiosity than a success indicator.

</comment></comment></comment><comment><USER19> I understand that Rich Hickey is a fantastic developer, a productivity multiplier, and an industry leader, but I have a few issues with his portrayal of types.

In this talk he has repeatedly cherry-picked the most negative examples from every type system, while ignoring the more positive, simple, and elegant type system features. E.g., he talks about languages which represent product types as `int * int * string * string * ...`, i.e. as nameless clumps of data, while ignoring that those same languages usually support much richer record types which are of course product types with field labels.

Then he talks about Java types being non-composable while ignoring generics and row polymorphism in other languages. He talks about Clojure maps being powerful while ignoring the same maps with the same power in static languages. He talks about type system complexity while ignoring the mental burden of keeping the types in your head in a totally dynamic system like Clojure. Ironically, he even talks about how you can handle five to seven arguments mentally before getting lost, while ignoring that in a dynamically-typed system you're left to your own devices handling much higher cognitive loads.

Another beef I have here is he repeatedly talks about pattern-matching in 500 different places, and having to go and update them, while ignoring the fact that _no one does that,_ we actually do write modular code with data structures as abstract as possible and try to provide powerful, general- purpose functions which manipulate them instead of exposing all the variant cases for raw pattern-matching. PM is great, but it's still important to limit its use for scalability reasons.

I don't know to what extent he has explored the type systems of ML-family languages. But he certainly does not present them accurately here. I would love to see him just do a debate-style talk with someone really well-versed in type theory as well as practical systems, say, Yaron Minsky of Jane Street.

<comment><USER9> Rich would probably do very well in a debate-style talk. The art of argumentation is very subtle. If you think there'd be a blowout that entirely discredits the dynamic typing camp—that would rather be like expecting a debate that completely invalidates one side of republican/democrat debate. There are simply core values each side has that are very hard to persuade someone out of. mostly, what people do is "talk to their base/tribe", and then snipe the other side with cheap shots.

<comment><USER19> I'm not even looking for a winner-take-all argument. I just want someone to be able to immediately correct Rich when he says something wacky about static typing. E.g.,

'You don't have labelled arguments!'

'You have labelled arguments since Standard ML i.e. _at least_ the '80s, e.g.:

        $ poly
        Poly/ML 5.7 Release
        > fun add { num1, num2 } = num1 + num2;
        val add = fn: {num1: int, num2: int} -> int
        > add { num1 = 1, num2 = 0 };
        val it = 1: int

<comment><USER13> Yeah. He's aware of that. I think he's generally talking to Java crowds, so the static typing experience of the general programmer is pretty bad.

That said, I liked this talk and agreed with much of it.

<comment><USER19> There are options on the JVM outside of Java, from Kotlin to Scala to Whiley to Eta, or even OCamlJava which might be nearing a release. An alternative to dismissing static typing entirely based on Java, is looking at other languages which have less verbose, more elegant type systems on the JVM. RH is ignoring that aspect completely. Understandable, based on his worldview and experience, but not very accurate.

</comment></comment></comment></comment></comment><comment><USER20> Can we please get this man a Wikipedia page now?

[https://news.ycombinator.com/item?id=5619680](https://news.ycombinator.com/item?id=5619680)

<comment><USER21> Wow that man Artem Karibov quoted in the link has some problems.

</comment></comment><comment><USER22> Any transcripts yet?

</comment><comment><USER23> I always enjoy Rich's and Cognitect's increasingly futile attempts to bait and switch the Clojure community into using his expensive proprietary database, Datomic.

I love Clojure, it's a beautiful language, but its march has stalled, perhaps even reversed, and I lay the blame of that squarely at the anti-community practices of Cognitect, especially surrounding Datomic.

<comment><USER12> is anybody forcing you to use datomic? no.

is cognitect doing something to clojure that is beneficial exclusively for datomic? no.

has cognitect banned you from making pull requests that improve clojure? no.

has cognitect banned you from forking clojure and fixing whatever you think they've done with some evil intent? no.

so wtf are you on about?

<comment><USER24> > _has cognitect banned you from forking clojure and fixing whatever you think > they 've done with some evil intent? no._

I don't understand this objection. The value in a free software project, and especially of a programming language, is primarily in its community and the expectation of a future around the project, not in the existence of some code somewhere. It's extraordinarily hard to build a community around a fork, and if you need to fork to do reasonable things, that's a legitimate criticism of the people running the original community.

(That said, if you only need to fork to do unreasonable things, that's good community management. I don't pay nearly enough attention to Clojure to know what's actually happening - but I have seen both of these cases in other free software communities.)

<comment><USER12> > It's extraordinarily hard to build a community around a fork

it follows quite naturally, that reasoning to fork doesn't have enough community support, which only means one thing - you're wrong about clojure community's opinion on state of things around clojure.

<comment><USER25> Adding to that, there are a few forks of popular projects that were quite successful: io.js, libreoffice, mariadb.

<comment><USER26> Blink, Ubuntu, neovim, LibreSSL, Plex, XOrg, etc, etc.

If you're dedicated to it and correct about your choices, forking doesn't seem to hamper anything.</comment></comment></comment></comment></comment></comment>


A Wait-Free Queue as Fast as Fetch-And-Add [pdf] - <AUTHOR> http://chaoran.me/assets/pdf/wfq-ppopp16.pdf <comment><USER2> I've been playing with wait-free algorithms some time ago but never got anywhere meaningful.

A wait-free queue for multiple consumers and multiple producers would be kind of the holy grail when it comes to wait free data structures. Is it MPMC though? I skipped through the PDF and could not find a definitive claim…

Also, big thumbs up to Chaoran for putting the implementation on GitHub: [https://github.com/chaoran/fast-wait-free- queue](https://github.com/chaoran/fast-wait-free-queue) The code looks like it is easy to follow and it's MIT licensed.

<comment><USER3> Ah! I thought I recognised that name/domain.

He previously saved my bacon with `node-finish` - a Node.JS library that let's you fire off a bunch of tasks, and wait for _all_ to finish before executing a callback.

What a hero.

<comment><USER4> Promise.all?

<comment><USER5> But for callbacks, which is much more of a pain.

There was a time before Promises, you know.

<comment><USER4> OP said "recently".

Even before Promises, wrapping up some callback functions and tracking async task state isn't rocket surgery.

<comment><USER3>
        > OP said "recently".

I did? I think you misread my "previously".

Regardless, I was new to JS and not up to the task of implementing it myself. @chaoran's library did exactly what I needed.

An appreciative note didn't need to turn into criticism of the project's worth.

</comment></comment></comment></comment></comment></comment><comment><USER6> So I just recently learned how a rather simple ring buffer implementation is lock-free and doesn't even need primitives like CAS (although it does need memory barriers).

In spite of this, all the literature about lock-free queues that I see (including this one) is for some kind of linked structure. Any reason for that?

I guess one big limitation of the ring buffer is that it only works for a single reader and single writer. Although maybe you can work around that using CAS primitves...

<comment><USER7> I'm not sure you're aware of this, but there's a distinction between wait-free and lock-free.

[http://rethinkdb.com/blog/lock-free-vs-wait-free- concurrency...](http://rethinkdb.com/blog/lock-free-vs-wait-free-concurrency/)

This might be relevant to answering your question.

<comment><USER6> I became aware of the distinction when I skimmed the paper. But I couldn't figure out what it meant in this case.

Specifically does the _every thread_ requirement rule out algorithms where there only one reader and one writer is allowed? If not, then this ring buffer is wait-free, since there is no CAS-and-retry step. (Of course an operation can _fail_ because the queue is empty/full, but that is still completion).

<comment><USER8> there are several aspects to consider when talking about a concurrent queue:

* multiple/single producer, multiple/single consumer

* progress guarantees (wait-free, lock-free)

* bounded vs. unbounded

* whether it's double-ended or single-ended

* memory reclamation being dependant on a GC or not

* which atomic operations they need (e.g. some require double-CAS)

What you mention is a spsc bounded queue. this is about a mpmc unbounded queue. And from skimming the paper is seems like it does not require a GC either.

So it's far more powerful.

Of course spsc queues still have their use even if we have a good mpmc queue, they generally incur less overhead.

</comment></comment></comment></comment><comment><USER9> For context, the traditional wait-free queues are only wait-free for one side, writing or reading. The other side has to spin in an atomic fetch loop, waiting for the wait-free multi-step operation to complete.

The double wait-free queue from the paper is using a technicality to achieve its status. The spinning operation is replaced with a loop over all the threads doing opposite (multi-step) operations, finishing them for threads that may be blocked in the middle of the steps. It's not that it doesn't spin, but the spinning is bounded by the number of threads. Edit: Actually, spinning is bounded by O(#threads^4) according to the paper.

</comment><comment><USER10> Funny, I had a coworker several years ago whom built this exact algorithm. The performance of our system increased literally orders of magnitude.

I've been slipping it into systems for a couple years now :D

<comment><USER11> Did his algorithm include the helper concept that makes this wait-free, or are you just talking about the fetch-and-add queue part?

</comment></comment><comment><USER12> Is it better than: [http://www.1024cores.net/home/lock-free- algorithms/queues/no...](http://www.1024cores.net/home/lock-free- algorithms/queues/non-intrusive-mpsc-node-based-queue)

Which is what Rust mpsc uses. It has a big advantage in being short and easy to understand.

<comment><USER13> Dmitry Vyukov queue is awesome, but as the author himself notices, a slow writer can prevent the reader to make progress, and as such is not even non- blocking.

</comment></comment><comment><USER14> Hmm.. why bother with a complicated approach now that transactional memory (Intel TSX) is available in HW now? What are the advantages and disadvantages of this approach vs using TSX?

<comment><USER15> Hardware transactions as implemented by TSX are not wait free. There is no guarantee that any TSX transaction will ever commit, so you need a non- transactional fallback path to guarantee forward progress.

<comment><USER14> Do you know the relative performance of Power7 and Haswell? The implementation is not wait-free on Power7 because of HW limitation, and has significantly lower throughput than Haswell in the benchmarks.

</comment></comment></comment><comment><USER16> So how different is this from something like [https://github.com/chanks/que](https://github.com/chanks/que)</comment>


FlameStower - USB charger powered by fire - <AUTHOR> http://www.kickstarter.com/projects/flamestower/flamestower-charge-your-gear-with-fire

<comment><USER2> I think they got the idea right, but designed it around the wrong source first. Using fuel to power my devices means I need to carry more fuel with me. Why do that when I can just carry cell phone backup batteries like this one: [http://mylimeade.com/](http://mylimeade.com/)

Instead this should have been designed around something I can throw in a campfire with some sort of protective spiral metal cabling to snake out of the fire to a box with a USB connector. The metal cabling could be similar to those used on high temperature oven thermometers.

<comment><USER3> The cable isn't likely to be the limiting feature here. The method of energy conversion doesn't just require heat, it requires a _temperature gradient_ across the device. Here they're putting the tip in the fire to heat it, and the little bowl at the back full of water is used to cool the other end, thus getting a good temperature difference.

In contrast, throwing hte whole thing into the fire might work briefly while the heating was uneven, and the water hadn't all boiled off, but as soon as it reaches the same temp all over, no more power. And if it's all in the fire, even the water evaporative cooling isn't going to help much, vs when it's out of the direct flame/hot air stream at the edge.

I imagine you could design a in-fire version using a heatpipe to transfer energy out to a radiator/cooler somewhere, but that would be much more fragile and/or expensive.

What we really need is MEMS (or at least, really teeny, zero-maintenance) Stirling engines :)

<comment><USER4> MEMS (or stirling engines) don't help you there either -- as long as it's all in the fire, you have trouble extracting energy.

All heat engines run off of a temperature gradient, which is limited by Carnot's theorem to a maximum efficiency of (1 - Hot/Cold). If your heat source temperature is the same as your heat sink temperature, you get zero energy out of it.

The bigger the difference between the heat source and heat sink in your engine, the more energy you can extract.

<comment><USER5> Fully agree, the only small remark being that it's

η = 1 - Tcold/Thot

and to put in perspective: If your metal rod on one side of the peltier element (that's inside the device) is at 150°C = 302° = 423K and the cold side (water reservoir) is at 20°C = 68°F = 293K the maximum achievable efficiency is 30%.

In practice you'll waste a _lot_ of energy (probably the flame outputs about a kilowatt of power, normally you'd comfortably use it to heat a kettle of water or canned spaghetty or...) for a meager 2W or 3W of power to your cellphone. That's because the energy transfer from a flame to a simple rod is very, very inefficient.

</comment></comment></comment></comment><comment><USER6> First thought: "Awesome - power for phone if everything goes to hell."

Second thought: "Wait, if everything goes to hell, there's not going to be any cell service."

Third thought: "Oh well, at least I'll have Candy Crush."

<comment><USER7> Perfect for using your offline cached copy of Wikipedia to recreate civilization after the apocalypse?

<comment><USER8> Maybe? It'd probably harder than you think: [https://www.youtube.com/watch?v=BVxOb8-d7Ic](https://www.youtube.com/watch?v=BVxOb8-d7Ic)

<comment><USER9> I think that is the whole point of bringing wikipedia along. Pretty sure you could reconstruct most of civilization from it...

<comment><USER10> Not sure, it's high on modern theoretical content but not very on low-tech practicals, e.g. no information on how to go about prospecting for copper or iron.

<comment><USER11> You won't need to prospect for iron or copper if civilization collapsed, the fact of the matter is we could never be "bombed back to the stone age" as there is soooo much processed iron just lying around - everywhere.

<comment><USER12> We just need technicals on recycling and smelting, cooling, rolling, machining, etc.

<comment><USER13> Myself and a couple other guys did the due-dillegence for a proposed documentary about Stone Age to building a functional electric calculator.

The starting point would have various ores as they came from the Earth.

Glass and metal working are key.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I brought a BioLite stove with me on a recent camping trip and loved it. That had other advantages: easy to get a fire going during a very rainy week, no fuel to carry (in the White Mountain National Forest, anyway) and it was pretty easy to cook with.

USB charging didn't seem all that useful at first, but with a USB-rechargeable LED lantern it ended up being great. If that's all you really needed, you could get it from the FlameStower without the battery + fan machinery of the BioLite, I guess.

<comment><USER15> I've been having an internal struggle regarding the purchase of a BioLite stove. The primary reason I haven't is because of it's weight. As a backpacker, the stove is just way too heavy to carry on a trip (weekend trips, fine - but anything longer it would have to stay behind).

The FlameStower seems much more practical for longer trips because of it's weight / bulk.

<comment><USER16> [https://www.globetrotter.de/outdoor-kueche/sturmkocher- spiri...](https://www.globetrotter.de/outdoor-kueche/sturmkocher- spirituskocher/?q=kocher&listMode=grid)

well the Biolite seems to be a top notch stove plus it charges your devices. The link above are comments of buyers, nearly all positive. For a stove you prefer gas?

<comment><USER17> The biolite weights 33oz. My MSR pocket rocket weighs 3oz, + 2-8 oz for the fuel. (I generally take 4oz for short trips). Even with an external battery pack I could still be almost 1lb lighter than the biolite.

Biolite is totally cool, but 2lbs is a LOT for backpacking, you can get tents lighter than that.

</comment></comment></comment></comment><comment><USER18> Last year there was the PowerPot, which is the same principle on the bottom of a cooking pot [http://www.kickstarter.com/projects/david-toledo/the- powerpo...](http://www.kickstarter.com/projects/david-toledo/the-powerpot)

<comment><USER19> another similiar project: [http://www.biolitestove.com/](http://www.biolitestove.com/)

<comment><USER20> I own one of these and it is fantastic, even if you don't use it to charge your phone (which I do) you get to scavenge fuel instead of carrying it and that vortex of flame boils water only slightly slower than most normal portable camp stoves and it is just damn cool to look at.

<comment><USER21> these are great - also good for starting campfires

</comment></comment></comment></comment><comment><USER22> Stoves with built-in USB chargers already exist as a commerical product. For example, check out [http://www.rei.com/product/846334/biolite-wood-burning- camps...](http://www.rei.com/product/846334/biolite-wood-burning-campstove)

</comment><comment><USER23> A DIY version by Timo Noko [1]. The same guy has been tinkering also with some other interesting stuff [2].

[1] [http://www.youtube.com/watch?v=R1A5qc872Ks](http://www.youtube.com/watch?v=R1A5qc872Ks) [2] [http://koti.welho.com/tnoko/](http://koti.welho.com/tnoko/)

</comment><comment><USER24> And here I was hoping I could finally buy a USB powered flamethrower.

</comment><comment><USER25> Oh man, I do and don't want to see the efficiency and carbon-output per joule generated of this device compared to actual grid energy. Not to mention particulate air pollution.

Although it will depend on what you are using for the source of your 'fire', it's not gonna look good.

This is a weird idea.

<comment><USER26> It's not intended to be an efficient clean power source. It's intended for people who want to do something like hike the Appalachian Trail and want to be able to charge their devices using the same fire they use for cooking / heat.

</comment></comment><comment><USER27> I'm going to get one so I can carry coal instead of batteries.

</comment><comment><USER28> Great for the post-apocalyptic world!

Maybe good for short term natural disasters or outdoorsy types who want to stay connected.

I find some humor in that having a cell phone on and charged is still 'off the grid' (I know they meant electrical grid).

</comment><comment><USER29> I wrote about something very similar last year, the BioLite camp stove: [https://bbot.org/blog/archives/2012/06/13/biolite_camp_stove...](https://bbot.org/blog/archives/2012/06/13/biolite_camp_stove/) (I'd argue that the BioLite is a better product, despite being twice as expensive, since it can run on wood.)

A problem with both products that they use the thermoelectric effect, which is miserably inefficient: The BioLite generated 2 watts from a thermal power of 5500W, for a thermodynamic efficiency of 0.036%

Solar panels, on the other hand, don't need to burn anything at all.

</comment><comment><USER30> I see this product as having two target markets:

1) Outdoorsy people who carry fuel and find themselvea away from electricity.

2) People who are going to burn their homes down trying to recharge their iPhones during power outages.

</comment><comment><USER31> It looks like something one could craft in Minecraft so I like it, seriously though, I've been shopping for a solar charger just in case there is some unforseeable disaster and I need to be able to keep the GPS and compass working at least. This looks like a good alternative, I looked at two of the competing products in the comments here but this one seems to me to keep the most distance between the heat source and the electrical cord while still staying out of the way of my cooking. The collapsible design seems like a good idea too.

</comment><comment><USER32> 2-3W? That means it's only a 0.5A, right? A lot of devices don't even charge properly off of a 0.5A USB source.

<comment><USER33> While they may not fast charge, many of the devices will trickle charge - simply because the original USB 2.0 spec didn't require high amperage. In fact, 2.0 spec allowed for a max of 5 'unit loads' with a unit load of 100 mA (5x 100 mA = 0.5A). Putting out more than that was against spec unless the port was specifically marked as a 'charging port' per the Battery Charging specification (you may have noticed USB ports with battery icons next to them).

It wasn't until USB 3.0 that the limits were increased. Additionally the Battery Charging spec was re-written to increase limits for charging ports.

If you can plug your device into any single USB jack on a computer (not just ones with a battery icon next to them) and it will charge, it will likely charge with this project.

<comment><USER32> In my experience, 0.5A chargers (and PC USB ports) are functionally useless for charging many modern smartphones and tablets, especially after a deep discharge. There has been many times I've put on a device to charge on a 0.5A source and come back to find its battery completely depleted. The charging will fail to keep up with the device's idle energy consumption.

<comment><USER34> If your device uses more than 0.5A for idle energy consumption, your phone's 1500mAh battery would only last 3 hours. Standby time on most smartphones is usually at least 12 hours, consuming between 100-200mA. Being able to turn the device off, and charge for 3 hours while cooking dinner and hanging out around the campfire is _awesome_.

</comment></comment></comment></comment><comment><USER35> This, to me, isn't very novel. Why can't you just wait for the sun to come up and carry a 140g solar panel? I suppose this may be useful in a very rare emergency situation, but otherwise, nahhh.

$ don't lie, though, and it looks like they have almost reached their goal.

<comment><USER36> It's not new at all, see this 1956 kerosene radio: [http://blog.modernmechanix.com/kerosene- radio/](http://blog.modernmechanix.com/kerosene-radio/)

</comment></comment><comment><USER37> Congrats to Adam (and Andy) -- went to elementary/middle/high school with him, been neat to watch this product evolve over the past year on facebook.

</comment><comment><USER38> Does anyone bother to create something similar that would help 3rd world electricity problems? oh, I forgot... they don't have smartphones.

<comment> c-oreills Biolite does this. Traditional stoves produce a huge amount of smoke which is bad for people breathing it. BioLite reduces the smoke, but they found that men were usually in charge of purchasing decisions and weren't around when cooking was being done, so had no incentive to invest in the smokeless stoves. Adding electricity to the stove meant that men were more likely to buy, thus helping their family's health.

[http://www.bbc.co.uk/news/business-24116000](http://www.bbc.co.uk/news/business-24116000)

</comment></comment><comment><USER39> a superior technology is known for several years, but still can't make ends meet

[http://www.forbes.com/sites/michaelkanellos/2013/01/31/why-a...](http://www.forbes.com/sites/michaelkanellos/2013/01/31/why- are-portable-fuel-cells-such-a-flop/)

</comment><comment><USER40> Mongolians will love this.

</comment><comment><USER41> I like it but I'm curious how this compares to a hand crank like on one laptop per child

<comment><USER42> Handpower delivers about max 20W per hand to a bike with both hands. With electromechanical efficiency, 20W per hand comes out to around 1-10W per hand, depending on hand speed and generator efficiency. [1] [http://www.amazon.com/Bicycling-Science-David-Gordon- Wilson/...](http://www.amazon.com/Bicycling-Science-David-Gordon- Wilson/dp/0262731541) [2] [http://dspace.mit.edu/handle/1721.1/69801](http://dspace.mit.edu/handle/1721.1/69801)

</comment></comment><comment><USER43> Of limited practical use, but I can see it being a hot present for outdoorsy people.

<comment><USER44> I don't agree. In Africa where not all ppl have access to the electricity grid it have practical use. Together with google internet balloons plan it might be a game changer.

<comment><USER45> BioLite is making a generator/stove for daily home use in 3rd World conditions: [http://www.biolitestove.com/homestove/overview/](http://www.biolitestove.com/homestove/overview/)

They also have a camping version: [http://www.biolitestove.com/campstove/camp- overview/features...](http://www.biolitestove.com/campstove/camp- overview/features/)

<comment><USER44> In a quick look it seems like the same product with different marketing slogan

<comment><USER46> Biolite appears to have been formed in 2009, so much before this product: [http://en.wikipedia.org/wiki/BioLite](http://en.wikipedia.org/wiki/BioLite)

The tech used in either of these ([http://en.wikipedia.org/wiki/Peltier_effect](http://en.wikipedia.org/wiki/Peltier_effect)) has been known of since the 1800's - in the tech world we usually see it applied to exotic cooling solutions for microprocessors.

<comment><USER3>
        <pedant>

Strictly speaking it's not the Peltier effect, but the Seebeck effect. One is the inverse of the other; Peltier junctions produce a temperature gradient when current is passed through, and Seebeck ones generate a current when exposed to a temperature gradient.

I think for the most part you can actually run either type in either mode, but the design and materials differ for optimal efficiency across the 2 modes.</comment></comment></comment></comment></comment></comment>


A Brief, Animated Introduction to Programming with Python - <AUTHOR> https://ourcodestories.com/markm208/Playlist/16 <comment><AUTHOR> I am the creator of a new medium to guide others through code examples. I call them playbacks.

This is an intro book on Python. I have also written books on [C++]([https://ourcodestories.com/markm208/Playlist/2](https://ourcodestories.com/markm208/Playlist/2)) and [Clojure]([https://ourcodestories.com/markm208/Playlist/4](https://ourcodestories.com/markm208/Playlist/4)). I am looking for feedback on the medium.

I am also looking for others to write their own books/tutorials and to create professional portfolios to show potential employers how they do their work. Storyteller is a free, open source tool to create playbacks. Our Code Stories is a site to host them. Authors can post their playbacks for free, make them private, or charge a fee for others to access them.

If you are interested in creating your own playbacks and need a little help getting started reach out to me and I'll help.</comment>


Startup Recruitment for Founders - <AUTHOR> https://rocketshp.com/startup-recruitment/ <comment><USER2> I find it interesting if not a little disconcerting that the equity table has the startup hiring a COO at 2% - 5% equity but no CTO and the closest it has listed is "Lead Engineer" at 0.5% - 1%. I suppose there could be a VP of engineering under that chart since it doesn't specify what type of VP.

This article seems to be propagating the myth that engineers need MBA types more than they need engineers.

The article also advocates heavy contracting.

Speaking from experience, if you are contracting out most of your software engineering and don't have a CTO type role who knows what good code is and knows how to manage the contractors, you are in for a really bad time when you do decide to bring on full time software engineers. You risk overpaying and risk having completely unmaintainable code that doesn't scale with your business.

Conversely, much of what a COO does can be done by the CEO at early stages.

Of course, no two startups are the same. In fact, a bad CTO can be more damaging that not having any. Which is why it is important you screen your hires well. However, your milage may vary.

<comment><USER3> a bit offtopic but -- imo technical folks don't need MBAs. However you _do_ need a person who can sell. That person might have a technical background, might happen to have a MBA (though frankly very few MBA types are very good salespeople), but honestly the skill is orthogonal to anything else.

The question you ask an engineer is "can you build this?". The question you ask a business cofounder is "can you sell this?"

<comment><USER4> so true. to get a bit pedantic, there's generally no 'business' to 'administrate' in the early days, so an 'MBA' is... not specifically useful. To the extent an 'MBA' is useful, it's probably in doing things that are tangential to the degree itself.

</comment></comment></comment><comment><USER5> A curious bit:

> Rookies: Won't always request equity, Experienced: More likely to request > equity

Is this really true? I would think it's the opposite--the rookie has not yet felt the sting of swapping salary for worthless equity and would be more likely to value equity higher, whereas the veteran will know better...

The whole section on equity convinces me that I'm not joining a start-up any time soon. 1-3% for hires 1-5? Fractional percentages for everyone else? What a joke. That's what passes for early-stage equity? These are the people who are literally building your company. People seem to be falling for it though, and start-ups seem to have no trouble hiring, so who am I to argue?

<comment><USER3> The veteran knows that equity is something you can negotiate hard for and is very negotiable.

Regarding equity comp for early hires, presumably the founders have already done significant derisking by finding initial product market fit, secured initial capital, built a prototype, have buyer interest/commitments, etc.

Every time I see complaints about single digit % compensation, I wonder how many of the people complaining will go out and actually put in the work of validating a market and getting the initial momentum for sales and meeting 100 "investors" and "pseudoinvestors", put in years of networking to even be loosely connected to the money network, getting 90 rejections to get your first $500k, and the shitwork of setting up a corporation and doing all this work out of pocket in exchange for 10x the equity. I mean literally no one is stopping you from setting up a company that you own 100% of the equity of.

<comment> UK-AL This post hightlights the real barrier to entry for startups. Being connected with people with the money.

It's normally the people with best connections and the best relationship with investors and not the best product market fit that can get funding.

</comment></comment></comment><comment><USER6> > Ask them if they'd like to have a quick phone call

And that's how you fail to get introverted people interested. I'd have to be deaperatelly pissed off at my current position to want to voice chat about "great new opportunity" without getting all the details in writing first...

</comment><comment><USER7> A wise move to write a guide like this as content marketing. The key market for rocketshp appears to be early stage founders. This is a problem faced by that segment for sure.

<comment><USER8> Searching shows up ~nothing for rocketshp or Mark Hayes, I would take their opinion with a big grain of salt.

</comment></comment><comment><USER9> Typo in the first sentence...

> Has your startup has reached the point where you need to make your first > hire?

</comment><comment><USER10> is there a guide on how to hire reliable contractors if you're too busy currently to work on your saas product?

</comment><comment><USER11> İnteresting</comment>


Show HN: "Adventurize" Minecraft advertising platform built with Meteor - <AUTHOR> http://adventurize.com

<comment><AUTHOR> We've just launched the open beta for Adventurize, which is a new advertising platform for Minecraft that allows advertisers to display ads on servers through a plugin. The website is built with MeteorJS, and is currently open for server owners only during the 1-2 month testing period.

You can read more in the official launch post: [http://www.minecraftforum.net/topic/1874092-adventurize- laun...](http://www.minecraftforum.net/topic/1874092-adventurize-launch/)

</comment><comment><USER2> I didnt understand the point of your website until I read the comments section. Perhaps post something describing what your site does in clear detail.

<comment><AUTHOR> Thanks for the feedback! Did you mean, post on the website, or post it on HN in another post?</comment></comment>


Raspberry Pi GPIO Pinout - <AUTHOR> http://pinout.xyz/ <comment><USER2> Would be nice to have a good single & clean reference site like this for many boards, not just RPi.</comment>


Nanobox is now free for developers - <AUTHOR> https://news.nanobox.io/new-nanobox-pricing/ <comment><USER2> Never heard of it but the product looks pretty compelling. Is there any provision for running multiple apps on one server instance?

<comment><USER3> That's the highest requested feature! Should be available in Q1 of 2018.

<comment><USER4> Add my vote for this one. I'm running a dokku server right now for this reason but would rather not.

<comment><USER5> There's a full roadmap at [https://trello.com/b/4zbckEIY/nanobox- roadmap](https://trello.com/b/4zbckEIY/nanobox-roadmap) and users' votes are the main factor for deciding what gets done in what order.

</comment></comment></comment></comment><comment><USER6> I am a very happy user of nanobox, i was able to deploy to linode after migrating from GCP app engine, relatively painless. Their whole suite of tools made it easy to not scew up that..first deploy to the new server _shudders_

<comment><USER4> Were you running a docker image on custom VMs on app engine? Just wondering how easy the transition was. Are you still running on Google cloud instances via nanobox?

<comment><USER6> i was using flex python 3 engine, not custom. I am not running on GCP anymore, I switched to Linode because it's cheaper ($5 instance) and deployed using nanobox. I deployed to app engine using app engine deployment, Linode using nanobox

</comment></comment></comment><comment><USER7> I don't think this is what the designer wanted: [https://i.imgur.com/kHOwE5v.png](https://i.imgur.com/kHOwE5v.png)

You need scripting and/or UA sniffing to display your blog? Too bad.

</comment><comment><USER8> I haven't heard of this before, but it looks like it's similar to Docker compose or maybe a layer on top? And insight or comparison as to why you would use this over other tools.

<comment><USER9> It's a layer on top. I think it simplifies deployment to various services that may or may not support Docker so well.

<comment><USER5> It's more an alternative to Docker Compose, though it does sit on top of Docker itself...

</comment></comment></comment><comment><USER4> Can anyone using this give us a report on the developer experience? Even simple quality of life stuff is useful like how easy is it to see logs for running containers, how fast are the deploys, etc.

Thanks!

<comment><USER10> I can't give a full report, I strongly suggest that your try. But we are currently evaluating nanobox to see if we made the move from a another provider and for now it is very satisfying. Really easy to use and setup, very nice dashboard for monitoring your apps . Logs are present and easy to access but generally we prefer to use alternate/external solutions for log tracking (not related to nanobox) but it gives a good start if you can't externalize them. Deployment are as fast as other providers we tested. Deployments run on both local and server side, I will need more deployment to give a complete speed feedback. Scaling has never been easier. Honestly I really like the product and the team behind is very present on their slack channel to get you up and ready. So far so good.

<comment><USER4> Sounds very promising, I will give it a try. Thanks!

</comment></comment></comment><comment><USER11> I need this. To bad it doesn't support deployments to packet.net.

<comment><AUTHOR> Nanobox does support Packet deployments:

\- [https://news.nanobox.io/packet-now-officially- supported/](https://news.nanobox.io/packet-now-officially-supported/)

\- [https://docs.nanobox.io/providers/hosting- accounts/packet/](https://docs.nanobox.io/providers/hosting-accounts/packet/)

Their full list of officially supported cloud providers is here: [https://docs.nanobox.io/providers/hosting- accounts/](https://docs.nanobox.io/providers/hosting-accounts/)

</comment></comment><comment><USER12> Can't access the website. The SSL cert is wrong.

<comment><USER13> You can access it. The LE cert expired about a month ago though

<comment><USER3> fixing now. Thanks for the heads up

</comment></comment></comment><comment><USER14> Certificate problems.

</comment><comment><USER15> renew your cert!

[edit to point out the irony in "Nanobox essentially becomes your DevOps team"]

<comment><USER5> Cert was renewed, but apparently there was a bug in how the system chose which cert to use? Not certain how it had access to the old one, still, though.

Fixed, now, either way.</comment></comment>


What do you think of my Front-End? - <AUTHOR> http://www.happyapps.io/features

<comment><USER2> Looks cool.. :)

<comment><AUTHOR> Thanks :)</comment></comment>