Introductory bullshit detection for non-technical managers - <AUTHOR> https://itsyourturnblog.com/introductory-bullshit-detection-for-non-technical-managers-7c7a9e54afee <comment><USER2> Having worked 20 years, I'm getting me and more tired of one thing: a meeting that includes a manager that you need to explain every obvious thing to.

It's no problem with clients, stakeholders, new hires, or even unreasonably thick coworkers, but a manager that having less than a minimal domain knowledge trying to 'summarize' or 'weigh together' a lot of things they do not understand is just so utterly unmotivating.

I have the research on my side: the most influential factor on job satisfaction is if your manager can do your work. [https://hbr.org/2016/12/if- your-boss-could-do-your-job-youre...](https://hbr.org/2016/12/if-your-boss- could-do-your-job-youre-more-likely-to-be-happy-at-work)

<comment><USER3> I could do your job. If I learned how to code. But as a product manager my duty is to act as a bridge betweeen you and my bosses and my customers and my customer service etc.

How skilled do you want me to be? It's very difficult dancing this dance. Fighting for resources.

I think the difference is most managers can be ignorant uncaring assholes.

Having a manager trust and listen to you and fight for you and defend you when necessary is far more important.

I'm my opinion the only non technical part of me is that I haven't learned how to code.

But the proof of the pudding is in the eating. I eat.

<comment><USER4> > I could do your job. If I learned how to code.

All that means is that you can't, though.

In any case, I don't think the point is actually being able to code. To me, the point is knowing enough to not be a burden in the conversation. If you can follow the high level technical details of what people are saying, you're good.

I have managers like that, and I love them. You sometimes need to explain some things but it doesn't take more than a sentence of "we can't do this because it would break the other thing".

<comment><USER3> You're totally correct. But I never wanted to. I do love technology and certainly try not to ignorant of current and future technologies. I respect the art of the programmer. But to be slightly rude just to make a point: an average or above average coder is a commodity. In theory many many people could do your job. But a great manager is not a commodity. They are highly prized and compensated. They can break down barriers and fight fight fight.

You are right not to be a burden in the conversation. You need to kill your Ego - talking endless confusing bullshit to make yourself seem important is a nightmare. But my MD could be accused of the same the way he had to realign my priorities with that of the company.

But when you understand that some of the people on the board of the company I worked for never even use a computer, a bridge is necessary.

<comment><USER5> You compared great managers to average coders. My experience with managers is like many people's. The "average" manager is pretty bad. The average coder is also pretty bad. Both the average manager and the average coder can be replaced pretty easily. The great manager and great coder can not. I can only speak for the programmer side of that though having been involved in interviewing and seeing how hard it is to find people to pass the simplest of questions. But, given my experience with managers I suspect it's just has hard to hire great managers.

<comment><USER3> I think it's easier to find a great coder than a great manager.

I could be wrong and totally appreciate your distinction.

Edit- and I say that having worked with great coders but not many, if no great managers

<comment><USER2> Hm, being a bad manager is more visible, and even a good manager will attract more criticism.

A mediocre developer can hide behind the team or other circumstances that can be more or less hard to evaluate.

<comment><USER6> The same can be said of bad managers hiding behind a good team of direct reports. We've all had the bad manager who the owners or higher ups loved to death yet everyone on the team can tell they are incompetent. I'm not talking about the boss you hate but the truly incompentant ones.

The place I work now doesn't really care about competence only a body filling a vacancy. Maybe it's time to find a new job...I digress.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Non-technical managers... needs to be a thing of the past.

No one considers a guide for "Managers who cannot read, but must supervise writers" as meaningful article worth writing.

Being "non-technical" should be synonymous with being illiterate (if you are in a technical field that includes supervising technologists). The topic is no longer something to be assigned to "nerds in the basement" is is the language of business and life.

<comment><USER8> I was going to write something similar.

A manager of anything, including technology, should have an understanding of what they manage. Not having that understanding is the fundamental problem. Any kind of "guides" to help such ill equipped managers is only a band aid that doesn't fix the actual underlying problem.

Technical managers may cost more an be harder to find. That might just be the cost of not screwing up things in major ways. Including potentially business destroying ways.

An additional clue: Not just the immediate managers of the worker bees, but going up the chain of management there should be people who understand the technology.

Nobody would accept the idea of a manager that didn't understand the business they are in. If technology is part of your business, and you don't understand technology, then you don't understand the business you are in and shouldn't be a manager.

<comment><USER9> > An additional clue: Not just the immediate managers of the worker bees, but > going up the chain of management there should be people who understand the > technology.

There's a natural (and I think fundamental) inversion that happens as you go up the leadership chain. The first level of supervision almost inevitably knows more than the most junior employee about their area of work. (Think a senior developer mentoring a new college hire.)

That may hold for two levels, but at some point, management is about breadth and not depth. The head of technical operations probably came from networking or systems or storage or database or communications, but probably didn't come from ALL of those, so is unlikely to know more about networking than the head of networking AND more about databases than the head of databases, etc. In fact, they may know next to nothing about some particular field of ops and yet still be the right choice to lead operations. (I was in this position in a prior role.)

So you get this weird situation where at the junior levels, the supervisor knows more than the supervised. At the more senior levels, that's usually inverted. And then you get people who determine that the senior person is clueless because they know more about their specialized field than the boss.

IMO, it's unreasonable to expect the CEO of Boeing to be an expert in finance, operations, aerodynamics, manufacturing, supply chain, engine design, certification rules, avionics, landing gear, radar, flight controls, and the 100 other disciplines needed to make Boeing work. I see no reason to think that technology is extra-special in that all managers of technologists need to be world-class technologists.

<comment><USER10> Fair enough, but at the same time when you start getting to the level where they don't know about the details they need to start trusting the people below them to make decisions and take their advice. Far too often you see technically incompetent CEOs making far reaching decrees about technical issues they know nothing about because of some random brain fart they overheard on the golf course with one of their buddies.

<comment><USER7> I wish I could disagree... but is more like: they heard something they thought sounded like the tech they have and they could sell quickly.

</comment></comment></comment></comment></comment><comment><USER11> Ironically, _this_ looks like a bullshit article to me. I have no idea what is the experience level of the author, but as a senior developer, several times I have "created a framework" (and a quite useful one at that) which not only made the problem solving manageable for myself, also resulted in clean readable code which is maintainable for others in the team as well.

Also, don't underestimate the real need of refactoring at times. There's no red/yellow flag here. Sure, we can keep postponing that and create bigger mess - which is a decision we do have to take at times to avoid last minute bugs, but that still doesn't mean the developer is bullshitting when he says he needs to refactor some old ugly code.

<comment><USER12> Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it. It's not just about cleaning up code that might not meet the bar on quality. Sometimes it's about challenging assumptions by the developer that were completely valid when they wrote the original code that aren't now through hindsight, technology changes, etc.

It's possible for a developer to write all-star top shelf code only for it to be significantly improved a year later with a few line changes. To not challenge all code, even the good stuff, is doing your codebase a disservice.

<comment><USER13> >Refactoring as a "yellow flag" is not only dangerous, it's the opposite of how you should treat it.

Hmm, I actually thought it was pretty reasonable. Refactoring is real and necessary, but it also gets thrown around a lot in order to mislead. Contractors who are overbooked and not working on your project always seem to be "refactoring".

<comment><USER14> Having been both a manager and engineer for a number of years in a number of organizations, I can say with some confidence that an excess of refactoring is NOT the problem.

<comment><USER13> Having worked as a contractor for many years, I can say with absolute certainty that _actual_ excess refactoring is not a problem, but that _claims_ of refactoring very much are.

Again: when a contractor is backlogged, "we're refactoring" is the go-to justification for the delay.

</comment></comment></comment></comment></comment><comment><USER12> As a technical manager this article bugs me because it's pointing to issues with hiring that are only being made worse by having a non-technical manager.

You need to hire developers that are professionals capable of being independent, and most important, responsible. If you have developers that aren't accounting for simple things like memory or performance then you have a problem with that employee. It's something you can coach, and if that doesn't work out, then you let them go.

Having a non-technical manager makes this worse because you can't spot the problem early, and the developer doesn't have the strong sense of oversight that comes from the boss being able to read your pull requests.

<comment><USER15> Yeah but a good technical manager is out of most companies' budget.

<comment><USER3> I think you've hit the nail on the head. Or they simply haven't budgeted for it. I was paid far far less but carried the fallout for not delivering.

</comment></comment></comment><comment><USER16> Ironically, pretending to ask intelligent questions when you're clueless about the subject matter is a form of bullshitting.

<comment><USER17> Yeah that's exactly how this article reads to me. Like here's a list of questions you can ask that you'll likely not understand the answers to...ok.

</comment></comment><comment><USER18> You wouldn't want a manager working in finance who didn't understand a bit about finance.

You don't want senior programmers working in finance who don't have some domain specific knowledge.

Then why is it OK for completely non-technical managers to manage programmers? I get it, management is a separate skill set, but spend some time and learn your domain.

<comment><USER19> This is an interesting idea that can be turned on its head. So if you are stuck with a 'non-technical manager' then you should be able to get that changed, if you would prefer the manager of the guys that do the office cleaning then you should be able to get managed by them, or anyone else with these 'manager skills' that so elude developers. Then you should be able to avoid being micromanaged by a non-technical who pretends they know something of your domain.

</comment></comment><comment><USER20> Unfortunately this article is totally useless. A non-technical manager is going to read this:

> When someone on your team says… >> "I'm making a generic version of…" >> > "I'm creating a framework to…" >> "It's platform independent." >> "I'm > adding this to make sure it's future proof." >> "I really need to refactor > this bit…"

and then assume that they should fire anyone that mentions these words. In reality, it's always dependent on context and the article specifically does _not_ talk about the technical details that non-technical managers need to learn, in order to judge these situations correctly.

<comment><USER21> I worked for a really outstanding manager. She told me stories of a previous job where she managed a help desk group for a database application. She does not know how to code, but she does know how to motivate people to do their jobs.

She got the team to reduce the average time to close tickets by 75%. Customer satisfaction ratings vastly improved at the same time. The stories of the kinds of things she had to do in order to get a bunch of sullen, lazy, overpaid programmers to do their fucking jobs (her words) were hilarious. I learned a lot from those stories. And btw, she has never again wanted to manage "technical" people again.

Every time one of these "how to" articles for middle managers pops up here, a variation of this response almost automatically appears. The truth is that most technical people know nothing about the nuts and bolts of management, but think somehow that they either do know or are exempt by virtue of knowing how to code. The only group that is worse for this sort of ignorance is lawyers, in my experience.

I know it is somewhat unpopular to champion the value of having competent management, especially when companies reach a certain size. It's a lot easier for those who have never been managers to simply curse all of them as roadblocks to realizing the fruits of their genius.

<comment><USER22> I don't disagree with you, but I don't really understand how this relates to the parent comment?

It's certainly true that good management is a complex skillset, and if managers underestimate programmer's skills then the reverse is also likely. It's true that in some contexts non-technical managers can manage technical teams (and in some contexts they certainly _can 't_). But... none of that makes this article good or useful. It doesn't negate the parent comment at all. This article is _bad_ , and it's aimed at non-technical managers who aren't functional.

I suspect your outstanding manager didn't use "what are the memory constraints?" like a magic spell of management, because despite the article's sweeping generalizations ("most common... any system"), there are a lot of contexts where that's literal gibberish.

I'm willing to bet she didn't keep a list of words to interpret as "I'm a useless hack". That's basically what this article advocates. Like... "Generic version" translates to "I don't understand the problem"? Really? Last time I said that, it was "I'm making a generic version of our branded UI so the new clients can put their logo in it". That's not even a technical answer, but it still goes on the 'red flag checklist'.

I could keep that list going. And the obvious reply is "these are just tips, don't overuse them where they don't apply!" But then what was the point? Knowing when to ask these questions is the entire task of management, and this article is aimed at people who can't do that.

</comment></comment></comment><comment><USER23> For the longest time I took it to be the norm that a manager is mostly there to pressure you to work, to get things done well and on time.

Then I had a manager (he was technical) that actually helped solve issues. He didn't have to touch any code, but he had good suggestions. He knew what he was doing. He felt like he was in it. He was part of the team. He didn't just throw problems at you to solve. He was trying to help solve them himself.

</comment><comment><USER24> I think some context is needed: this post is written from the perspective of video game development where teams are composed of people with extremely broad skill sets (from the extremely artistic to the extremely technical to the extremely business side with everything inbetween). It is not uncommon to have managers there with a purely artist or purely business background working directly with the programmers.

Also, the video game industry has its share of bullshitters like everywhere else, the bigger and more 'professional' the company, the higher the relative amount of bullshitters.

Personally I think it's better to have no manager, than having a manager who doesn't have the slightest grasp of the areas the people in his team are working in, since there will just be too much time lost with communication and making sense of each other.

</comment><comment><USER25> How do non-technical people become managers of engineers in the first place?

It seems like something we should try to avoid.

<comment><USER26> I disagree, one of the best managers I had was a non-technical manager.

He was able to guide me back on track when I was veering too far into the 'interesting problem for the programmer, but not what the business is trying to solve' territory and also was able to clear obstacles out of the way to let me work on what it was I needed to be working on.

<comment><USER11> A technical manager could have done that as well, may be a little earlier than when it went "too far". Just my opinion.

<comment><USER26> Maybe, maybe not. I've had technical managers that weren't as good at that as this manager.

Now I'm sure maybe there are technical managers who can do this well too, but it's not an exclusive trait to them and my point (and experience) is simply that being non-technical is not in and of itself a disqualifying factor for being able to manage technical people.

</comment></comment></comment></comment><comment><USER27> Or "How to micromanage your engineers while not knowing anything technical."

</comment><comment><USER28> Can't non-technical managers study up?

The wealthiest entrepreneur and fierce manager in Taiwan back in 60s/70s was a man who only finished elementary school during war-torn Taiwan. But he could detect bullshit miles away. After Chinese nationalist took over Taiwan from Japanese, he started petroleum cracking business. One interesting anecdote was that a science guy was presenting to him some shiny new process with some fancy reaction formulas. He frowned and whip out pencil and paper. He started to pick apart the scientist's formulas and mansplained to that scientist how that process may not work in his plant due to this and that in your equation requires this and that, which is too costly, etc. That scientist lived to tell the tale.

<comment><USER29> >He started to pick apart the scientist's formulas and mansplained to that scientist how that process may not work in his plant due to this and that in your equation requires this and that

What does "mansplained" mean in this context?

</comment></comment><comment><USER30> I feel half of this article should be seen as project management basics for new technical managers with no PM skills.

It's very easy to forget the goals, value and cost when you understand the technical part of a project.

</comment><comment><USER31> A lot of commenters here focusing on the non-technical manager bit and ignoring a lot of very good advice that's in here even for technical people.

> Ask: Who specifically will represent the users of this system? You should > expect your team to tell you who they are actually creating something for. > Who will directly benefit from the work. And a real life individual person > they will consult with on questions and who can verify it meets their > expectations, at least. If your team is working in a vacuum, it's a sure > sign they're working on the wrong thing.

I've worked on teams where the person in charge of what features would be built had a "vision" and refused to ever actually iterate with users. Result: A thing gets built that nobody wants.

> Ask: What are you not doing instead? Real life is all triage and trade-offs. > You need to understand what's not happening so you can communicate that to > interested parties. And so you can make sure the right trade-offs are being > made in this case.

One of my biggest pet peeves in people making decisions is when they refuse to do the actual explicit analysis of costs, especially opportunity costs. Sure, you're laying groundwork for a good thing to happen in the future, but you're also costing that team the work of doing that and the rest of the group a bunch of work figuring out your new code layout. I can get behind it if I get a sense that people did the cost analysis but when the decision seems made willy nilly in a "this seems like it has a benefit" kind of fashion, it's really annoying that I'm spending time having to work with that.

</comment><comment><USER32> I can't really comment on non-technical managers, as all of the management at my company are former (and current) developers.

However, this list itself doesn't seem like a bad set of questions for a developer to ask themselves, let alone a manager ask the developer. We all know that it's all too tempting to fix the problem we want to fix, rather than the one that needs t obe fixed.

</comment><comment><USER33> If this methodology is overused, you will have your PM/dev team rebelling or leaving in a hurry.

That said, I can see a trimmed-down of this used as an evaluation tool for more substantial product development decisions. Ideally, these questions would be posed to a PM or dev manager and not directly to a coding team.

I also believe that the article is a good training piece for new(ish) general managers that have dev teams reporting to them. Along these lines, the listed criteria are a good thing to keep in mind for those GM's who (like me) sit in on product meetings while remaining fairly inactive.

IOW, the GM can listen-in and try to passively assess whether the team has a handle on these points. If not, address surgically and offline with the right folks.

</comment><comment><USER34> I was happy with the article content until I got to the examples.

These examples promote been suspicious of everything and treat the technical people as non-professionals. So I took exception on it.

"I'm making a generic version of…" It means: I don't understand the constraints of the actual problem, so I'm going to design an even bigger problem that we have no way of verifying the efficacy of.

BS. One of the most successful projects that I have delivery was so BECAUSE I started with a generic version of the core business concepts, and then I made a specific version for the different intra-department routings. There was more investment up on front, but it was recovered with gains at the end. Extracting the cross-cutting concerns into more generic versions is the right way to go.

"I'm creating a framework to…" It means: I'm not interested in solving the actual problem, so I'm going to create something else so that the person that actually will solve the problem has to also fix the problems in my stuff on top of that.

Same thing, is the cross-cutting concerns are implemented in a common framework, then you will have a high level of code reuse.

"It's platform independent." It means: I literally have not spent two seconds thinking about what platforms this will obviously not work for.

Sometimes you don't need to cover all platforms, but a few ones. So I might have to think what platforms will not work for and I still need to make it platform independent.

"I'm adding this to make sure it's future proof." It means: I believe in fairies.

One of the biggest compliments that I get from my work is exactly this: It has been 10+ years and we are still using what you created and finding gems in your code. If you have not received this kind of compliment either you are too young to write this article or know very little about architecture

"I really need to refactor this bit…" When you hear "refactoring" it's a bit more of a yellow flag. Technical debt is a real thing that needs to be addressed and that you should be aware of.

I cannot count how many times I have found myself in front of the question "Can you fix it?" and answering "This is such spaghetti code that I would really need to rewrite it, let alone refactor it.

I seem to me that these kind of recommendations are for a specific niche of software development. Enterprise (not enterprisey) level development, can have valid counterexamples for all and each one of what was described in the article.

</comment><comment><USER35> TLDR; How to be the Pointy Haired Boss.

</comment><comment><USER36> Management is (and should be) different for businesses where engineering excellence is a necessity versus businesses that just need competent/efficient technical solutions to non-technical problems.

This article is clearly about the second type of business. And it's designed to defend the second type of business against programmers who think they work for the first type of business.

<comment><USER37> Kindly disagree. If a business has a need that is critical to the business, not hiring a person with technical experience to manage technical things is just a mistake (or the business being lazy). I dont understand the shying away from hiring a qualified individual here. The fact is, its 2017 and there actually are a fair amount of qualified technical managers who can communicate and fufill the role.

Many other comments have pointed out various analogies in other fields that reinforce this.

<comment><USER36> If the business's primary objectives are non-technical, there will be some level of management that is non-technical, and they need some guidance.

This article isn't the greatest, but it doesn't seem terrible to me.

Note that "technical" is a matter of degree and relative to the team being managed. It doesn't necessarily mean they dictate their emails to their secretary.

</comment></comment></comment><comment><USER38> This piece is chock full of ridiculous advice.

>> "I'm making a generic version of…"

>> It means: I don't understand the constraints of the actual problem, so I'm going to design an even bigger problem that we have no way of verifying the efficacy of.

Yes, just tell the non-technical managers that "generic" means technicians have no idea what they are talking about. No matter what the problem is. That should make for a better world.

Whereas "refactoring" is only a "yellow flag".

Run away.

<comment><USER39> I think it's healthy to be _skeptical_ of people claiming to be solving a more general problem than the actual problem at hand (which is a large fraction of the advice in this article). Unfortunately, a non-technical manager trying to drill down into an argument about cross-platform, generic, or framework solutions to problems is quickly going to get lost and/or piss off engineers.

<comment><USER40> Non-technical managers often fail to account for the Inventor's Paradox [1]. They assume more general solutions will necessarily require more resources. This is often not the case _even if you ignore the resources which would be allocated to problems (solved in the general case) that you do not yet have_.

1: [https://en.wikipedia.org/wiki/Inventor%27s_paradox](https://en.wikipedia.org/wiki/Inventor%27s_paradox)

</comment></comment></comment><comment><USER41> Oh great. Let's tell managers that wanting to refactor is a yellow flag. What a terrible idea.

</comment><comment><USER42> That sounds like a very frustrating and untrustful interaction with one's manager. Good luck hanging on to your team members with all that.

But the important thing is that _you_ understand, because you're the manager! Right?!

</comment><comment><USER43> tl;dr. How about not having non-technical managers LOLOL</comment>


Prototype to Polish: Making Games in Chicken Scheme with Hypergiant - <AUTHOR> http://alex-charlton.com/posts/Prototype_to_polish_Making_games_in_CHICKEN_Scheme_with_Hypergiant/

<comment><USER2> [https://news.ycombinator.com/item?id=8850722](https://news.ycombinator.com/item?id=8850722)</comment>


Ask HN: Help prepare for AWS solution architect associate certificate exam - <AUTHOR> I am working as a developer from past 6 year and was involved in DevOps activities from past 2 years. I am trying to move into DevOps domain and want to get a certification for the same. I have worked full-time on AWS from past 6 months and created infra from scratch (mostly automated using cloud-formation) for a website. On giving some mock-test for Solution architect associate i score 500 out of 1000. I want to know some resources ( open-source/paid  ) which will help me prepare for the certificate examination. <comment><USER2> I used the course on Linux Academy, plus an Anki deck I found in the list of shared decks. That, along with making up a bunch of questions in an Anki deck myself, using the FAQ pages for the various AWS services, was good enough to pass comfortably.

That said... The test is _not_ easy. I studied pretty hard and have a considerable amount of real world experience with AWS, and I was honestly a bit nervous when I got to the end of the test. I usually try to over-prepare for tests like this, and usually expect to go in and score pretty close to 100%, and on this one, while I had no problem passing, I wasn't even close to a 100% score. Take that for what it's worth.</comment>


Ask HN: Low-delay one-to-one livestreaming - <AUTHOR> I would like to be able to watch and kibitz online as a friend streams a videogame from her Windows PC, as we did before she moved across the country. She's tried Steam Broadcasting and Twitch, but they both introduce large transmission delays--10 seconds and up--which makes it frustrating to try to talk about the action onscreen. I understand that this is necessary for buffering and other overhead when you're potentially streaming to hundreds of people at once, but for one-to-one streaming, I feel like we can do better.<p>Is there a good (and not too difficult to set up) way to stream video from Washington to Kentucky with <5sec delay? <comment><USER2> The only thing I can think of is WebRTC. Google WebRTC and screen sharing.</comment>


How to Create a Micro-SaaS - <AUTHOR> https://www.chrisfrantz.me/how-to-create-a-micro-saas/ <comment><USER2> Essentially the idea of the article boils down to finding a job title, creating something to help them with their job, and then promoting it to that audience.</comment>


What are some startup ideas that persistently fail? - <AUTHOR> http://www.quora.com/What-are-some-startup-ideas-that-persistently-fail/ <comment><USER2> If failure is defined by not getting articles written about you in Quora / TC then certainly.

Re dating sites: Try OkCupid / POF. Or the up and comer LikaALot.

"Social recommendations", seriously are you insane? Do you have any idea how much business is driven via social recommendations? If social recommendations didn't work then amazon would have no 'people who bought, also bought...' If you had a company that could make those things 10% better you'd have a truckload of money.

Anything that makes programming "easy for non-programmers or businesspeople": You might want to ask a little company called Microsoft about that and how much money they make by making it easy to program. Perhaps you've heard of something called ruby / python, that offload massive amounts of intellectual capacity off of programmers. Seriously, how many ruby programmers know assembly? How many companies derive incredible amounts of money from things like profilers, etc. Barely, anyone programs computers anymore.

Anything involving paying people to look at ads: You might want to ask the hundreds of companies that run things called 'focus groups' about that.

Anything that promises to make email a thing of the past: You've probably got an IM client on your desktop, might want to ask 37 signals about a product called Campfire. There's also that company called Twitter.

<comment><USER3> As for programming for non-programmers, Ruby is still a programming language for programmers. Just higher-level one.

But there are tools like LabVIEW and Simulink (MATLAB plugin), which are fairly popular among engineers.

<comment><USER4> Ok, I tell you one everyone knows: Excel.

<comment><USER5> Yes, spreadsheets are the obvious case of "programming for non-programmers" having succeeded. Are there others? Hypercard? Lotus Notes?

<comment><USER6> HTML?

</comment></comment></comment></comment></comment><comment><USER7> I would be hesitant to draw far-fetched conclusions from this. Often an idea persistently fails until someone finally does them right and then it doesn't fail anymore. One example is document synchronization; people justified the consistent failure of synchronization solutions with all sorts of explanations (including the "people just don't need it" joker card) until Dropbox came along, did it right, and now synchronization suddenly doesn't seem to be a "dead on arrival" idea. There are plenty of other examples.

It's easy to justify the failure of a product or solution by blaming the circumstances, like the "market not being ready" or "people don't need it" or "the market is too small" etc. Often, it's just that the product sucks, which might or might not be the fault of the creators.

TL;DR: Ideas only keep failing until someone does them right.

<comment><USER8> "Often an idea persistently fails until someone finally does them right and then it doesn't fail anymore."

But I very strongly think that you should _know_ that you are walking into a minefield, rather than just blundering into it. You should know that you need to learn the landscape, try to figure out what failed, and sail your project through what may be a very narrow window hard to find by chance, as opposed to other startup core ideas where success is more about perseverance and market savvy and a lot of other things other than sailing through a very small technical window.

Also, document synchronization is a word I'd save for actually trying to synchronize _documents_ , change tracking and merging, etc. Dropbox isn't the first to _solve_ the problem of presenting your backed up files as a folder, a much simpler problem, they're just the first to _productize_ it for consumers successfully. Business and open-source-technical solutions were around for a while.

</comment></comment><comment><USER9> It's interesting how little value the answers to this question seem to have.

dating/t-shirts - Lots of people date and buy t shirts online. I don't get this.

social or mobile _____ - How long have these been pursued? Most people don't even have smartphones yet and the first and only social thing they use is facebook. Patience.

grocery delivery - I can get groceries delivered in my area (melbourne) by one of several big companies. 10% or 1% of a one of the biggest markets is not failure, is it?

Maybe it's not possible to answer this question in a useful way.

<comment><AUTHOR> well, I asked pg to post a list of ideas he regularly rejects but I haven't seen any.

<comment><USER10> Essential reading: <http://www.paulgraham.com/ideas.html> :-)

</comment></comment></comment><comment><USER11> Micropayments is a subject of interest to me, because my current hybrid honours-project-slash-startup work is in approximately that field.

The business model I'm following most closely resembles the now-defunct Contenture; Readability is similar but not identical. Obviously I have some additional technology secret sauce or there wouldn't be a project in it to satisfy university requirements.

To me the main failing of conventional tipjars is the requirement to manually tip the recipient. To my eyes Tipjoy was the first real twist on this -- that you could commit to tip before paying -- but otherwise it was the same as Flattr and the dozens of others that have come and gone in this space. Flattr's twist is OK, but I think imposes even more potential cognitive overhead in terms of "I really like this site, I need to find more articles to flattr".

I think that the Contenture / Readability / my-company-name-here model works better because it requires no thought on the part of the customer. Payments are divvied up automatically. No transaction cost ("Do I tip or not?") is imposed on the user.

Mind you, my most imposing business obstacle is getting a merchant account. Businesses which take money from party A and pay some portion to party B are basically viewed as kryptonite crossed with rat poison by the banking sector.

Fair enough, too -- such businesses have statistically high rates of complaints, failures and money laundering shenanigans.

<comment><USER12> Check out Kachingle too: <http://news.cnet.com/8301-17939_109-10236893-2.html>

<comment><USER11> I remember when I first learnt about Kerchingle -- I was gutted. I thought that my idea was unique super-magic that would made me rich and I guarded it jealously. At the time I felt that the first mover would take all. Since then watching Facebook taught me that even an enormous network effect advantage can be defeated and absorbed if you have the right mix and a smart growth strategy.

I don't think Kerchingle's model is right either. They still require you to click their medallion to begin payment to a publishing site, introducing that same cognitive disruption as conventional tipjars. Also I think the "social cents" thing is basically nuts. Far too easy to be embarrassed. It smacks of that idiotic site that published credit card transactions. Blippy? Blit? Something like that.

<comment><USER12> The problem with money is everyone wants it and no one wants to part with it, or as little as possible!! I'd be interested in having software analyze my browser history (and my bookmarks), work out where I spend the most time or what is important to me, and allow me to spend some money that will go directly to those sites. A 2 minute carefully interfaced exercise every 6 months to a year. No background plugins, and little or no complexity for the website to implement. Badaboom.

<comment><USER11> You're close to what I have in mind. I did look at time-based, but my 'secret sauce' doesn't fit it.

</comment></comment></comment></comment></comment><comment><USER13> Question and answer sites usually fall in this category (irony of this being on Quora is not lost on anyone)

<comment><USER14> Naver, yahoo answers, answers.com, and stackoverflow are counterexamples. You're right though that there are a lot of failures

<comment><USER15> I would classify yahoo answers as mostly a failure.

<comment><USER14> Really? It's been a top-30 web site for four or five years ... Why do you see it as a failure?

</comment></comment></comment></comment><comment><USER16> Things that people don't actually want.

But there are many examples of things and markets which at first didn't seem all that promising. But then someone made something slightly different (or radically different) and it actually made users happy.

So just keep trying.

</comment><comment><USER17> One thing stood out to me:

Semantic Search

1) It might be that it is hard for mortals to formulate a semantic query

2) _AI is hard_

That struck me as a problem that might be worth working on. Presumably we're being paid to solve hard problems that might have value. If someone can improve search by tackling the AI problem and make it relatively easy for people to use, they could push search to the next level.

<comment><USER18> Semantic understanding (including the Semantic Web) will always be alluring, but it's just not going to happen. We can't agree on semantics in real life except in small groups or in very shallow ways. Computers just aren't going to be any better at it until we create something smarter than ourselves.

I'm not saying some of the automated semantic extraction technologies are useless. Some of them are very cool, and it is absolutely the way we should be heading (waiting for humans to tag everything is a waste of time). However, we need to recognize while this path is taking us somewhere good it will ultimately fall short of the vision--much in the same way that the AI field has given us some great improvements without approaching a true artificial general intelligence.

</comment></comment><comment><USER19> Wow! I would never say something would fail because it has failed in the past. Things fail because they're not done right. Demand can be created (and destroyed). This list is a list of opportunities IMHO.

<comment><USER20> Right, the idea is only a small part of the equation, actually getting it to a state that people like it is the other.

These ideas are probably simply the most popular startup ideas. Which means they also fail the most. Or simply, no one got them right yet.

For example, Dropbox became a big hit where a helluva lot of online drives and sync services failed before.

<comment><USER19> Absolutely! Or the iPad, tablets were around for years.

</comment></comment></comment><comment><USER14> My first reaction was that unlike most Quora questions, the answer summary is quite good on this. When I looked at it more, though, I realized that it didn't distinguish at all between more-popular and less-popular answers: the wisdom of the crowd (such as it is) has been lost. Also, credit for the answers isn't included; and neither are links ... so it's still far from ideal.

</comment><comment><USER21> Actually, quite a few of these ideas persistently succeed. Dating sites, t-shirts, rss readers -- how many times have those worked since the dawn of the Internet?

<comment><USER22> dating sites and tshirts will never die, but rss readers are a blast from the past - even firefox removed the icon because people didn't use it. rss is essential to provide content for web services when you don't have an api, but on the user end it's not used anymore due to social newsstreams, dashboards, etc.

<comment><USER23> I'm not entirely sure actually - I think that the majority (if not all) of RSS readers are out dated and lack "social" features that are necessary for them to succeed. I'd list some of my ideas here but I'm currently building a very simple "RSS reader" that might solve the problem - it'll be at <http://www.northpad.com> when it's finished.

<comment><USER22> [http://www.staynalive.com/2011/05/twitter-and-facebook- both-...](http://www.staynalive.com/2011/05/twitter-and-facebook-both-quietly- kill.html?q=1)

[http://www.staynalive.com/2011/04/rss-is-not-dead-concept- of...](http://www.staynalive.com/2011/04/rss-is-not-dead-concept-of- subscribing.html)

</comment></comment></comment></comment><comment><USER24> Maybe recommendation engines fail just because the math is crappy. Current scholarship in the field is pretty shallow and/or hackish.

<comment><USER25> The best algorithms in the world won't make up for a lack of data. Few companies are in a position to make good recommendation engines.

I also don't think math is to be blamed -- human psychology plays an important role -- i.e. I may be interested in software-dev stuff or in startups stuff, but not every hour of every day. Basically I'm inclined to read such stuff only in the morning, while drinking my coffee (the perfect time of day for big plans).

But in the afternoon I prefer reading articles about my OTHER (lighter) interests / hobbies, like photography. And I also prefer getting stuff solved, like finding an electrician to fix the poor wiring in my house or searching for gifts for my wife/child.

For any person on this earth, immediate interest in something is relative, based on time of day, time of year, mood, current needs, current problems, current hobbies, etc...

A good recommendation engine is practically unfeasible -- because if it cannot anticipate your future desires, both short-term and long-term, then it's useless; because people "search" for stuff as soon as they realize they have a new need/desire, and then it is too late to make a recommendation (at this time, the user's history is only useful to "understand" / parse the search query).

Recommendations need to happen before the user searches for stuff.

For example -- I searched for books on drawing / colors on Amazon, and bought 2. Amazon should have anticipated that I may like getting into photography, as they do know a lot about me, but it didn't, even though Amazon's recommendations are some of the best. Now that I already bought stuff, I don't care about special offers on the same kind of stuff that I already bought.

Also, people with "hackish" attitudes have done pretty amazing stuff btw, contributions to AI included -- software isn't just math, it's also biology / chemistry / physics / psychology / philosophy, amongst others.

<comment><USER26> There is no reason why time of the day, temperature outside, whether Obama made a joke or not, etc can't all be features for a classifier to learn.

I love the idea of an algorithm anticipating my next move and I'd argue that for the vast majority of people you can find repeating patterns that are almost always relevant. These patterns will not be simple or obvious and as you currently pointed out, the lack of data is what is holding most innovation behind. I feel that companies that own the data like Amazon will have a lot to gain if they do a Netflix-style competition to improve their recommendations engine.

<comment><USER24> assiotis, have you tried giving a bazillion data points to an SVM? One needs a sensible kernel as well.

</comment></comment></comment></comment><comment><USER27> All the answers that said "its already been done" are not quite right. Its often possible to do it better and eat their lunch. Look at DropBox. Lots of mountable-cloud-storage solutions existed but they were (are) fragile and expensive.

</comment><comment><USER15> Something tells me the very question is wrong. If you think avoiding failure = avoiding bad ideas, then that tell me something about you: you place too much an importance on the idea. If you're already thinking this way, eh, I can't help but feel you're already starting on the wrong path.

The better question would perhaps be about a list of common reasons for failed startups. I don't think "having a bad startup idea" would be anywhere on the top of that list. Or for that matter, even "repeating a failed idea" wouldn't occur on the list.

</comment><comment><USER28> There are so many examples prooving that the type of shallow analysis given in the first answer is pointless. I thought it was finally understood that it is not the idea that matters but the execution. According to this type of analysis, google was doomed from the start, dropbox as well, Android dito, etc. etc.

My advise would be to ignore such type of answer and focus on making something people want and generates traction. The author of the answer is too narrow minded and lacks imagination and creativity.

</comment><comment><USER10> There is a difference between a bad 'idea' and a bad implementation of an idea.

Early search engines were pretty bad (Lycos, Altavista etc) - why? because the idea was bad, or the implementation was bad?

I would say that if all dating sites fail in the same way then maybe there is a brilliant opportunity to build one that works...which is what google did with search engines.

</comment><comment><USER29> I like the overview, although I'd vastly prefer a list of startup ideas that persistently succeed.

<comment><USER19> For any success, there are countless failures.

</comment></comment><comment><USER30> Music and micropayments are definitely uphill battles.

</comment><comment><USER31> I think it's worthy to define failure first.

Company no longer exists? Completely bankrupt? Burn rate continues to increase? Point is, even if a company goes bankrupt you can still can technically still sell it. Does a failure constitue that all assets of a business are completely no worth anything?

Side question - how do you actually close a company?

</comment><comment><USER32> My favorite is craigslist killer...because craigslist is already dead. So true.

</comment><comment><USER33> #1 "I can do it all"

#2 "I am smart enough to manipulate the system to beat the tax-man"

<comment><USER11> 2 is possible in the present, but the problem is that in the long run, the taxman can change the rules and you can't.

</comment></comment><comment><USER34> Startup ideas that confuse "persistent" with "consistent".

</comment><comment><USER35> _Anything that makes programming "easy for non-programmers or businesspeople"_

Hypercard.

Speaking of which, why did Hypercard die in 2004? With the explosion in computer use by so many 'normals', I would think adoption would be huge. I'm not aware of any web-based technology that would enable Hypercard level of minimalist, user-friendly programming.

<comment><USER36> _Anything that makes programming "easy for non-programmers or businesspeople" Why? Make Car repair "easy for non-mechanics" ... presumes people want to work on their own cars. They don't._

I don't buy in to this answer. People obviously connect with the idea of creating content on their computer whether it's word processing, creating music, or editing photos. I think people like the idea of creating their own programs too.

The problem with general programming is that the output is too ambiguous, so it's impossible to build simple tools to express them. Lego for instance has a drag and drop tool for programming mindstorm legos but the input and output are a known quantity. With PCs it is impossible to anticipate everything that can and will be built.

<comment><USER37> I also don't really buy that answer, but I think it's partly because many businesspeople already _do_ do their own programming, in Excel, a good-enough solution that also has the critical edge of being installed on most corporate machines. There are thousands of people who don't consider themselves programmers who do _all kinds_ of what amounts to dataflow programming in Excel, ranging from quick scripts that automate repetitive tasks (what Unix folk might use a shell or Perl script for), to full-on modeling and simulation.

<comment><USER38> It always strikes me that Excel is essentially a functional programming language. A limited one perhaps (no looping/recursion) with an awkward syntax (all those commas), but still one that tons of non-programmers manage to learn and create powerful stuff with. This language then has an IDE that is quite advanced in some things (conditional formatting, charts) while strangely archaic in others (why are all variables are laid out on a grid?)

I wonder if there's an opportunity for a product that introduces a more powerful programming language and steps away from doing all the calculations on a grid, but that keeps the intuitiveness of Excel.

<comment><USER39> You are right that Excel is the most widely used programing language, but it _does_ have recursion and looping. They might be hidden under various tools (Macros for the trivial case, but Goal Seek for optimization, Data Tables for exploration, and Solver for multilinear optimization). Excel also does have the ability to have a "variable" hold multiple values. Pressing control-shift- enter will allow you to start using arrays in the cells, and there are a ton of functions that can handle them.

So the reason excel won as the common mans programming language is that it doesn't force you to learn everything all at once. It starts you off as just a table of sorts (useful on its own), then you can graph stuff (useful), then you learn about sum(a1:a30) (useful), and you just keep going down the rabbit hole until you've mastered everything.

The only thing that I really hate about Excel is that Procs cannot be run in parallel _, otherwise so many other cool things would be possible.

_ last time I checked, at least.

<comment><USER40> >> The only thing that I really hate about Excel is that Procs cannot be run in parallel, otherwise so many other cool things would be possible.

I think Excel 2007 and further, Excel 2010 improved on that. Pivot tables, formula calculations and many other addins (not sure about Solver) use multi- threading.

</comment></comment></comment></comment></comment></comment><comment><USER41> saying that craigslist is dead... the person probably never tried to buy a (cheap) used car or a rent an apartment.

<comment><USER42> Craigslist is dead? News to me. I was using it just the other night...</comment></comment>


Show HN: Developed a small web-app in 6 days. Help me make it better. - <AUTHOR>

Less than a week ago, my co-worker suggested an idea for a small web app:  Put your waiting lists online. We fleshed out some plans and put together who-next.com.
It doesn't revolutionize the world or anything, and it will be very surprising if it makes a cent, but it's up and live and I'm proud of it - not too bad for a week of work.
Feel free to login with u/p: demo/demo and tell me what you think - any suggested improvements are particularly appreciated. <comment><AUTHOR> I'm happy to answer any technical questions about the app. It's pretty boring though, LAMP stack, jQuery.

The other thing I would kill for is any ideas on how to market this. How to market it, and to whom. I can run around to all the local creches and nurseries with flyers etc, but in terms of online marketing... I don't have a lot of ideas.

<comment><USER2> i think best way to let user know about your app is by making it free and running it on beta until you have irresistible feature in the app. by then your will be having quite enough users who can signup for premium services.

even writing technical blog about how you implemented the app will drive users in for testing the app that is really great way for getting feedback and improving features.

creating plugin for popular frameworks and cms will also add a value and you will soon see users using it.

if you have enough users or customer you will soon see people getting interested in investing in the project

hope this help

</comment></comment><comment><USER3> >We remove all the drudgery in managing lists manually. At $4.95 per queue...

I wouldn't put a price tag in the description so quickly. Most won't understand what you're up to until 3-4 sentences in, and you're already asking for money.

Hope that is helpful.

<comment><AUTHOR> Huh. I guess that does clang a bit. I suppose the more frequently used approach is to sell sell sell, raise expectations, and then drop the curtain and reveal the pricing.

Thanks for the tip, will think about how I can re-work it.

</comment></comment><comment><USER2> i think the app is good may be a little bit of the design improvement and making the app completely free will grub some attentions. may be making it as service with apis to queue from a java scripts which can be used in static sites

<comment><AUTHOR> Thanks Yunus. The design is definitely pretty bare ... TODO.

I'm not so sure about giving it APIs, I think the target market will be mainly non-technical. But I suppose given an API, the application could perhaps be leveraged in ways that I cannot anticipate right now. Interesting idea, thank you.

<comment><USER4> You add an API; someone builds a mobile app for it; your users find your service more useful; you retain/win more customers.

<comment><AUTHOR> OK. I'm not accustomed to that level of optimism :-) But I see what you're saying.

One API coming up.

</comment></comment></comment></comment><comment><USER4> Clickable: <http://who-next.com></comment>


The Clockwork City - <AUTHOR> http://www.digitalurban.org/2011/07/clockwork-city.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FEYWY+(Digital+Urban) <comment><USER2> Neat concept. I can see one problem, though...

It appears the rings are organized by urban function... parks on one ring, industrial on another, etc. Let's say I'm at my house and I want to go to my friend's house on the opposite side of the residential ring. Then what?

<comment><USER3> It's explained in the video. You go to the office ring, wait for a quarter rotation, meanwhile the residential ring has rotated towards you, then go back to the residential ring.

<comment><AUTHOR> They called it "Double Switch". It appers on 1:35 on the video[1].

[1] [http://www.youtube.com/watch?v=8HrPGfn47t0&feature=playe...](http://www.youtube.com/watch?v=8HrPGfn47t0&feature=player_embedded#at=95)</comment></comment></comment>


Fearless Concurrency: Clojure, Rust, Pony, Erlang and Dart - <AUTHOR> https://sites.google.com/a/athaydes.com/renato-athaydes/posts/fearlessconcurrencyhowclojurerustponyerlanganddartletyouachievethat <comment><USER2> I'm a bit surprised that there didn't appear to be any mention of Clojure's built-in concurrency support outside of basic immutability. core.async gives a nice channel-based system, agents give an actor-ish system, and STM/atoms let you mutate the variable safely, without having to manually work with locks.

This is definitely a good high-level article, just something I was surprised by, since core.async is what drove me (and several other people I know) to start using Clojure.

EDIT: Just a note that I know core.async isn't built in, that was a mistake. It _is_ a first-party library, however.

<comment><USER3> It's also worth noting that almost nobody uses agents or STM (except for some highly specific use cases, but I've never seen them in years), and core.async is a library, not a part of Clojure (which is a good thing, because it promotes choice and keeps the language small).

<comment><USER4> I did use agents in the past, but stopped since core.async became available: it addresses the use cases for agents in a much more flexible way. Also, I found that handling errors in agents is difficult.

As for the general use case, atoms and core.async are great tools, and I haven't needed to use refs (aka the STM) for years.

<comment><USER2> Don't the core.async go-blocks have issues if you need to block on IO heavy stuff, as in the thread-pool will be blocked until the side-effects are done? Agents don't have that problem, at least I don't think they do.

<comment><USER3> Yeah this is true, typically you want to keep blocking functions outside this. By default, core.async allocates as many threads as cores in your CPU.

In addition to this, I personally find core.async to deal poorly with flow control (e.g. slow subscribers slowing down the entire flow for every subscriber), and seems to not have a lot of telemetry / it's difficult to find out what's going on in the thread pool behind it.

I've personally settled on Zach Tellman's Manifold library, which provides a much more sane abstraction and is fully compatible with core.async.

For some addition thought and material on these topics, I highly recommend watching this talk by Zach, "Everything Will Flow" [https://youtu.be/1bNOO3xxMc0](https://youtu.be/1bNOO3xxMc0)

<comment><USER4> Hmm, interesting — but manifold is clj-only, and I use core.async both on server side and client-side in ClojureScript.

</comment></comment></comment></comment></comment></comment><comment><USER5> What's great about the actor model is that you can kinda apply it in languages not having such native support. Even if it will not be a strict model, with some education from the programmer it can do wonders and can be backed by lock free queues. What I see as a problem is always they for a thread to wait on new items a syscall must be executed which is costly. But one could use a spinlock a few cycles and later degradate to syscall.

<comment><USER6> I found it interesting that the article mentions actors much at all for the same reason.

It's pretty trivial to construct actors out of some other message passing system. The interesting design choices in doing so are mostly down to the semantics in A) message passing, and B) scheduling/triggering/mapping-onto- green-threads/etc.

And for part A, all the other choices in the first three segments of the article are still effectively the choices that you've got to contend with: copying vs immutablity (bonus, COW mode, but still) vs ownership semantics.

Or to come at it from the other way: actors are far _more_ featureful than is appropriate to directly compare to mere message passing semantics choices, because actors generally have some concept of error handling as a result of their relationship to scheduling, and that puts them on a whole different field.

<comment><USER7> That's a big reason I'm a fan of Erlang: individually, its features are interesting, but collectively they form an amazing system. Greater than the sum of its parts.

<comment><USER8> Agreed, it's one thing to have good primitives like Go channels but Erlang/Elixir provide an entire system from which to build a concurrent/async application. Things like error handling, messaging, storage, and structuring your application well for concurrency are already basically built-in into the standard approach you take building Erlang/Elixir apps.

<comment><USER9> Whats a tldr for how Erlang handles error handling?

This is something that is usually glossed over / afterthought when it is kind of a big deal in real life programming.

<comment><USER7> The language is built upon a few core concepts:

* Processes are extremely lightweight, orders of magnitude smaller than operating system processes or JVM threads.

* Exceptions should generally not be handled; instead, those lightweight processes are allowed to fail, and an external supervisor process will re-launch if appropriate.

* Assertions about the state of the data are effectively enabled on every line of code, so the processes crash early, before corrupting other parts of the system.

* Data is immutable, which plays a role in making those assertions happen.

You could probably strip one or two of those bullet points and/or add a couple of more, but I think that captures the highlights.

I'll toot my own horn. If you find that interesting, this is my favorite talk I've given about the above: [https://youtu.be/E18shi1qIHU](https://youtu.be/E18shi1qIHU)

</comment></comment></comment></comment></comment></comment><comment><USER10> In case the author sees this: The indentation of the code samples is all over the place, making it quite hard to read. Even more so for a white-space sensitive language like Pony. Did you mix tabs and spaces?

<comment><USER11> Pony is not white space sensitive.

<comment><USER12> Readers are though..

</comment></comment></comment><comment><USER13> The Rust examples seemed a little bit oddly structured to me; the case of collecting a value from a single thread would be just as easily solved by returning from the closure and receiving it through join(): [https://gist.github.com/lorkki/e7386df8fff186b3e473994e9d31b...](https://gist.github.com/lorkki/e7386df8fff186b3e473994e9d31bee0#file- thread-example-1-rs)

The power of channels could be illustrated better by adapting the next example to show how you can avoid shared state completely: [https://gist.github.com/lorkki/e7386df8fff186b3e473994e9d31b...](https://gist.github.com/lorkki/e7386df8fff186b3e473994e9d31bee0#file- thread-example-2-rs)

It's also worth noting that a more versatile channel implementation than mpsc can be found in the crossbeam crate, in case you're thinking of using them for anything more serious.

</comment><comment><USER14> And Eiffel Scoop which is always forgotten:

[https://en.wikipedia.org/wiki/SCOOP_(software)](https://en.wikipedia.org/wiki/SCOOP_\(software\))

[https://www.eiffel.org/doc- file/solutions/eth-46802-01.pdf](https://www.eiffel.org/doc- file/solutions/eth-46802-01.pdf)

It was ported to Java in a student project. That means other languages without great concurrency could probably use it with macros or a preprocessor.

</comment><comment><USER15> I was really excited to discover Pony a couple of years ago, sadly there is negative momentum with this project. So much potential, yet the world isn't ready for it yet.

<comment><USER16> Or Pony is not ready for the world. I mean, they don't even have arithmetic operator precedences [1]. If you're doing things concurrently it must be something uber-important, like censoring cat pictures, but apparently not arithmetics.

[1] [https://github.com/aksh98/Pony_Documentation#precedence](https://github.com/aksh98/Pony_Documentation#precedence)

<comment><USER17> > _Or Pony is not ready for the world. I mean, they don 't even have > arithmetic operator precedences_

Many languages don't have arithmetic operator precedence (Smalltalk, Lisp, etc) and that's fine.

It's not some feature that's missing, it's a design choice.

<comment><USER16> In Lisp and Smalltalk it's obvious enough how composite expressions are evaluated, and they don't have the usual infix syntax to begin with. Pony does and the different precedences are just a bad surprise. As far as that's a design decision, I'd call it bad design.

<comment><USER17> > _In Lisp and Smalltalk it 's obvious enough how composite expressions are > evaluated, and they don't have the usual infix syntax to begin with._

That's Lisp. In Smalltalk they do (have the usual infix syntax).

<comment><USER18> > _have the usual infix syntax_

Isn't it the case that all operators in Smalltalk have the same precedence and left-to-right associativity? That's not "the usual" infix syntax.

<comment><USER17> Usual referring to the mere "infix syntax" part (as opposed to some other kind of syntax that isn't infix).

Not to having "infix syntax plus the associativity / precedence you get in C". We've already established that it doesn't have the usual precedence.

The distinction was with e.g. Lisp which has a prefix syntax (polish notation), and other more exotic styles.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> It's too bad Perl6's interesting approaches to concurrency aren't mentioned here. Supporting concurrency and parallelism were key points in the design of Perl6, and in the multi-paradigmatic way of Perl, it provides a variety of tools.

Jonathan Worthington can write and speak about this topic far better than I can so I refer you to his talk and slides:

1\. [http://www.jnthn.net/papers/2018-conc- par-8-ways.pdf](http://www.jnthn.net/papers/2018-conc-par-8-ways.pdf) 2.C [https://www.youtube.com/watch?v=l2fSbOPeSQs](https://www.youtube.com/watch?v=l2fSbOPeSQs)

<comment><USER20> But these explicitly don't mention the two best approaches he chose to ignore and even kill.

First the parrot threading model, which provided lockless safe threadpools, and second the pony threading model which provides the same on top of supporting shared refs, and forbids blocking IO. Which makes it even faster.

His talk ends with his simple approach taken being the best. Which is not only wrong but also a lie, because he was part in killing off the parrot threading model.

<comment><USER21> Reini, get off your crazy horse man! No one in the world, including the author of the Parrot threading model, thinks it is the "best" threading model.

</comment></comment></comment><comment><USER22> For those of you who want to test multiple concurrency models, I can highly recommend Seven Concurrency Models in Seven Weeks from Pragmatic.

</comment><comment><USER23> I'll just mention that if you're using C++, the SaferCPlusPlus library[1] supports a data race safe subset of C++, vaguely analogous to Rust's.

[1] shameless plug: [https://github.com/duneroadrunner/SaferCPlusPlus#multithread...](https://github.com/duneroadrunner/SaferCPlusPlus#multithreading)

</comment><comment><USER24> Sorry, I do not know any of these languages but I have used Haskell's STM which is incredible. Any of the languages mentioned here close to the STM idea (basically using strong types to ensure mutations happen in isolated context)?

<comment><USER25> The idea of STM has nothing todo with strong types. You can have STM with types or without.

Clojure has a full STM since version before version 1.0. Simple example:

(def stm (refs {}))

(alter! stm assoc :testkey "testvalue")

(println @stm)

See: [https://clojure.org/reference/refs](https://clojure.org/reference/refs)

<comment><USER26> Important part of STM is that the retry mechanism requires functions to be pure - which haskell compiler will check for you.

<comment><USER27> Technically, STM requires that you're not updating your state via side effects. That's a different proposition from requiring your functions to be pure. For example, you could have a function with a print statement inside your STM transaction just fine.

<comment><USER28> If you want to go way down that rabbit hole, it's an active topic of conversation in the Haskell community right now how to break up IO into more granular pieces than what the IO type natively provides, where a function is either "pure" or it's a dirty rotten effects producer, and no middle ground in between.

Although, even a stray print inside an STM transaction could actually do you a lot of damage, since "print" is actually a fairly expensive operation. I've written all sorts of programs in my life that were technically bottlenecked not on reading the input, writing the output, or any of the processing in- between, but on the printing it was doing. And, relatedly, every community that tries to write a really blazingly fast web server in their language runs into a bit of a wall around the mere act of _logging_ the hits. (Even just the date computation starts to bottleneck things, but the writing does too.)

<comment><USER27> That's the difference between Clojure and Haskell mindsets in a nutshell. Clojure approach is to have sane defaults and guide the programmer towards doing the right thing, but ultimately letting them do what they need to. Whether it makes sense to do something or not is context dependent in practice. Ultimately, the person writing the code understands their situation best, and the language shouldn't get in the way of them doing what they need to.

You could of course argue that by preventing the user from doing certain things you avoid some classes of errors. However, I will in turn argue that by forcing the user to write code for the benefit of the type checker often results in convoluted solutions that are hard to understand and maintain. So, you just end up trading one set of problems for another.

<comment><USER29> > You could of course argue that by preventing the user from doing certain > things you avoid some classes of errors. However, I will in turn argue that > by forcing the user to write code for the benefit of the type checker often > results in convoluted solutions that are hard to understand and maintain. > So, you just end up trading one set of problems for another.

Funny, this is exactly the opposite of my take from a type system like Haskell's. The thing is, whether it's enforced by types or not, the same invariants exist in your code. The only difference is that in one case they are checked explicitly at compile time, and the other case they are hidden and can blow up your programs.

If anything, explicit invariants make code _easier_ to maintain and understand.

<comment><USER27> Except that they're not the same. Static typing restricts you to a set of statements that can be verified by the type checker. This is a subset of all valid statements, otherwise you could just type check code in any language at compile time.

Static typing makes many dynamic patterns either difficult or impossible to use. For example, Ring middleware becomes pretty much impossible in a static language [https://github.com/ring-clojure/ring/wiki/Middleware- Pattern...](https://github.com/ring-clojure/ring/wiki/Middleware-Patterns)

The pattern here is that the request and response are expressed as maps. The request map is passed through a set of middleware functions, and each one can modify this map in some way.

A dynamic language makes it possible to write middleware libraries that know absolutely nothing about each other, and compose seamlessly. A static language would require you to provide a full description of every possible permutation of the request map, and every library would have to conform to it. This creates coupling because any time a library needs to create a new key that only it cares about, the global spec needs to be modified to support it.

My experience is that immutability plays a far bigger role than types in addressing the problem of maintainability. Immutability as the default makes it natural to structure applications using independent components. This indirectly helps with the problem of tracking types in large applications as well. You don't need to track types across your entire application, and you're able to do local reasoning within the scope of each component. Meanwhile, you make bigger components by composing smaller ones together, and you only need to know the types at the level of composition which is the public API for the components.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> Speaking of concurrency, is there a current environment that does something similar to Linda? I always thought that sounded quite promising, but apparently that generally is a death sentence (I also liked Modula-3, the Palm Pre and Tcl).

<comment><USER12> I think that creating a Linda engine is a chicken/egg problem. If there are no applications that are using the paradigm, then there's no need for a highly performing engine.

</comment></comment><comment><USER31> You can also use Actors and elements of the OTP from Erlang in Clojure via certain libraries.

</comment><comment><USER32> > _Its use of dynamic typing makes me a little bit hesitant to use it, though, > as I really love the help provided by static typing._

There is dialyzer, a static type (and not only) analysis tool for Erlang. It is part of Erlang/OTP (i. e. built-in.)

[http://erlang.org/doc/apps/dialyzer/users_guide.html](http://erlang.org/doc/apps/dialyzer/users_guide.html)

<comment><USER33> Yeah as a long-time Erlang dev I would strongly recommend Dialyzer to anyone trying to build a serious Erlang project. It doesn't give you quite the same level of rigor that a strong typing system would, but it is nice to be able to spec out types on an as-needed basis while letting it infer types in other parts of the code. It kind of ends up feeling like a nice middle ground between static and dynamic typing, in my experience.

</comment></comment><comment><USER34> "The problem is, that sometimes, unfortunately, these tools are just not sufficient, it's still easy to shoot your own foot and get lost in a sea of complexity."

As a non-native English speaker I found this use of commas very difficult to understand. Often I get the feeling that native speakers don't even notice it.

<comment><USER35> The first comma is simply incorrect. "unfortunately" does need commas around it, but it could be moved to the beginning for a simpler sentence.

The fourth comma is also incorrect and should be replaced by a semicolon.

"Unfortunately, the problem is that sometimes these tools are just not sufficient; it's still easy to shoot your own foot and get lost in a sea of complexity."

And looking at that now, I would also get rid of "the problem is that". "Unfortunately" and "sometimes" back to back lacks flow, so I would also replace "sometimes" (in this case with "often" in place of "just"). In the original, "just not" has a stronger grouping than "not sufficient", which is why "insufficient" wasn't used. Now with "just" gone, I'd swap back in "insufficient".

"Unfortunately, these tools are often insufficient; it's still easy to shoot your own foot and get lost in a sea of complexity."

<comment><USER36> Just to aid people who are interesting in looking this sort of thing up, the fourth comma in the original is an example of a "comma splice", where the comma is too weak to join the two independent clauses. You can solve a comma splice by either making the two independent clauses into separate sentences, joining them with a stronger piece of punctuation (like a semicolon, colon, or a dash), or by using a conjunction like "and".

<comment><USER37> British English seems to be more forgiving about comma splices than American English. One certainly sees them much more frequently in British English.

<comment><USER36> I suspect it may be more the case that many people under 40 in the UK weren't really taught much at all in the way of grammar, and even people who have involuntarily picked up fairly decent grammatical skills still struggle with comma splices, which are, admittedly, quite a subtle sort of error whose detection is predicated by a full mastery of the purposes of the various punctuation marks _and_ an understanding of clauses.

</comment></comment></comment></comment></comment><comment><USER38> I am surprised it does not mention Ada. I really feel like that Ada is not getting enough attention, it definitely deserves more. Even if you have heard of the language before, please do check out some of the resources available, you will not regret it!

It has been supporting multiprocessor, multi-core, and multithreaded architectures for as long as it has been around. It has language constructs to make it really easy to develop, say, embedded parallel and real-time programs. It is such a breeze. I admit I am not quite sure what they are referring to by fearless, but if it means that they can handle concurrent programming safely and efficiently in a language, well, then Ada definitely has it.

Ada is successful in the domain of mission-critical software, which involves air traffic control systems, avionics, medical devices, railways, rockets, satellites, and so on.

Ada is one of the few programming languages to provide high-level operations to control and manipulate the registers and interrupts of input and output devices.

Ada has concurrency types, and its type system integrates concurrency (threading, parallelism) neatly. Protected types for data-based synchronization, and task types for concurrency. They of course can be unified through the use of interface inheritance, and so on.

If you are interested in building such programs, I recommend two books:

[https://www.amazon.com/Building-Parallel-Embedded-Real- Time-...](https://www.amazon.com/Building-Parallel-Embedded-Real-Time- Applications/dp/0521197163)

[https://www.amazon.com/Concurrent-Real-Time-Programming- Alan...](https://www.amazon.com/Concurrent-Real-Time-Programming-Alan- Burns/dp/0521866979)

...other good resources:

[https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency](https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency)

[https://www.adacore.com/uploads/books/pdf/AdaCore-Tech- Cyber...](https://www.adacore.com/uploads/books/pdf/AdaCore-Tech-Cyber- Security-web.pdf)

The last PDF will summarize in what ways Ada is awesome for:

\- contract-based programming (with static analysis tools (formal verification, etc.))

\- object-oriented programming

\- concurrent programming

\- systems programming

\- real-time programming

\- developing high-integrity systems

and a lot more. It also gives you a proper introduction to the language's features.

<comment><USER39> We learned some Ada in school. I really liked it, but the free toolchain was poor (hard to get working properly, unintuitive) and the community stubbornly defended its various idiosyncrasies like its verbose Pascal syntax and its homegrown project file format. Most importantly, it just didn't heave much of an open source ecosystem, and the community was pretty hostile and defensive toward newbies. But yeah, the language was neat! :)

<comment><USER38> When did this happen? Have you checked its current state? It has been growing ever since. There are dozens of tools available today for free, and it is very easy to set up.

I agree that its open source ecosystem needs to grow, but for that we do need more Ada programmers! :P

By the way, I am really sorry if you experienced hostility from the community. May I ask where it took place? I had similar experiences with a variety of communities, even Rust. I try to not be demotivated from the language itself, after all, it is not particularly the language's fault, and there are people like that everywhere. They need to learn that what is obvious to them is not necessarily obvious to other people, and asking is a sign of wanting to learn, which I believe is a good thing. :)

<comment><USER39> Hmm, circa 2012. I've checked in on it a handful of times in the ensuing years, but I came across Go in 2014 and it ended up suiting my needs almost perfectly (rapid application development, simple, great performance, mostly safe, fantastic tooling/ecosystem, zero-runtime-dependencies, etc).

As for where the hostility took place, it was most Ada proponents who would pop up in /r/programming, here on HN, etc. I'm sure the circumstances select for the most toxic folks from any community, but it seemed especially potent from Ada folks (could have been bad luck, ymmv and all that).

Would love for Ada to modernize and improve tooling/ecosystem, but between Go and Rust, I'm afraid that the advantages for a modern Ada might be marginal. It seems unfortunate for Ada that it didn't modernize prior to 2012; it could have eaten both Go and Rust's lunch before they even existed.

</comment></comment></comment></comment><comment><USER40> > it seems quite a lot easier to manage concurrency in Clojure from my biased > point-of-view.

Assuming you know that none of the code in your concurrent blocks are is side- effecting, which may be hard to know if it's not your code; Haskell checks this for you, so to me it seems easier in haskell, not harder, because I don't have to hunt down and read all the source code to know if what I'm doing has concurrency bugs or not.

</comment><comment><USER41> I'd also like to mention cooperative concurrency. I know the author kind of skipped over this from the first sentence of the article where he defined a concurrent program as having more than one thread of execution. But with coroutines, we can have a single threaded-application that handles multiple tasks concurrently too. In fact I believe this is much easier to reason about for the programmer: the kernel won't randomly decide this thread's time slice is up in the middle of an important data operation; the programmer knows exactly when an operation may cause the current task to be "descheduled" because those are usually explicitly tagged with the "await" keyword. In my experience, this model eliminates the vast majority (but not all) of the use cases for locks and other synchronization primitives. It is also very performant.

Take a look at Python's asyncio, which has been in the standard library for years, and you'll see how easy it is to write concurrent networking code without threads and with very very few uses of locks.

<comment><USER9> Did you just say single threaded concurrently reasoned applications are more performant than multithreaded applications?

Trying to reason about how this could be possible. I'm still amazed by the performance you can get out of async non blocking style application code so don't take this the wrong way, truly trying to understand here.

I'm also a little confused about threads being rescheduled by the OS being treated like an inconvenience, to me it's a feature that prevents one application being too hoggish.

I can see your point that it's nice to have these labelled with await but I'm struggling to pinpoint a time I've asked myself what thread scheduling might mean for my code. Other than just assuming that another thread could be anywhere doing anything which I think is the correct approach no?

Locks btw, totally non issue with the right API/Lang support.

<comment><USER41> No I didn't say "single threaded concurrently reasoned applications are more performant than multithreaded applications" because I was highlighting this style of concurrency from the programmer's perspective. But yes, for certain types of applications it can be more performant.

Naturally, if your application is computationally intensive, a single thread can't compete with a multithreaded application. But for applications that use a lot of slow, blocking I/O, converting them to a single-threaded application that uses non-blocking I/O is a significant reduction in overhead. Compare a traditional web server that uses one thread per request and blocking I/O, versus one that uses an event loop, non-blocking I/O. You will see why the latter is more efficiently on system resources. Again this isn't a panacea, and for some applications you do have to use threads. I'm just pointing out an omission of the article.

<comment><USER9> Thanks for the clarification I see your angle now.

I'm not trying to debate on this, pretty sure we're just reasoning about facts we both agree on here.

I was aiming for a more general stance but if were talking about web servers there is one thing we might disagree on being the net benefit of non blocking in that specific scenario.

Let me see if I can explain, the individual requests may contain a lot of slow blocking io but these are handled async with a thread per request at the server level. So the request and internal blocking is limited to the request only (ignoring thread pool limits.)

While it may be that non blocking might produce more performant request level handling in some cases most or at least a substantial amount of web request logic is very dependent on chaining those blocking io one after the other, e.g. get thing modify, return.

In blocking you execute and reason about sequentially in non blocking you reason about with callbacks or syntactic sugar around promises specifically because sequential programming is easier to reason about.

The point of difference being that in non blocking you have a lot of overhead in the event loop and in the implementation, all to produce sequentially executing code that doesn't block other requests.

This is sort of why me and a few colleagues came to the conclusion PHP is still pretty damn decent for web stuff.

Non blocking is great for concurrency where it actually results in parallelism but if it doesn't then there isn't much gain other than gained complexity.

All this needs to be taken with a grain of salt. Node has Async await for a reason, and I've seen a few different implementations of non blocking php as well.

The choice really comes down to which style you find your self benefiting from on the regular.

Bleh that needs about three rounds of editing before it makes sense, something I don't have time for. Sorry for the ramble!

</comment></comment></comment></comment><comment><USER42> What about picking jobs from an SQL-table as writing back with a check? I naver had any of the problems specified on a multi-core/process system.. or have I just been lucky or blessed by ignorance?

<comment><USER43> That's an example of shared-nothing message-passing system, which is a perfectly valid solution. It's implementable in all the aforementioned languages.

</comment></comment><comment><USER44> I am not sure but I think Go channels were inspired by CSP (communicating sequential processes) which is not inherently unsafe though.

<comment><USER29> from the article:

> Notice that this article does not include Go, a language that admittedly has > an elegant concurrency solution as well (Go channels) because that solution > is _not actually thread-safe_ \- it's not very hard to have race conditions > in Go or corrupt state because Go does not enforce a separation of shareable > and not-shareable mutable state.

<comment><USER28> My vote for Go's #1 mistake isn't the popular "lacking generics", but missing the opportunity to have fearless concurrency, and making it so that goroutines can only communicate via immutable shared values and copied values. If you want to optionally and explicitly penetrate that barrier sometimes, I'd be OK with that, but this should be the default.

Generics will probably be added after the fact 10 years after the 1.0 release. They may not be quite as slick as something that was in there from the beginning, but based on the many other languages that added them after the fact, it'll probably work out well enough. Fearless concurrency can't be added to a language; if it's not in there from the beginning it'll never be added. It's a change so big it's almost automatically a new language. And, as can be logically deduced from that statement, I am aware that it would have some additional effects in the language, such as introducing immutability, it wouldn't be simply what we now know as "Go" with just a minor tweak. I'm comfortable with that. Even with Go's focus on simplicity, I do think there was a slight error towards being a bit simpler than the problem permits here.

(I do pretty well with Go's concurrency, but I was first trained brutally by Erlang and Haskell. I see those who don't come by the same route have more trouble.)

</comment></comment></comment><comment><USER45> Man the indentation in this article is confusing me.

</comment><comment><USER46> technically node achieves it as well.

</comment><comment><USER47> I have a, perhaps unjustified, concern at the loss of fear around things like concurrency. People keep substituting appeasing the compiler with actual thinking around _hard_ problems. But until the halting problem is solved at a compiler level (at a level that can account for runtime cases), you should always have a healthy amount of fear when writing concurrent code.

Fear, and respect, the absurdly difficult challenge that is writing correct concurrent code, even when your compiler is helping you out.

<comment><USER48> I find this line of thinking to be a holdover from an earlier age. One could replace the word "concurrency" in the above comment with "memory safety" to express the popular sentiment as of the 1980s--but in the decades hence the vast, vast majority of programmers have come to be able to completely ignore concerns related to the careful management of allocating and deallocating memory, and though we can argue that the result is a proliferation of memory- hungry Electron-like apps, on balance it's been a dramatic victory for letting people focus on solving the problem at hand rather than distract them with tiresome pointer-juggling.

It's true that in the 90s it was important to cultivate a healthy fear of concurrency in the same way that parents in Cambodia must sadly teach their children to fear landmines. However, there's nothing inherent in the problem space that dictates that the concerns of one's ancestors must be the concerns of their descendants. One day we hope the landmines in Cambodia will be cleared, just as we hope the landmines in concurrent programming will be, and I'll be thankful when that day comes.

<comment><USER47> How do you solve for deadlocks at the compiler level? Even if all your memory access is perfectly safe, you can still deadlock on external resources if you aren't pay attention.

That's what I mean by fear and respect for concurrent programming. That's the problem that hasn't been solved.

<comment><USER49> Deadlocks is a solved problem. Technically, they can't even exist in any concurrency model that doesn't share anything. What can exist is processes waiting for messages from each other, but that's not a deadlock, but a valid behavior and is only potentially problematic without timeouts. Asynchronous message passing with event-driven/reactive semantics farther enforce impossibility to block on waiting for a specific message. In practice strict event-driven semantics are not necessary for it to never be a problem.

<comment><USER50> Deadlocks are not restricted to shared memory communication. Two Unix processes talking via a socket pair can trivially deadlock ( for example if they are both blocked waiting for the other side to speak first).

Also asynchronous systems can deadlock as well, it is just much harder to debug as the debugger won't show an obvious system thread blocked on some system call; the deadlocked threads of execution still exist but will have been subject to CPS and hidden from view (just some callback waiting forever on some wait queue).

<comment><USER49> It's not useful to use the same term for very different kinds of things. Shared resource deadlocks are common and disastrous problems. Share nothing mutual blocking is uncommon, not necessarily a problem at all and can be completely harmless and automatically recovered when it is a problem. For example, spawning actors to wait without timeouts would be absolutely ok, parent can do all the timeouting and kill the children.

Two processes blocking on a socket is not a deadlock. Surely there are timeouts on both sides, because using sockets without timeouts is just ignorance, and both will just timeout and move on.

Also strictly statically declared event handlers per actor are 100% mutual blocking and deadlock free. Because they can't wait for messages in a way, that blocks other event handlers.

<comment><USER50> The term deadlock has been used for message passing issues since the dawn of time. It is literally the same issue.

Using timeouts to paper over issues is just wrong. I accept that timeouts are necessary to deal with network issues (and a timeout should cause the connection to be dropped, so won't solve the deadlock issue), but certainly they are not required for in-application message passing.

Finally if an actor won't send a message untill it has received another one, I fail to see how statically declared handlers will help.

<comment><USER49> > Finally if an actor won't send a message untill it has received another one, > I fail to see how statically declared handlers will help.

Think of it as reacting to messages, not waiting. In that model actors of course can react by sending messages, but can't have a special waiting state for specific messages, making it impossible to block other handlers. I'm not sure why this is hard to understand.

We do have this problem solved in every possible way. But it's so not a big deal with actor model, that there is no point sacrificing any flexibility for it.

<comment><USER50> Forget about waiting. Think about state machines. Let's say that that there is a rule that, if the machine is on state S1, on reception of message M, send message M and move to state S2. This the only rule for state S1. Now if two actors implementating this state machine and exchanging messages find themselves in state S1 at the same time, they are stuck. This is a bug in the state machine specification of course and I would call it a deadlock. How would you call it? How would the actor model statically prevent you from implementing such a state transition rule?

Edit: BTW, not sure why you got downvoted.

<comment><USER49> This is why I'm talking about specific model with static handlers per actor, where you can't choose handlers dynamically depending on the state you are in. Whether you are on state S1 or S2, all handlers are still able to receive messages, what they can't do is run at the same time.

<comment><USER50> It can receive all messages you want, but if the only message that it that would cause a state transition, and send out a message, is M, then it is still stuck.

I mean, I'm no expert, but I guess you could statically analize the state machine and figure out, given a set of communicating actors, which sequence of messages would lead to a global state from which there is no progress. I assume that, because message ordering is not deterministic the analysis is probably non easy to do.

<comment><USER49> Well, this is the limit all models have. You can abuse memory safety the same way and use indices of bounds checkable arrays as raw pointers for example.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER51> Whether or not this is "fearless" depends on your point of view.

As a long-time pthreads programmer, these systems feel like skittish concurrency. It's for folks who are too afraid to use the underlying concurrency primitives, like shared memory, synchronization of some kind provided by OS, threads.

<comment><USER52> Exactly. Because the recorded history shows those constructs are nearly impossible to use correctly.

<comment><USER53> Yes. Having spent too much time debugging code by people who thought they were clever enough not to need language safety, I want language-level protection.

(Did the Python crowd ever fix the race condition in CPickle?[1] They were in denial about this about eight years ago when I reported it. Doing multiple CPickle operations in separate threads can crash CPython. If you search for "CPickle thread crash" you find many reports of hard to reproduce problems in that area.)

[1] [https://bugs.python.org/issue23655](https://bugs.python.org/issue23655)

<comment><USER54> I don't see a denial in that bug report - they're just saying that they don't have an actionable repro, and don't know how to get one.</comment></comment></comment></comment>