Can the Dutch Get the World to Eat Bugs? - <AUTHOR> http://www.theatlantic.com/magazine/print/2011/09/bug-nuggets/8599/

<comment><USER2> It should be relatively easy to both engineer completely controlled "farms" for growing insects and to selectively breed variants that are more suitable for food. We should be able to produce a creature that would be a great deal more palatable to the western palate as well as easier to process.

Have you ever seen a wild strawberry or a wild carrot? Many examples of the former are little mean things whose entire surface is seed, and the latter can have the consistency of wood. (Sometimes fully domesticated carrots can have woody parts in the center.)

In general, the domesticated versions of plants are an order of magnitude tastier than their wild ancestors, and a great deal of adaptation can be managed with animals as well. Insects, with their small size and short lifespans, should be even easier to domesticate, once we set our minds to it.

<comment><USER3> While true, it's not -too- necessary. There's a pretty good set of insects that are already 'palpable to the western palate'. Grasshoppers/crickets when stir fried pretty much tastes like crunchy chicken (at least that's my 5 year old memory of it).

Also, it's pretty clear that the 'western palate' is super open to change from social pressures. You guys seem to love raw fish now.

<comment><USER4> sashimi does have the upside of still being fish, which westerners are used to.

</comment></comment></comment><comment><USER5> Pass the word: rich, cultured people eat lovely healthy organic _DUTCH_HERE_. This script has gotten people to eat cooked snails, raw fish, and various microbial infection byproducts before.

They're only "bugs" if you're incompetent at marketing.

<comment><USER6> Perhaps "land shrimp"? Seriously, I agree that putting the word "bugs" in the name of the products does not bode well for attracting any but the adventurous and novelty-seeking Americans/Europeans.

<comment><USER5> Even worse, they're describing it as chicken nugget replacements: i.e. for those people who are too poor to buy McNuggets now you can get fat on BugNuggets. I'd have difficulty coming up with a less appealing narrative for food if I tried.

<comment><USER7> What do _you_ suggest as affordable and practical sources of protein for poor people?

<comment><USER5> Are we talking Africa poor or American poor? For Americans: beef, pork, chicken, fish, or anythig else. At the top of the list of problems poor Americans don't have: dang, poverty is greatly restricting my protein and calorie intake.

For everybody else, seaweed, legumes, or whatever. You really don't need Western levels of protein consumption, as evidenced by e.g. it being a minuscule portion of the traditional diets of Non-Western nations without peacetime food problems, like, say, Japan.

Plus after they're rich they can overconsume meat like we do. It practically defines being a rich country when your local poor people eat meat regularly.

<comment><USER7> I'm talking about Americans working 2 or 3 jobs who don't have the time, and honestly don't have the money either (yes, such poverty _does_ exist in the US, perhaps you are just lucky enough to have not encountered it...) needed to cook meals with sufficient nutrient value for their (often quite large...) family. The result of this is that malnutrition is a _very_ real problem among children of poor families. The worst part about this is the problem is infectious. Children that grow up without proper nutrition will be intellectually and physically stunted, dramatically increasing the chances that when they eventually have a family their children will end up the same way.

Statements like _"local poor people eat meat regularly."_ are just flat out ignorant. I've known families that _save up_ for bulk rice. _"Seaweed, legumes or whatever"_ is so unrealistic it is absurd. People with time and money have those luxuries.

<comment><USER5> _Statements like "local poor people eat meat regularly." are just flat out ignorant._

[http://www.heritage.org/research/reports/1990/09/how-poor- ar...](http://www.heritage.org/research/reports/1990/09/how-poor-are-americas- poor)

Search for "Food Consumption of Poor Children", read the following two paragraphs. USDA data shows poor people eat a) more protein than non-poor people (yes, really), b) more meat than average citizens of many rich nations (like Japan or the UK), and c) _vastly_ more meat than average citizens of Mexico/Brazil/etc.

<comment><USER7> heritage.org? You have to be fucking kidding me. Do you even know who they are?

<comment><USER5> They appear to be the group with USDA data to back up their claims regarding a measurable fact of material reality. If you have better data, please, do share.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> Well, Mexico is a place where you can find places to eat insects fairly easily. Like "chapulines" (grasshopers)from Oaxaca. They are very crunchy and tasty. ;)

The mexicas (from prehispanic era) used to have a variety of insects in their menu.

Here you can find a table with a list of some of the species currently included in people's diet: <http://entomologia.net/idolina.htm>

It's in Spanish, but they have the scientific order and family name.

</comment><comment><USER9> > Crickets, for example, convert feed to body mass about twice as efficiently > as pigs and five times as efficiently as cattle.

So, with about the same efficiency as chicken. <http://en.wikipedia.org/wiki/Feed_conversion_ratio>

</comment><comment><USER10> Over here in Asia people have been eating all kinds of bugs for years. A bowl of beetles with chili powder is a favorite bar snack in Thailand.

<comment><USER11> Please tell me the beetles are already dead before being served.

<comment><USER10> Definitely. Generally fried and liberally seasoned. I haven't had the courage to try one myself yet.

</comment></comment></comment><comment><USER12> Interesting. I wonder how bugs stack up for heme-iron and the other nutrients (aside from protein) that one gets from red meat. It's diversity of nutrients, and the body's efficiency at absorbing them, that for me make the strongest case for an omnivorous diet. It's the environmental cost of raising animal protein that for me is the strongest argument for vegetarianism.

<comment><USER2> Diversity is often overlooked when people think about diet. The longest lived populations also tend to have preserved a tremendous amount of diversity in their diet. Folks living in the hills of Sicily can sometimes incorporate material from several dozen different kinds of plants in a single meal. In contrast, it's not unusual for a North American to make a meal with corn, peas, potatoes, and some form of meat. That's between one or two orders of magnitude less diversity.

I've tried purposely maximizing dietary diversity, and it seems to make a difference for me.

</comment></comment><comment><USER13> Why is it I have no problems eating shrimp or lobster, but the thought of insects disgusts me? Shrimp and lobster are crustaceans which are arthropods just like insects.

<comment><USER14> Because one provide a large continuous chunk of meat, and the other doesn't? Also are insects gutted or do you end up eating their entire intestinal track?

<comment><USER15> Clams, oysters, and mussels aren't gutted.

<comment><USER16> ... and neither are crustaceans. They're mollusks, and they're delicious when properly cooked (especially mussels, if you ever visit the north of France, Belgium or the Netherlands, you'll miss something if you don't try them).

I find oysters disappointing though, especially for their high price. They're just textureless, wet salty things.

French people also eat snails. With truckloads of garlic, to mask the dirt taste, they're quite nice to eat too.

</comment></comment></comment></comment><comment><USER15> A piece of advice I learned in the publishing industry: When a headline ends in a question mark, and the question can be answered either "yes" or "no", it's never yes.

</comment><comment><USER17> It's interesting to note that this is not a new concept. I've long been enamored of Vincent Holt's 1885 "Why Not Eat Insects". It the work of a very earnest Victorian gentleman trying to figure out how best to deal with the protein needs of "the poor", leading to the conclusion that the upper class must lead the way by changing their attitude toward the consumption of insects:

      It is hard, very hard, to overcome the feelings that have
      been instilled into us from our youth upwards; but still I
      foresee the day when the slug will be as popular in
      England as its luscious namesake the Trepang, or sea-slug,
      is in China, and a dish of grasshoppers fried in butter as
      much relished by the English peasant as a similarly
      treated dish of locusts is by an Arab or Hottentot. There
      are many reasons why this is to be hoped for. Firstly,
      philosophy bids us neglect no wholesome source of food.
      Secondly, what a pleasant change from the labourer's
      unvarying meal of bread, lard, and bacon, or bread and
      lard without bacon, or bread without lard or bacon, would
      be a good dish of fried cockchafers or grasshoppers. "How
      the poor live!" Badly, I know; but they neglect wholesome
      foods, from a foolish prejudice which it should be the
      task of their betters, by their example, to overcome.

Full text (with many recipes) online here: <http://bugsandbeasts.com/whynoteatinsects/>

<comment><USER4> The only argument that matters to me:

 _10 kilograms of feed will generate just 1kg of beef, 3kg of pork, and 5kg of chicken. It generates 9kg of locusts._

And that is why we should be eating insects, end of story.

<comment><USER18> Note that it also yields 10 kg of feed, which sounds more appealing to me than locusts. Unless these locust nuggets turn out to be the best tasting thing ever, I think I'll have my feed with a side of chicken, and leave the locusts to the more adventurous.

<comment><USER4> Yes, but you do need some protein. Not to say you have to eat bugs to get it, but it's a step up from beef or pork.

One other thought- you assume you can or would eat bug feed.

Locusts, for example, eat: leaves, flowers, bark, stems, fruit, and seeds. While it is true humans can eat all of these things, it is typically only from select plants. When was the last time you ate a rice plant, or bark that wasn't Cinnamon?

</comment></comment></comment></comment><comment><USER19> I'd try it right away. I dig the idea and I wouldn't mind at all moving away from having to eat cattle.

But what I didn't from the article get was, how is eating insects considered in line with the vegatarian mindset? Insects are living things, too, no?

<comment><USER20> Well, I guess it depends on what particular mindset. I do not eat meat, because I think that most animals that are commonly eaten are sentient, and I believe intentionally killing sentient animals is wrong.

The question of course is, what animals are sentient. I don't know. But I find it plausible that, say worms, are not really sentient. And from that perspective it's pretty ok to eat worms. Since I do not know where to draw the line, I play safe and avoid meat, but others would choose differently.

Some of my friends are also vegetarians, not because they think killing animals is wrong, but because they believe animal farming has a negative impact on the environment. If insect farming does not have the same impact, it could be a reason for them to consider eating insects.

<comment><USER21> I don't want to attack you or anything, just want to point out that no living thing wants to die. There is evidence that even plants have some form of sensation [1]

[1] <http://www.nytimes.com/2011/03/15/science/15food.html?_r=2>

<comment><USER4> Of course living things don't want to die. But if you decide that _all_ living things including plants deserve to not be eaten or harvested, your menu becomes incredibly short.

I mean, you are not left with _absolutely nothing_ to eat, but all you've got that I can think of is dairy, fruit and nuts. You could technically eat grains, but harvesting enough grain without killing the plant is difficult.

</comment></comment></comment></comment><comment><USER22> I'm curious to see how many people turn out to be allergic to insects. Again drawing the analogy to shellfish which are among the most common food allergens. This is not to say that eating insects is a bad idea in general, though.

</comment><comment><USER23> We already eat bugs.

You should see what's allowed to get into the ingredients by the FDA in food processing plants.

<comment><USER24> That's probably because it's heathly. _People in rice-eating regions, for example, typically ingest significant numbers of rice weevil (Sitophilus oryzae) larvae, and this has been suggested as an important source of vitamins.[37] ...

3.1.2 Wheat flour shall be free from abnormal flavours, odours, and living insects. 3.1.3 Wheat flour shall be free from filth (impurities of animal origin, including dead insects) in amounts which may represent a hazard to human health.

According to the U.S. Food and Drug Administration's The Food Defect Action Levels booklet.[39] Contamination on the average of 150 or more insect fragments per 100 grams of wheat flour, or below poses no health hazard._

<http://en.wikipedia.org/wiki/Entomophagy>

<comment><USER25> It is not always healthy.

For instance it is suspected that the prevalence of peanut allergies is connected to the fact that stored peanuts usually have cockroach infestations. The FDA limit on acceptable levels are 30 insect parts per 100 grams. (See [http://www.fda.gov/food/guidancecomplianceregulatoryinformat...](http://www.fda.gov/food/guidancecomplianceregulatoryinformation/guidancedocuments/sanitation/ucm056174.htm) for verification.)

</comment></comment></comment><comment><USER26> A few weeks ago, feeling adventurous, a few coworkers and I journeyed to midtown New York to try the grasshopper tacos at a Mexican restaurant.

When mine arrived, I fearfully picked up a grasshopper and brought it to my tongue...

...and had to restrain myself from gobbling the rest up by the fistful.

In less than a second, my opinion of grasshoppers had gone from "creepy" to "tasty." I expect most others won't be much harder to convince.

</comment><comment><USER27> Lobster were once seen as cockroaches, now the rich want them. So, anything's possible with enough marketing.

</comment><comment><USER28> Why did I click on this? I completely lost my appetite when reading this and some of the comments.

</comment><comment><USER29> Did the dutch get the world to eat Pannekoeke, Bitterballen, Haring or Uitsmijtern? Sadly not.

</comment><comment><USER30> What happened to that project that would develop meat in vitro?

<comment><USER31> Here's a fairly recent article: [http://www.scientificamerican.com/article.cfm?id=inside- the-...](http://www.scientificamerican.com/article.cfm?id=inside-the-meat-lab)

I'm a lot more enthused by the thought of petri-dish-grown steak than mealworm.

</comment></comment><comment><USER32> No

</comment><comment><USER33> Wageningen, that's down the road from where I live! I wonder if I could get a free sample...

</comment><comment><USER34> So disgusting. There are millions of vegeterian options available. But as usual, get science involved and people make it more complicated.

<comment><USER35> I'm thinking vegetarian options are not necessarily more eco-friendly than this solution, which is 10-100 times more efficient than pigs. Factory-grown bugs take little room. The corn around here (I'm in Iowa) take up 96% of the land surface of the state.

Organic vegetables take up - more ecosystem. More passes thru the field to baby them, more loss to insects etc so less yield. And they are labor- intensive so load them with the cost of raising the humans that tend them. Humans are Really eco-unfriendly, especially when used as laborers.

<comment><USER36> How much of that corn grown is for human consumption, and how much becomes cattle feed?

<comment><USER37> I vaguely remember it being some huge number, like 80%-90%? The rest of it goes to ethanol and high fructose corn syrup and other processing. I'm pretty sure the amount of corn that is grown for humans to eat as corn directly is (much?) less than 5%.

A quick Google search showed roughly similar stats.

<comment><USER38> Ethanol is now using about 40% of the US corn crop.</comment></comment></comment></comment></comment>


Making a classroom discussion an actual discussion - <AUTHOR> http://crookedtimber.org/2016/09/12/making-a-classroom-discussion-an-actual-discussion/ <comment><USER2> The point of this being a mentally taxing exercise is an interesting and welcome one. Especially from someone that seems good at it.

I will try to keep "yes, this is hard" in my mind on future conversations. Especially with my family. The point is I want their points. Not that I want them to bend to my will.

</comment><comment><USER3> Ok, naive question: how "21 separate and not that great tutorials, all happening at the same time" is not what a class is supposed to be? If I go to the class, I expect to learn information from the teacher. There will be occasional classmate information that will be interesting but I expect 90% of my time spent gaining information from the teacher.

Since when do we expect classes to be social events? If I want to learn with other learners then I don't really need a teacher, or a classroom, actually. I need a forum, a la stackoverflow, and a good doc/book.

<comment><USER4> No, that's not what a class is supposed to be.

The view of a classroom as being a conduit where the teacher transmits knowledge from their brain into the students is entirely outdated. That's not how learning works.

To learn, you have to process information, build understanding. One way that has been shown to work quite well at this is to make students explain to each other and challenge each other.

You may have heard the phrase "I didn't really learn this until I had to teach it", which is another reflection of the same thing; the act of explaining to other people improves your understanding.

Not to mention that it also improves your skills at things like making a coherent argument and working with other people, which are quite useful skills to have in life.

If this doesn't work for you, you don't need the teacher either. After all, what can they tell you that you can't just read in the textbook?

<comment><USER5> >That's not how learning works.

I've learned lots of information from classes by just paying attention to the lectures and doing no out of class studying/conversations unless I had particular trouble with something, in a wide range of subjects like physics from Newton's laws to relativity, various history classes, music theory, epistemology, calculus. Is this that unusual of an experience?

<comment><USER6> You may just be predisposed to that form of instruction. Many other folks aren't.

One of my most interesting experiences was US history Class in high school. The teacher was supposedly boring as hell (like that guy from ferris bueller). I kind of went into a trance in but recalled quite a bit of facts and did great on his tests.

Now did I really grok the subject? Perhaps not.

</comment></comment></comment></comment><comment><USER7> Are there any HN members who have experienced a flipped classroom approach at university in the last 5 years? I'm referring to use of MOOCs for lectures and classroom for facilitated discussion. Would you share your experiences?

<comment><USER8> Ignoring the MOOCs for a second, isn't this essentially how a seminar has traditionally operated? Everyone reads the assigned papers/books/whatever on their own time, and then shows up in a room for a discussion. If so, these were my favorite classes. The class operated as follows. For each class meeting, the syllabus listed 3-5 "core" papers that were "officially required" reading, along with a smattering of background material. One or two students would give a brief overview of the material for ten or fifteen minutes before they (and the profs) led the discussion.

\- There needs to be a hook for the discussions. In many cases, the profs baited that hook by choosing papers that contradicted or complemented each other. For example, it's fairly easy to get a self-sustaining discussion going on whether Theory A seems plausible. Papers 1-3 show data that they claim supports it, but the experiments in 4-5 seem to refute it. Hashing this out-- and watching others do so--is probably even more useful than whatever the ostensible topic of the class may be.

This works really well when there is a legitimate debate. It can sorta kinda work if there _was_ some debate but the question has been settled pretty conclusively. Some students can be asked to play the losing side (e.g., the pro-luminiferous aether folks in a physics class). It does not work well at all for things like methods papers or situations where the debate is so remote or unfathomable (e.g., I would not teach calculus or programming like this)

You can sometimes get away with "what did you like or dislike about this paper?", but this often veers into a discussion of methodology (which may or may not be the goal).

However, I think a good selection of papers typically led to good discussions, while even the best-prepared list of discussion questions couldn't do much to provoke interesting debates about a random walk through the literature.

\- Everyone needs to have a pretty solid background. We tried a similar format with 1st and 2nd year undergrads and it was not a smashing success. The conversation kept bottoming out in places where students did not know enough to ask/answer questions or connect it with other things that weren't explicitly in the reading (This is probably more of an issue with science or social science; I imagine it happens less in literature classes). The undergrads were also very reluctant to question published papers.

One class attempted to circumvent this with a mixed format. The Thursday classes were lectures. A guest professor would lecture for ~90 minutes on their field of research. These served as background material for 3-5 papers that were the assigned reading. On the following Tuesday, students (+ the professors coordinating the course) discussed the papers. The guest lecturer would return for the discussion and act as a sort of 'expert witness' who could answer questions.

\- This format works well when the atmosphere is fairly casual and the students are comfortable with each other. This probably imposes an upper limit of 15-20 students/class or so.

<comment><USER7> Thanks for sharing</comment></comment></comment>


Orwell and China: Nineteen Eighty-four in Chinese - <AUTHOR> http://ibisbill.wordpress.com/2014/01/02/nineteen-eighty-four-in-chinese/

<comment><USER2> I find blogs like these rather impressive: long discursions on a topic of interest, as opposed to the snappy marketing pieces that I see much more often. Clearly the author is a dedicated researcher in his field.

It's odd and ironic, but yes, the book has been repeatedly published in China and is widely available, even from a state-run bookstore. Perhaps this illustrates the point that, if you treat something like it ain't no thang, people don't notice and focus on it (the "forbidden fruit syndrome"). Or, alternatively, that most people don't care about political satire as long their lives are improving materially.

A quote by Orwell from the article, showing his ethnic/national sensitivity in 1947:

 _We all have these feelings in one form or another. If a Chinese wants to be called a Chinese and not a Chinaman, if a Scotsman objects to be called a Scotchman, or if a Negro demands his capital N, it is only the most ordinary politeness to do what is asked of one. The sad thing about this alphabet-book is that the writer obviously has no intention of insulting the "lower" races. He is merely not quite aware that they are human beings like ourselves. A "native" is a comic black man with very few clothes on; a "Chinaman" wears a pigtail and travels in a junk– which is about as true as saying that an Englishman wears a top hat and travels in a hansom cab. This unconsciously patronising attitude is learned in childhood and then, as here, passed onto a new generation of children._

(The article explains that 'Negro' was a term of respect at the time.)

<comment><USER3> Well, that's interesting. I wouldn't think of China as a prime example of an Orwellian state, but rather something out of Huxley's mind.

China is capitalist, industrial, workers are salaried, the culture is material-focused, and more than half of the population is non-religious. Politically alienated rather than politically manipulated. Censorship is not based on hate speech, but justified as a way to protect the internal market, a capitalist and pragmatic view.

That's "Brave New World" to me.

A prime example of Orwellian state in my opinion would be DPRK, or Cuba, or what Venezuela is turning into. Two major points of "1984" are a population kept poor and hate speech.

<comment><USER4> China has its Orwellian moments, just read the newspaper or watch the news inside the country, as do cuba and Venezuela, but none of those are Orwellian states. Spot on a about North Korea, Kim Sung Il must have read 1984 and used it as a template. Note, however, that North Korea is hardly the poorest state.

<comment> guard-of-terra Outside poorest central asia and sub-saharan africa, North Korea is the poorest.

Certainly was in 90-s. Now it's getting better thanks to small business, trade with China and limited agri reforms,

<comment><USER4> There are probably some countries in SE Asia that are poorer (New Guinea, Myanmar, Laos, maybe even Cambodia). If DPRK reunited with ROK (under the ROK government, of course), it would probably only take a generation or so to catch up to ROK. They have a culture of high literacy and industry, only their government is holding them back (less developed countries have much less to work with).

<comment> guard-of-terra Even ex-DDR still did not catch up with the rest of Germany - and one generation did pass. And they were just 3x poorer, where DPRK is more like 15x poorer than ROK.

I doubt that SE countries you listed lost 100k+ people due to hunger (in 90-s and 00-s anyway). Sure they are poor, but they can handle it better than command economy. They're used to be poor, not shocked by it.

<comment><USER4> There are just SE countries that haven't been rich and have or are are going through their fair share of poor governance. My only point was that there are plenty of other ways to be poor, even poorer. Now I have to get back to my view screen in my beijing apartment, 大哥 is watching.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Off-topic slightly, but it's worth mentioning Louisa Lim, former NPR / BBC's China correspondent had recently published the book The People's Republic of Amnesia: Tiananmen Revisited. It's worth a read.

It covered the current state of political life in China from 1989 ~ now. The whole concept of "1984 in China" is very much a topic talked about in the book. In the book it mentioned there was a case where regional government authorities forced the public to go back to work and school on Sat. and Sunday as a way to prevent crowd to gather for a weekend protest. It's rather fascinating.

<comment><USER6> Whoa, I thought she was still reporting from China. I guess she is now persona non grata.

Funny story: She came through Dallas a few months ago for a book signing tour. At the last minute I had to travel out of town. I sent my Taiwan-born gf in my place to see her speak and get a book signed. She was apparently one of the few, or the only, Asians in attendance. Louisa Lim even remarked how few Chinese have shown up to her book signings. So, even in America, Chinese here have a blind spot for recent Chinese history.

<comment><USER7> > _" So, even in America, Chinese here have a blind spot for recent Chinese > history."_

And it's getting worse. I've noticed a trend in recent years where the new Chinese bourgeoisie and intelligentsia are outright dismissive of books and other media addressing these topics, attributing them as Western slander driven primarily by envy over China's economic miracle.

</comment></comment></comment><comment><USER8> Ironically, this website is hosted as a wordpress.com subdomain, so it cannot be accessed in China (I can't open it here)

</comment><comment><USER9> I wish there was an auto summation tool or keywords of major topics for every link. I wonder how many good articles are closed immediately after they're opened simply because of the word count.

Back on topic, do they actually print copies of the translated version in China? It would be mighty ironic if that is the case.

<comment><USER10> _George Orwell's Nineteen Eighty-four is just the kind of book that you would expect to be banned in China – all that talk of Big Brother, Newspeak and the rewriting of history is far too close to the bone, surely. So I was amazed to come across it on open sale in a state-run bookshop, in Yanji 延吉 on the North Korean border in fact. Nineteen Eighty-four is all over the place in China, it turns out.

A Chinese website lists no fewer than 13 translations published in the PRC between 1985 and 2012, and it's easy to find at least three or four downloadable or online translations on a quick internet search._

They are indeed printed in China, and are openly sold in China, without any government censorship surprisingly.

<comment><USER11> > They are indeed printed in China, and are openly sold in China, without any > government censorship surprisingly.

Censorship applied to materials about censorship seems like it's made for the Streisand effect—look at the vibrant samizdat culture in the soviet union. A much better way is to have it fall into insignificance out of lack of cultural application. You can bet they measure up well to a government that exercises prosecution of thought crime.</comment></comment></comment>


VS Code issues related to "icon" - <AUTHOR> https://github.com/Microsoft/vscode/issues?utf8=%E2%9C%93&q=is%3Aissue%20assignee%3Achrisdias%20icon%20 <comment><USER2> It's an extremely unpleasant icon compared with what it replaced.</comment>


One Program Written in Python, Go, and Rust - <AUTHOR> http://www.nicolas-hahn.com/python/go/rust/programming/2019/07/01/program-in-python-go-rust/ <comment><USER2> The "image" interface is one of my favorite parts of Go's standard library, and I think it's one of the best showcases of Go's "interface" feature. Want to save something as an image? Just implement three functions, two of which are trivial boilerplate and the third of which is just "return the color at this coordinate". You don't even need to manage the buffer of image data yourself this way. For example, if you want an image full of noise, just make your "get color" function return a random value every time it's called. I've used this myself for things like simple fractals.

And,on top of all that, once you've written code satisfying the image interface, the standard library even includes functions for saving your image as one of several possible image formats. And, due to the fact that the interface itself is specified by the standard library, virtually all third- party image encoding or decoding libraries for Go use it, too. So, every image reader or writer I've seen for Go, even third-party ones, can be drop-in replacements for one another.

Anyway, it's not Go's standard use case, but as someone who loves fractals and fiddles with images all the time it's one of my favorite parts of the language.

<comment><USER3> I like the simplicity of this (very Go-like). However, what are the performance implications of only being able to get one pixel value at a time? Wouldn't it be much less efficient than say "get this line of pixels" or "get this rectangle of pixels"?

<comment><USER4> You'll get the overhead of a non-inlineable vtable-based method call for each pixel. How badly that hurts you depends on the ratio of expense of that call vs. how expensive the pixel is to generate. If you've already got all your pixel values manifested in memory and you're just indexing into an array, it's going to be fairly expensive. If you're generating noise with a random number generator, it's going to be noticeable but not necessarily catastrophic (since "generating a random number" and "making a method call" are somewhat comparable in size, varying based on the number generator in question). If you're generating a fractal the overhead will rapidly be lost in the noise.

But I'd also point out that the Go standard library does not necessarily claim to the "last word" for any give task; it's generally more an 80/20 sort of thing. If you've got a case where that's an unacceptable performance loss, go get or write a specialized library. There's nothing "un-Go-ic" about that.

<comment><USER5> I would expect the stable based dispatch to be handled quite well with branch prediction. And surely the cache misses from those nested loops would have a much worse impact. Even if a few extra instructions have to run per pixel it's going to be quicker than a fetch from main memory.

All the examples, in each language, could be rewritten as a cache oblivious algorithm to optimise cache usage. This would speed them all up. See [https://en.wikipedia.org/wiki/Cache- oblivious_algorithm](https://en.wikipedia.org/wiki/Cache-oblivious_algorithm)

<comment><USER4> In general, I tend to agree there's a lot of people who have kind of picked up "vtables always bad and slow" and overestimate the actual overhead.

But I have actually benchmarked this before, and it is possible to have a function body so small (like, for example, a single slice array index lookup and return of a register-sized value like a machine word) that the function call overhead can dominate even so.

(Languages like Erlang and Go that emphasize concurrency have a constant low- level stream of posts on their forums from people who do an even more extreme version, when they try to "parallelize" the task of adding a list of integers together, and replace a highly-pipelineable int add operation that can actually come out to less than one cycle per add with spawning a new execution context, sending over the integers to add, adding them in the new context, and then synchronizing on sending them back. Then they wonder why Erlang/Go/threading in general sucks so much because this new program is literally hundreds of times slower than the original.)

But it is true this amortizes away fairly quickly, because the overhead isn't that large. Even the larger random number generators like the Mersenne Twister will be a long ways towards dominating the function call overhead. I don't even begin to worry about function call overhead unless I can see I'm trying to do several million per second, because generally, you _can 't_ do several million per second on a single core because the function bodies themselves are too large and doing too much stuff, such that even if function call overhead was 0 it would still be impossible in the particular program to do it.

</comment></comment></comment></comment></comment><comment><USER6> > _Rust slaps you and demands that you clean up after yourself. This stung at > first, since I'm spoiled and usually have my languages pick up after me, > moreso even than moving from a dynamic to a statically typed language._

And yet, in the author's example, all memory handling in Rust was completely automatic. And that includes, AFAICT, no Box'd pointers¹, no ref-counting, and certainly no raw/unsafe pointers.

IME, this seems to be a common response among people coming from GC'd languages; I think the expectation is that they're going to be doing C-style memory management (manually alloc/free pairs), when the truth is that 99.9% of allocations will just happen automatically and invisible thanks to RAII.

In the end, I really think it's _resources_ , of which memory is just one type of, that matter. Python doesn't do anything for resources, and you have to know you're allocating something (e.g., files, locks, connections, connection leases, etc.) that will require a manual .close() or with statement s.t. it gets dealloc/cleaned/released; RAII will handle this just like memory, and automatically handle it, and because of that, I find myself doing less _resource_ management in Rust than I do in Python.

¹There are conditions in which I would argue that some uses of Box are "automatic", depending on the reason it's pulled in. E.g., I've used it to reduce the size of an enum in the common case, but still allow it to store a heavy structure in the rare case. The handling of the Box itself is essentially still automatic.

<comment><USER7> > Python doesn't do anything for resources

The "with" blocks can help with certain kinds of resources, for example:

        with open('foo.txt', 'r') as inf:
            data = inf.readlines()

<comment><USER6> That statement was too vague, you're right. I meant that it doesn't automatically do anything. I'm aware of with (it's mentioned in the post you're responding to ;) ).

The thing about `with` (and similar constructs in other languages) is that you must _remember_ to use them at every single site of use. If you forget, while the resource usually gets cleaned up when the language's GC decides to finalize the object, it's non-deterministic and might be too late. The consequences of forgetting are significantly better vs. C, as the GC will _usually_ get to it in time, but that's not something I'd like to _depend_ on. But the amount of "effort" and _possibilities_ for mistakes is, generally, the same as C (in number, not severity): each resource allocation and each resource free requires the programmer's attention — excepting the specific, and I grant, quite common, case of memory, which one can say the GC will handle for you. RAII makes it s.t. you don't have to remember except in the (hopefully rare) case of implementing a new resource, and you can treat variables holding resources at sites-of-use like any other variable.

For your specific example, if you can do w/o the list of lines (which I find is often possible) Python's actually got a somewhat nicer construct w/ Path:

      pathlib.Path('foo.txt').read_text()

This only reads the data into a single string, whereas yours is a list of strings. Slight different, but usually it is acceptable. But it moves the required `with` into Path's helper method, so then it's harder for you to forget it. But this is a specific case (reading all data in a file), and doesn't generalize.

<comment><USER7> Good point. There is a big gulf between "can do for you" and "automatically does for you."

I really appreciate the fact that Rust does it automatically (and that it's not easy to turn that automatic management off).

</comment></comment></comment></comment><comment><USER8> You can use Hyperfine [1] instead of time for a nicer CLI benchmark.

I'd also be curious to know is pillow-simd [2] gets the Python performance closer to Go/Rust, and if using Rayon [3] and changing your .iter()'s in your Rust code to .par_iter()'s will yield an improvement there.

[1] [https://github.com/sharkdp/hyperfine](https://github.com/sharkdp/hyperfine)

[2] [https://github.com/uploadcare/pillow- simd](https://github.com/uploadcare/pillow-simd)

[3] [https://github.com/rayon-rs/rayon](https://github.com/rayon-rs/rayon)

</comment><comment><USER9> I don't know much Rust (essentially none) but the sample doesn't seem to me to warrant the 'murkier' comment. It took me a few moments to realize that the loop variable was not produced from

        image1

but instead from

        image1.raw_pixels().iter().zip(image2.raw_pixels().iter()

I would have created a local for that before the loop for clarity. And I would not have declared the ratio variable, that is surely unidiomatic as the last expression provides the result.

But apart from those stylistic quibbles it seems a model of clarity, the opposite of murky, whereas the Python version simply glues together opaque library calls.

<comment><USER10> Alternatively you can avoid the loop for the summing and just do.

        let diffsum: u64 = image1.raw_pixels().iter()
          .zip(image2.raw_pixels().iter())
          .map(|(&p1, &p2)| u64::from(abs_diff(p1, p2)))
          .sum();

I find this a lot easier to read because there is no control flow in this snippet. I can see that it is just summing the diffs. I know some people prefer iterators and some prefer loops, however I think mixing them like was done often leads to less readable code.

<comment><USER11> I prefer iterators in concise places like this, but loops when there's a bit more logic inside.

<comment><USER10> Definitely. If your logic flow naturally maps to common iterator methods I think it helps readability. If you need complex control flow it is best to use a loop then try to wrangle iterator methods to achieve it.

</comment></comment></comment></comment><comment><USER12> > No Optional Arguments: Go only has variadic functions which are similar to > Python's keyword arguments, but less useful, since the arguments need to be > of the same type.

What I like to do is to make the last arg take a struct such that you indirectly have named (and optional) arguments:

      type DownloadOpts struct {
        UserAgent string
        TimeoutSeconds int
        //...
      }

      func Download(url string, opts DownloadOpts) (io.Reader, error) {
        ...
      }

      //use like:
      contents, err := Download("https://news.ycombinator.com", DownloadOpts {
        UserAgent: "example-snippet/1.0",
      })

> Never needing to pause for garbage collection could also be a factor [in > Rust's greater speed compared to Go].

Would be nice if the author had checked

      var ms runtime.MemStats
      runtime.ReadMemStats(&ms)
      print(ms.NumGC)

to see if there was actually any garbage collection performed.

<comment><USER13> >What I like to do is to make the last arg take a struct such that you indirectly have named (and optional) arguments:

Rob Pike, and Dave Cheney both posted about this [1][2]. They summarised that using self-referential functions were a more optimal way for handling options to a function. This gives the benefit of allowing the options to be easily extensible by yourself, and any users that would be interacting with your API.

[1] - [https://commandcenter.blogspot.com/2014/01/self- referential-...](https://commandcenter.blogspot.com/2014/01/self-referential- functions-and-design.html)

[2] - [https://dave.cheney.net/2014/10/17/functional-options-for- fr...](https://dave.cheney.net/2014/10/17/functional-options-for-friendly- apis)

<comment><USER14> Functional options were exciting when they were first discovered, and they're used in a few popular APIs (e.g. gRPC), but they haven't become as ubiquitous as you'd expect if they were truly superior. My guess is that a struct is the more direct and obvious approach for most people. Functional options also make it awkward to save and reuse a set of options later.

</comment></comment></comment><comment><USER15> Nice writeup overall. Tiny nitpick however - in your Rust generation of the diff image, you go by column instead of by row, making it quite a lot slower than it should be (probably because of cache locality, I ain't no expert). Switching from

        for x in 0..w {
            for y in 0..h {
            let mut rgba = [0; 4];
            [...]

to

        let mut rgba = [0; 4];
        for y in 0..h {
            for x in 0..w {
            [...]

cuts down runtime by between 35 and 50% on my side.

EDIT : moving the call to get_pixel outside the inner loop take off another ~10%, bringing it to sub 0.145 from ~0.290.

        let mut rgba = [0; 4];
        for y in 0..h {
            for x in 0..w {
                let pix1 = image1.get_pixel(x, y);
                let pix2 = image2.get_pixel(x, y);
                for c in 0..4 {
                    rgba[c] = abs_diff(
                        pix1.data[c],
                        pix2.data[c],
                    );
                }
                let new_pix = image::Pixel::from_slice(&rgba);
                diff.put_pixel(x, y, *new_pix);
            }
        }

<comment><USER5> The optimal cache usage would be to not use staright nested for loops, but to segment the whole image recursively. So take the whole imahe, then take each quarter, then proceeds each quarter again.

At least that is my understanding of how to implement a cache oblivious algorithm. See [https://en.wikipedia.org/wiki/Cache- oblivious_algorithm](https://en.wikipedia.org/wiki/Cache-oblivious_algorithm)

Used that approach once when computing a large cross product and it gave a good speed up.

</comment></comment><comment><USER16> To anyone coming from Python and wanting to try out Rust: If you haven't worked with C before I highly recommend spending a weekend hacking something in C before starting Rust. It really made me appreciate the borrow checker and super restrictive type system.

<comment><USER17> Nope. That's a 7 mile "shortcut" for 100m bridge. It really takes time to feel the pain of all the foot guns in C. Just read Jim Blandy's awesome "Why Rust" summary instead [https://www.oreilly.com/programming/free/files/why- rust.pdf](https://www.oreilly.com/programming/free/files/why-rust.pdf)

<comment><USER16> Thx for the link, it looks useful. However, I disagree. The experience of trying to make something work when the compiler gives grief for no obvious reason or doesn't give any errors but you segfault for the 10th time cannot be substituted by reading a book.

</comment></comment></comment><comment><USER18> > I've used statically typed languages in the past, but my programming for the > past few years has mostly been in Python. The experience was somewhat > annoying at first, it felt as though it was simply slowing me down and > forcing me to be excessively explicit whereas Python would just let me do > what I wanted, even if I got it wrong occasionally. Somewhat like giving > instructions to someone who always stops you to ask you to clarify what you > mean, versus someone who always nods along and seems to understand you, > though you're not always sure they're absorbing everything. It will decrease > the amount of type-related bugs for free, but I've found that I still need > to spend nearly the same amount of time writing tests.

This is one of the biggest confusion points when comparing Python and Go.

Go's static type system is weak, the weakest of any widely-used static-typed languages except C/C++. Lack of interfaces means you have to cast in/out of object, so you're constantly sidestepping the supposed benefits of the static type system. Type errors will, of course, be caught at runtime, but that's completely identical to Python. You can, of course, use go generate to avoid a lot of the object casting, but then you get all the wonderful problems of macros.

Python doesn't enforce types at compile time (because there isn't a compile time) but it does enforce types--it _does not_ "nod and seem to understand you", if, for example you decide to do `42 + "Hello, world"`. It very much tells you that this is not valid.

This confusion comes from the common misconception that static types = strong types, and dynamic types = weak types. The truth is that there are a good number of static languages (C being the most obvious) which have much weaker type-checking that some dynamic languages like Python.

<comment><USER19> Is "duck typing" strong or weak?

Maybe one could argue that Python has a robust but hard-to-use interface system called "documentation".

</comment></comment><comment><USER20> Thanks, this is a pretty great write up. It's not a langauge-war, the discussion is knowledgeable and pragmatic, and I like that you recognise that a language suitable for work might be different from one you'd use on a side project.

</comment><comment><USER21> This is a pretty silly comparison to be honest. Why would you choose an example for which a library exists in Python that can already do most of the work for you? Sure, it might be the most "Pythonic" thing to do (importing a library) but for an actual language comparison, you should be comparing things 1 to 1.

EDIT: For example, implementing a merge sort (without using any .sort() functions) would be interesting to compare between the three languages. Though to be honest, I wouldn't expect major differences aside from basic syntax.

<comment><USER22> > _but for an actual language comparison, you should be comparing things 1 to > 1._

Not really, you should be comparing the idiomatic ways in each language.

And if Python is more of a "batteries included / easily installable" language, then that's how you should use it.

> _EDIT: For example, implementing a merge sort (without using any .sort() > functions) would be interesting to compare between the three languages._

Only if you want to see how each language feels in terms of primitives and syntax and so on. Not if you want to see how you'd actually use the language, and what facilities and ecosystem you can leverage, which is more important.

If I'm going to compare Python for scientific computing to Java, for example, of course I'll consider that Python has Nympy, Pandas, Anaconda, and so on, and similar for what Java offers, not just try to e.g. write my own math code in pure Python and Java. Same for most domains...

<comment><USER21> Sure, that makes sense in a specific way - perhaps if you were deciding which language to use for a particular project. You'd look at which libraries it offers, which features you will be making the most use of etc.

But in this case, it's comparing two languages generally to each other. And the example chosen biases Python in terms of brevity and complexity because Python has a library for the use case chosen for the comparison. If you want to do a general comparison you need to be general in your approach.

<comment><USER23> > the example chosen biases Python in terms of brevity and complexity because > Python has a library for the use case

Which would also be true for many other examples they might have picked, which makes it a reflection of the ecosystem, not a distortion.

It's a "subjective, primarily developer-ergonomics based" comparison. Seems like fair game to me.

</comment></comment></comment></comment><comment><USER24> That's ironic, I also wrote a similar app for image diffing and it is also written in Python, Go, Rust... and Node. It also spits a number as diff metric, but it is an integer. Code is at [https://github.com/elvis- epx/pictdiff](https://github.com/elvis-epx/pictdiff)

</comment><comment><USER25> > There was one place where because of the type system, the implementation of > the imaging library I was using would have led to an uncomfortable amount of > code repetition.

If you truly don't care about handling the different variants and want them all to execute the same code you could have just as easily done:

        let w = image1.width();
        let h = image1.height();
        let mut diff = image::DynamicImage::new_rgb8(w, h);

If you don't care about image1.color() 's variants, why even have the match at all? I guess I don't understand why it 'rubbed you the wrong way'. You don't have to match anything if you don't want to, and if you do want to match variants, you have all the tools necessary to reduce duplication & only handle the variants you want to.

<comment><USER6> I don't know if others do this, or if the Rust style guide particularly sanctions it, but in match sections that get overly verbose like that, I find it useful to do a local use statement to pull the enum variants into scope. E.g.,

      use image::ColorType::*;

      match ... {
        RGB(_) => DynamicImage::new_rgb8(w, h),
        RGBA(_) => DynamicImage::new_rgb8a(w, h),
      }

If you don't necessarily want the variants in the broader scope, it keeps them out of it, but within the local context of the match, the reader often will know what's being referred to. (And if they don't, the use statement will tell them.)

Also, the author already has DynamicImage available in the scope (there's a use for it at the top) so the image:: prefix isn't needed in that section.

There's also what looks like a manual expansion of try!() in run(), that could just be create_diff_image(...)? which would be less verbose.

<comment><USER25> I prefer the constructors being in the scope personally because it feels similar to Haskell. I'm not sure why they decided to make them hidden.

</comment></comment></comment><comment><USER26> I think the author does a good job comparing the three languages here. That said, comparing just one program can provide some insights, but not enough to know if the language is a good choice for larger projects. I have rewritten a whole book of programs, first in Swift, then in Python, and soon in Java ([https://classicproblems.com](https://classicproblems.com)). And if I didn't know the three languages well, I probably would have to say that even writing that book has not provided me enough insight to say "this language is good for my next 100,000 line project."

</comment><comment><USER27> I wish these comparisons that involve typing would include Mypy. Python is now effectively an optionally-typed language, not just a dynamically-typed language, and in my experience it solves a good deal of the problems, while not getting in the way.

</comment><comment><USER28> I don't understand the obsession of people trying to compare statically typed and dynamically typed language performance.

Besides that, cpython is not the only Python runtime or interpreter. The author should have tried pypy runtime which has mature JIT.

<comment><USER29> Yeah, there's a lot more I could do to have made this fairer. But, in the end, my goal was to write the program in the most pragmatic way I could for each language, not level the playing field as much as possible.

Also, this blew my mind: [https://lobste.rs/s/xz5l8t/one_program_written_python_go_rus...](https://lobste.rs/s/xz5l8t/one_program_written_python_go_rust#c_lxm4vf)

<comment><USER30> any chance I can get an invite? tracker1 at gmail

</comment></comment></comment><comment><USER31> Interesting comparison, coming from a python background this was actually helpful info!

Just odd to read noun-verb combinations like:

> "If you're comfortable with Python, you can go through the Tour of Go in a > day or two..."

> "I would go as far as saying that Go's strength is that it's not clever."

> "I decided to give an honest go at learning Rust."

> "Go propagates errors by returning tuples: value, error from functions > wherever something may go wrong."

</comment><comment><USER32> > _Its minimalism and lack of freedom are constraining as a single developer > just trying to materialize an idea. However, this weakness becomes its > strength when the project scales to dozens or hundreds of developers_

I actually appreciate this less for other developers, but even for my own code. Let's be honest, It's difficult to come back to a code base a year or two after it went into maintenance even if you were the writer.

</comment><comment><USER33> I love that this Lisp version from a comment at lobste.rs ([https://lobste.rs/s/xz5l8t/one_program_written_python_go_rus...](https://lobste.rs/s/xz5l8t/one_program_written_python_go_rust#c_lxm4vf)) runs in less than half the time of Rust, and is more readable to boot:

        (declaim (ftype (function (string string) double-float) img-diff))

        (defun img-diff (first-file-name second-file-name)
          (declare (optimize (speed 3) (safety 0) (debug 0) (space 0)))
          (let ((im1 (png:decode-file first-file-name))
                (im2 (png:decode-file second-file-name)))
            (declare ((SIMPLE-ARRAY (UNSIGNED-BYTE 8) (* * *)) im1 im2))
            (/ (loop
                for i fixnum below (array-total-size im1)
                summing (abs (- (row-major-aref im1 i)
                                (row-major-aref im2 i))) fixnum)
               (* (ash 1 (png:image-bit-depth im1)) (array-total-size im1))
               1.0))) ; Convert rational to float

        (img-diff "file1.png" "file2.png")

<comment><USER34> Less than half the time is provable. More readable is a bit of a stretch.

What does declaim mean? What about ftype? What is the (* * *) in the array declaration? What is ash? I've read through some of CLtL and the rust book both, but none of those are constructs I've come across.

Also (this doesn't matter in practice due to rainbow parens for almost every editor), it's really hard to read lisp code without syntax highlighting. Rust isn't super easy, but I don't have to count braces to see what lines up.

</comment></comment><comment><USER35> Great post, I like comparisons like this because its about implementing something practical. I like to see how the languages do in the real world.

</comment><comment><USER36> This is great. I've been thinking about doing this very thing in a different problem domain.

</comment><comment><USER37> If there were one perfect language, for all porpoises, we would be using it already.

Also a genuine dollars and cents factor: Development Time.

Do not just measure for cpu cycles and bytes. Development time is money, and that is a measurable factor too that must be considered as a language tradeoff.

</comment><comment><USER38> Good to read! let me know that pillow has lot of space for optimizing.

</comment><comment><USER39> Should have also considered C++

</comment><comment><USER40> you could've given at least one JVM language, maan o_0

<comment><USER41> I always feel that way about the Python/Go/Rust obsession on HN. For the majority of cases, you could just use Java (or Kotlin etc) or C# and while "boring", the overall benefits nad balance those two provide would usually make Python/Go/Rust pointless. Doing it with one language as well.</comment></comment>


A home-made lithographically-fabricated integrated circuit - <AUTHOR> http://sam.zeloof.xyz/first-ic/# <comment><USER2> Awesome. For those considering exploring some of these steps in their own garage -- the chemistry is dangerous, perhaps HF in particular, as it doesn't hurt, it just kills you a few hours later.

Can you do this in a garage? Absolutely, but learn everything you need to know from an ensemble of safety-minded mentors before you strike out on your own.

It's not just about safety for you, proper disposal of these chemicals is essential for the many generations to come. Sometimes it is inexpensive, sometimes it is costly. You need to know how before you start, or it costs a lot more.

(Also, you can get someone else to pay for the hardware, the infrastructure, the material, the resists, the reagents, the safety training, and the waste disposal if you work/volunteer at a university's photolithography facility. They'll probably pay you, too.)

<comment><USER3> >> For those considering exploring some of these steps in their own garage -- the chemistry is dangerous, perhaps HF in particular, as it doesn't hurt, it just kills you a few hours later.

I was hoping that with 50 years of development behind us, the home fabricators could use less complex methods and less hazardous chemicals. In other words, can the folks who lived it help people like this by saying "If we had to do it over, I'd go about it like...."

Any suggestions? If you had to reboot the chip fab business on a budget what would be a more practical approach?

<comment><USER4> I used to work in a fab. As far as I know, there's no acceptable way to remove native oxide without HF. We do have another etch process -- dry etch -- that uses plasma instead, but it causes surface damage, and you don't want that under the gate. Also, dry etch chambers are a lot more work to maintain than a fume hood where you do wet etch. Furthermore, dry etch has its own set of hazards, and you have to deal with a lot more potentially toxic vapor.

<comment><USER4> Thinking a little more outside the box, you might look into using germanium instead of silicon. I don't know much about the germanium system, except that it supposedly grows less oxide. You're still going to have to deposit and remove oxide somehow, though, which means CVD reactors and silane. It's not going to be easy to get away from explosive toxic gases and dirty processes.

<comment><USER5> Not to mention DiBorane and Arsene... 1000C anneal cycles, teratogenic photoresist ethers, UHV equipment, and muti-kW RF sources. It's possible to demonstrate um scale MOS with a small lab, but not safely in anything resembling a normal garage. Hoping to replicate a multi-$B process at home is a fool's errand.

<comment><USER4> While we're at it, a modern scanner costs many million dollars, weighs tons, and sits on its own separate foundation on pilings that go down to bedrock so that it doesn't pick up vibrations from the air handling systems. DIY it ain't :)

<comment><USER6> what is a scanner in this context? what is its role?

or is this a stepper? or scanning electron microscope?

<comment><USER4> A scanner is a photolithography tool like a stepper, except instead of exposing the entire shot at once, it sweeps (scans) a narrow rectangular exposure across the shot, and then steps to the next one. This allows for lighter, more precise optics. Confusingly, there's a piece of standard office equipment with the same name. Even more confusingly, Canon makes both kinds! Be sure you call the right technician for service.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Have a mini-course into maskless photolithography[1][2], and find out how an old DLP projector combined with some advanced optics can yield this: [http://sam.zeloof.xyz/wp- content/uploads/2017/02/IMG_2917-e1...](http://sam.zeloof.xyz/wp- content/uploads/2017/02/IMG_2917-e1522160324771.jpg)

Take a tour in a home fab: [https://www.youtube.com/watch?v=TrmqZ0hgAXk](https://www.youtube.com/watch?v=TrmqZ0hgAXk)

His website and Youtube channel are so richly filled with knowledge that so desperately needs to be in the public domain, instead of being locked in corporate structures.

[1] [https://www.youtube.com/watch?v=XVoldtNpIzI](https://www.youtube.com/watch?v=XVoldtNpIzI)

[2] [http://sam.zeloof.xyz/maskless- photolithography/](http://sam.zeloof.xyz/maskless-photolithography/)

<comment><USER8> "His website and Youtube channel are so richly filled with knowledge that so desperately needs to be in the public domain, instead of being locked in corporate structures."

All of this information is public domain, what are you talking about? This is extremely well understood stuff.

<comment><USER7> Yeah, I went a bit overboard in my amazement that this exploration into building integrated circuitry with affordable tools was so well documented. Such practical information and experience is hard to come by in world where the manufacturing of integrated circuits has been iterated on with very expensive machinery for at least 50 years.

</comment></comment></comment><comment><USER9> IEEE has a background piece for those (like me) wondering "who is this guy?"

[https://spectrum.ieee.org/semiconductors/devices/the-high- sc...](https://spectrum.ieee.org/semiconductors/devices/the-high-school- student-whos-building-his-own-integrated-circuits)

Impressive.

<comment><USER10> His inspiration, Jeri Ellsworth is just (if not more) impressive. Check out her youtube.

[https://www.youtube.com/watch?v=PdcKwOo7dmM](https://www.youtube.com/watch?v=PdcKwOo7dmM)

<comment><USER11> [5:16] _"...oh, I didn't die having go in there messing with the hydrofluoric acid. My bones do feel a little gelatinous though."_

I'm not sure if I should admire or condone this kind of attitude in a science related context.

<comment><USER12> > I'm not sure if I should admire or condone this kind of attitude in a > science related context.

It makes no difference whatsoever to the whole what you've pointed out here.

Throughout the video, she states she's responding to critics. Her whole attitude is of teasing those who accuse her of not knowing what she does (calling her chips fake, etc).

When she says that, it's perfectly clear that she's being very (and I mean very) sarcastic.

We can discuss if her use of sarcasm is useful or not, but then we will be discussing the specifics of her presentation, not her skills at doing the chemical process she just demonstrated.

Since this is a video about "Making Microchips at Home"; since she's responding to critics; I think we can allow her some room to throw some sarcasm to the mix, even if it does not work out completely as intended.

On a side note: it would be nice if people on the internet would allow others some "humanity"; by that meaning giving them room to err, like saying silly things when they are annoyed — instead of nitpicking bits of unimportant information.

The Internet is already too noiseful as it is.

<comment><USER13> Normally I would agree with you. But these days when anyone can find support for, as well as buy, almost anything on the Internet our freedom to be imprecise and still responsible has unfortunately diminished significantly. That of course doesn't justify a lot of other comments, or attitudes, people have to deal with when wanting to make something.

<comment><USER14> > our freedom to be imprecise and still responsible has unfortunately > diminished significantly

I disagree. The responsibility has and should always remain entirely with the person taking the action. If speaking imprecisely on the Internet is a liability then nobody can speak at all.

Random YouTube maker videos have virtually zero duty of care to their audience.

I say _virtually_ because I could imagine a maliciously crafted video designed to lull a watcher into inadvertently blowing themselves up, but even in the case of a prank video which gives knowingly false/dangerous instructions I'm still not sure of this is something people can or should be held liable for.

If you are handling dangerous chemicals, it is your own personal responsibility to have proper tools, training, and certification to do so safely. Being able to find false information on the internet doesn't in any way absolve you from the responsibility or shift the blame to someone else.

A moral/legal system which would shift liability to a random YouTube video has a lot of highly undesirable side-effects in terms of stifling free speech, and free exchange of ideas.

<comment><USER13> It's not really about liability, but whether it's warranted to object. You can say whatever you want, but you can't expect others to not say what they want back unless what you are saying is measured. Objecting to what other people are saying isn't stifling of free speech, it is free speech itself.

<comment><USER14> Yes, certainly, no one should expect anything they say or write to be beyond reproach or free from criticism. That's very different from saying they shouldn't be free to say it in the first place, which is how I (mis-)perceived your initial comment.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Impressive to replicate silicon semiconductor process. But wouldn't it be more feasible to develop as good enough process node, flexible, thin film semiconductor devices? Have been observing developments of plastic based transistors, inks, processes like nanoimprint lithography, Cleanroom in a STEM microscope and Chad Mirkin's Tera Print system. Can a small scale nanfab emerge using tech such as Nano-Ops [http://nano-ops.net/nanoscale- printing/](http://nano-ops.net/nanoscale-printing/) ?

I imagine flexible, thin film, large panel based semiconductor SoC. It will not be just a mere microcontroller or IoT node, but a full fleged computing form factor. Think your wall as big plastic computer.

<comment><USER16> So there is reel to reel OLED screen technology out there (basically a printing press for OLED screens).

[http://www.flexolighting.eu/](http://www.flexolighting.eu/) (These guys have some pictures of the process).

It's probably also possible to print transistors directly. Here's a paper from 2017 that outlays that process.

[https://www.nature.com/articles/s41598-017-01391-2](https://www.nature.com/articles/s41598-017-01391-2)

</comment></comment><comment><USER17> When I read things like this I start to think about the following question: Given no technology at all (i.e. after an apocalypse!), how would one go about creating a computer (as we know them). What sort of knowledge would you need? The science of these things is basically multi decades of trial and error in various disciplines. Imagine a manual that explained how to create everything from scratch!

<comment><USER18> I'm interesting in this too and wondering why nobody did huge task and compiling everything into one book, starting from refining materials to making 8051/Z80 era pc

<comment><USER19> There is a book about building a toaster from scratch like this called "The Toaster Project" [1]. The conclusion is that it's extremely difficult and nearly impossible for even a simple device like a toaster. A computer would be significantly more difficult.

[1] [http://www.thetoasterproject.org/](http://www.thetoasterproject.org/)

</comment></comment></comment><comment><USER20> Geeze, I though you needed a clean room to do this kind of work. I guess, being a hobby, with less concern for effort, loss of product, or cost versus profit, one might summon the will to try, try again, when confronted with botched fabrication runs.

Even with millimeter-scale components, I'd still think dust and debris could be a real problem. Is it just that 12 hour runs are short enough to just accept an imperfect production output, since it's a personal project, or is dust not as big a deal at this scale as I'd imagine?

<comment><USER21> You do not need a cleanroom, just some laminar airflow to prevent dust contamination. That is easy to achieve with a bunch of fans and lab clothing.

Static electricity damage is prevented by grounding everything. (Important during lithography.)

The hard part is getting a reliable plasma oven and the requisite chemicals plus running the process to reliability.

</comment></comment><comment><USER22> I was looking for how he managed the clean room or did he not go too small. Found the answer in the IEEE article shared by another commenter (he didn't go below 10 micron tech node).

But now I have a follow up question, if getting a clean room is obviously harder, isn't "clean box" more doable? E.g., if you line up a bunch of tables, and put a long box on top that acts like a poor man's assembly line. The insides of that box are only accessible through gloves that are attached to holes on the sides of the box, and plenty of glass windows to look inside (kinda like the box in movie 'Life'). How cost effective and feasible (i.e., gets the job done) would that be compared to a clean room? maybe you could go sub-micron with it if not sub-100nm.

<comment><USER23> Also if you don't really care about yield, many things are not that critical. I did a PhD in semi-conductor physics, and most processes for silicon are actually surprisingly robust (compared to processes of any other material). Also many things are just done the way because people know it worked before, which does not mean you can't use less fancy equipment and it would still work.

</comment></comment><comment><USER24> I predict a future Hacker News submission titled "I turned my garage into an EPA Superfund Site"

<comment><USER25> You should really read "The Radioactive Boy Scout", about a teenager who attempts to build a nuclear reactor. The EPA ends up dismantling his shed in moon suits.

[https://harpers.org/archive/1998/11/the-radioactive-boy- scou...](https://harpers.org/archive/1998/11/the-radioactive-boy-scout/)

</comment></comment><comment><USER26> This is incredible work. I would have loved to have attempted this when I was in college. The field seemed so inaccessible, and now it makes me happy to see some homebrewer accomplishing things like this.

</comment><comment><USER27> That's great! Are we anywhere near to making homebrew ICs on silicon at home? Yes, apparently we are! But it seems we are still far away from DIY kits, or even complete prototyping devices (like 3D printers).

</comment><comment><USER28> If he could get feature size down to 10 microns someone might have a shot at making a microprocessor.

<comment><USER21> At that scale his hacked together (amazingly cheap) optical lithography equipment will not serve. (See how well it did with 1um lines. That is the main problem.) Nor especially the photoresist process.

Perhaps it can do 5um with a different resist.

</comment></comment><comment> orbital-decay Can the process be streamlined into a single amateur-friendly device/lab? Yes, I mean a chip printer, as a commercial product.

<comment><USER29> Chip printer that would make IC's that are better than what amateur can make from readily available cheap components on a PCB board would be used in the industry first.

There is small number of field-programmable analog array (FPAA) products and FPGA/FPAA hybrids in the market. I hope they become better and more available (never used one myself).

</comment></comment><comment><USER30> Instead of using all these dangerous chemicals, can you use use an alternative like Ion Beam Etch (IBE) or some sort of plasma etching system (given that a person can build one and has the money for everything like turbopumps and grids)? Or is it mandatory to use something like HF to etch?

</comment><comment><USER5> Lots of comments on the previous article (before he had a chip to test) as well.

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

</comment><comment><USER31> I remember, there is a Swiss guy in HK who is trying to reanimate an abandoned nineties era fab for use by of opensource electronics.

</comment><comment><USER32> Cheers to this kid's drive and inventiveness, but I won't be at all surprised when his house becomes a Superfund site.

</comment><comment><USER33> Had a chance to interview Sam last week, he's as bright as you'd assume: [https://theamphour.com/390-an-interview-with-sam- zeloof/](https://theamphour.com/390-an-interview-with-sam-zeloof/)

</comment><comment><USER34> There are less dangerous ways to explore "building a CPU from scratch" that hit on the _really_ interesting bits. "Digital Computer Electronics" by Malvino and Brown. You are given logic gates (and, or, nor, nand etc) and build up from there to a working CPU. The articles referenced about HF are terrifying. I am a programmer, but, have worked in a chemistry lap. Its just endless stinky stuff that will kill you in a variety of ways. The logic of how a CPU works is more interesting.

<comment><USER35> > The logic of how a CPU works is more interesting.

Maybe for you. I find silicon fabrication to be much more interesting.

</comment></comment><comment><USER36> Uoou... now this is really cool, this guy is incredible :)

</comment><comment><USER37> Lovely, I've always wanted to do something similar.

</comment><comment><USER38> Bravo!

</comment><comment><USER39> OK now grow your own SI wafers using repeated Czochralski process based on silicon you made by melting sand.

<comment><USER40> This seems to be a little silly. Sure, that'd be cool, but I mean, he didn't claim to have manufactured his own oscilloscopes here either.

<comment><USER39> Just putting out next step learning challenges. I'm loving what he's doing, it's a great project, I hope he continues it by exploring different aspects of it.

Other challenges include smaller lithography and CMOS fabrication using a self-aligned gate process. But there are pitfalls ahead, including chemicals that can kill with in trace doses...

I fabricated my own ICs as a teen in my freshman year of college as part of our program, but that obviously wasn't at home. It was still awesome, just going through the entire process.</comment></comment></comment>


Breaking Through the Normalization Barrier: A Self-Interpreter for Fω (2016) [pdf] - <AUTHOR> http://web.cs.ucla.edu/%7Epalsberg/paper/popl16-full.pdf <comment><USER2> Previous discussion on /r/haskell:

[https://www.reddit.com/r/haskell/comments/3s93w1/a_selfinter...](https://www.reddit.com/r/haskell/comments/3s93w1/a_selfinterpreter_for_fomega/)

To summarize, there are a number of different notions of self-interpretation. The strongest notion is interpreting from raw untyped syntax (which entails that the input is first type checked and some failing result is returned if it's invalid). This can be relatively easily proven to be impossible in any total language. The weakest notion of interpretation is the no-op embedding: quoted terms are terms themselves and self-interpretation is the identity function.

The weakest self-interpreter is trivial to implement but useless. The strongest one is very useful but impossible. The paper presents something which is weak enough to be possible but strong enough to be useful. It essentially Church encodes the terms of System F-omega as a fold over their structure. This makes it possible to implement pretty printers or structural equality. However, in this scheme all quoted terms are well-typed to begin with, also, quotation can not be invoked at runtime and is available through external preprocessing step only.

<comment><USER3> _> This can be relatively easily proven to be impossible in any total language._

Please provide this proof.

<comment><USER2>
        f :: String -> ()
        f g' = case (eval g' :: Maybe (String -> ())) of
          Just g  -> g g'
          Nothing -> ()

        loop :: ()
        loop = f (quote f)

<comment><USER3> Your sketch of a proof does not appear substantially different from the proof given in section 3.1 of the linked paper. Section 3.2 explains that this result does not apply to strongly normalising languages.

See also the slides titled "So what about, e.g. Fω instead of ℕ ⇒ ℕ?" in Gergo Erdi's talk on the subject of the linked paper:

[https://gergo.erdi.hu/talks/2015-11-fomega/FOmegaUnquote.pdf](https://gergo.erdi.hu/talks/2015-11-fomega/FOmegaUnquote.pdf)

Note that your sketch is one particular variation of a folklore argument, best recalled by Conor McBride in 2003:

[https://mail.haskell.org/pipermail/haskell- cafe/2003-May/004...](https://mail.haskell.org/pipermail/haskell- cafe/2003-May/004343.html)

Here's what Conor McBride has to say on the subject in 2015:

[https://www.reddit.com/r/haskell/comments/38wels/conor_mcbri...](https://www.reddit.com/r/haskell/comments/38wels/conor_mcbride_hasochistic_containers/cs11ppm/?context=3)

If you are interested in discussing this further, please feel free to contact me privately.

<comment><USER2> I am familiar with all of your listed sources (even attended one incarnation of the Érdi Gergő talk).

Section 3.2 of the paper absolutely does not say that the result does not hold. The main point of the construction is that typed quoted representations can preserve totality by disallowing diagonal application. Interpreting untyped quoted representations is impossible all the same, which is what I said in grandparent post.

I know Conor's views on total programming and share them, but the 2015 comment is not particularly relevant to the current topic, nor does it reflect on the folklore self-interpreter argument.

<comment><USER3> It is great that you are interested in the subject. Please consider joining ##dependent on Freenode IRC.

</comment></comment></comment></comment></comment></comment><comment><USER4> Another discussion on LtU: [http://lambda-the- ultimate.org/node/5276](http://lambda-the-ultimate.org/node/5276)</comment>


Why Groupon Needs $950 Million More - <AUTHOR> http://www.pmorganbrown.com/2010/12/why-groupon-needs-950-million-more/

<comment><USER3> Unless Google put significant earn-outs in the acquisition (possible) - <USER2> there any real downside to Groupon accepting an offer that they knew was bound to fail? It's not as though a failed $6B acquisition would really have negatively impacted GOOG's $190B market cap, so, even it had been a stock deal - they could have taken the money and run.

I think the better answer is that (A) The Groupon guys thought they were worth more than $6B, and (B) they wanted to keep running their own show and find their place in the sun.

</comment><comment><USER4> Touche. I was having this discussion with a coworker the other day and I was saying sort of the same thing. People think it was unwise to refuse Google's offer, but Google's culture and track record regarding what need's to be done to make Groupon big make selling to Google the wrong decision. If they had accepted Groupon would have undoubtedly died a gruesome death or end up merged into a subdivision of Adwords quietly collecting dust.

</comment><comment><USER5> I don't get it - how is Groupon supposed to scale? What would be the point of them having 100000 small businesses in a city? They could hardly put them all on their homepage? Also, they would need enough visitors to their homepage to drive business to all their clients.

What does Groupon offer, besides traffic (ie people who visit the Groupon homepage)? Can't small businesses just make up their own special offers? I mean if they are not on the front page of Groupon, they would gain little by going through Groupon, or so it seems to me.

<comment><USER6> You're thinking short term, Groupon just needs to get to the stage where people think "I'll just check Groupon to see if I can get this cheaper" before every purchase. Then there's a million things they could do to take advantage of that visitor's purchasing intent, local price comparison for example

<comment><USER5> None of these things are exclusive to Groupon, though. There are already lots of aggregators for coupons where you can check if you can get something cheaper.

<comment><USER7> The point is that these aggregators are not in everyone's mind today. Groupon can use their current offering to reach everyone's mind, and then use that positioning (and therefore you going to their site) to do price comparison, focus on the user choosing specific topics of interest, etc.

<comment><USER8> Yes but the counterpoint is that it's an easy-to-replicate idea

<comment><USER9> Having a large mindshare in a specific niche is neither an idea nor is it easy to replicate.</comment></comment></comment></comment></comment></comment>


Show HN: WebGL Multiplayer Game (wizardwarz.nergal.se) - <AUTHOR>

Just launched a very early beta of a multiplayer "FPS" made in WebGL using ThreeJS library. (possible to switch between FPS and 3rd person) Just a hobby project that I would love to get some feedback on, in order to see if I should continue working on it or not.
Note; It will add the project to github as open source once I've spent some time cleaning up the code.
URL: http://wizardwarz.nergal.se <comment><AUTHOR> The server is a nodejs based server that generates the world dynamically. Each map is therefore always unique.

</comment><comment><AUTHOR> NOTE: Recommended web-browser is Google-chrome on PC. It must support WebGL.

<comment><USER2> Seems to work on FF/OSX Mavericks

<comment><AUTHOR> I heard someone had an issue with the pointer lock on FF/OSX. Did you see any issues with the pointer lock?</comment></comment></comment>