I don't want to be a full-fullstack developer - <AUTHOR> https://artur-martsinkovskyi.github.io//2019/i-dont-want-to-be-fullstack/ <comment><USER4> So, it seems like the pendulum is swinging back. I remember companies with more dedicated specialists, and it could be challenging to ship small features due to large coordination efforts.

Further, sometimes the work is unbalanced. In my current company, we recently had a backend-dominant release in a way that the frontend team didn't have as much work. That team rolled up its sleeves and dug in to solve problems, even if they weren't specialized in it. They weren't happy. It wasn't what gave them joy, but it was what was necessary for everyone to release what was needed. Now, we made sure that they had access to backend developers who could pair or guide work, and we knew the work would talk longer. (After all, these were developers who were stronger in the front end!) With our next release, we look to be more balanced, but we're looking at having developers with more backend competencies contribute to the frontend this release.

I think it's too much to ask for developers to be equally brilliant in multiple areas, but I don't think it's too much to ask that people have the willingness to develop minimal proficiencies in multiple layers and the willingness to contribute and learn.

<comment><USER5> I think the broad historical sweep here is sort of along the lines of:

* From the early microcomputer era onwards, applications development focused on getting developers that knew the base platform or operating system(e.g. if you knew "Win32" dev, that was solid in the mid-90's) - and it was one platform per category of application, and for applications that integrated a database you also had platforms like Foxpro, Access, or Hypercard. Specialization beyond that was typically the domain of big-iron computing, which had an older market and talent pool that was used to a certain model and infrastructure of scaling to solve the data processing needs of the era.

* Increased usage of computer networking pushed all development towards a multi-tier setup(e.g. LAMP stack or the multifarious forms of Java and .Net), meaning that more applications needed "front-end" vs "back-end" division, regardless of their needs. We addressed the problem at a local level by gluing together big-iron concepts and microcomputer concepts to get an awkward-yet-servicable jumble of domain competence, with the Web as the dominant frontend. A very small number of Internet companies pushed the boundaries and set the standards on data processing and frontends, and the market followed in their footsteps and used their leftovers.

* Now that we have built out a lot of leverage towards all the possible speciality roles and computing is firmly in the hands of a few giants that can leverage all of that specialization, commoditization is creeping in and pushing smaller development teams back into more consolidated platforms. "The browser is the OS" is effectively true today, except that it's a terrible OS, scarred by numerous wars to control the platform and enable only specific categories of applications.

What developers are moving towards, but are having trouble reaching because of the sheer number of established layers and protocols and required features, is another Hypercard that consolidates concepts into a single consumable, more uniform package, without requiring you to know all the boundaries and sharp edges that exist when going between the JS type system, the SQL engine, the browser engine, serialization protocols, network conditions and hardware status, etc. This is not a project that can be accomplished by lightly papering over the existing systems with framework glue - it requires attention to detail to clean up and simplify each part of the whole. So it takes time.

But at the same time, I think we're also going to get where we want to go, faster than we think. The introduction of, and adoption of Web Assembly, is a major milestone because it raises the level of local processing and hence local platform consolidation, which in turn limits browser-specific APIs to importance in terms of their core I/O functionality, and not one-off standardized features. New platforms can carve out more and more space from that starting point, ultimately resulting in applications that have replaced the browser with a custom native runtime, but still ship WASM binaries.

Simultaneously, native code development is getting better. The bottom of the stack is getting attention after leaning heavily on the traditional C/Unix model for decades and accumulating features without major revision - Rust and systemd are two healthy(if polarizing) examples.

And at that point, the classical Open Web is dead, but it's due to be replaced in turn with a second coming of specialized, decentralized and federated protocols - new takes on Usenet, IRC, FTP, etc. The wheel will keep turning, though all the formats might churn.

<comment><USER4> I think there's truth to that when looking at internal software, but external (B2C) software will continue to live in this division. (Think of hotels.com as an application, for example. There's no world where you can build a hypercard app that meets those needs.)

</comment></comment></comment><comment><USER6> > _As years go by the industry is going deeper and deeper down the rabbit hole > of developer-focused engineering process and developers go on to combine > more and more responsibilities beneath the surface of single cranium._

Why do you think developer salaries are so high? As the advancement and sophistication of open-source and SaaS offerings increasingly empowers individual developers to do more for businesses, so do developers leverage those capabilities to demand higher salaries and become more and more integral, _as individuals_ , to the business process. The natural consequence of this is that companies have increased their expectations across the board because they ultimately get more value out of a highly paid full-stack than paying three moderately smaller salaries to a FEE, BEE and a manager/architect/SME to coordinate their efforts.

<comment><USER7> I disagree with that assessment. Sophisticated open source, IaaS, and SaaS offerings greatly lower the barrier of entry in this industry and ought to have a negative effect on wages as dictated by supply and demand.

Your argument undermines itself by highlighting that a single open-source- equipped person can do the job of 3 grey beards of old. That automation of labor runs counter to rising wages.

As another data point, some of the highest paid engineers in the industry - those manning in the private battlements of the FAANG citadels - <USER2> specialist steeped in closed source arcana. I myself have been such an acolyte for many years.

My own take on the situation is that the distribution of skillets will further take on a bimodal distribution: the specialists and the generalists.

For now both the supply of sophisticated tools and capable practitioners has not kept pace with the demand from modernizing business. When the demand is met and equilibrium reached, I expect salaries to normalize back to what other technical professionals command (e.g. aerospace and civil engineers).

<comment><USER6> > _Sophisticated open source, IaaS, and SaaS offerings greatly lower the > barrier of entry in this industry_

I would question this assumption. In my view, the existence of these tools actually _increases_ the barrier to entry because they represent additional skills that developers are expected to posses in order to be competitive in the job market. This is actually a common complaint among developers whenever a new technology gains viral popularity (e.g. AWS, react, k8s).

> _That automation of labor runs counter to rising wages_

Well of course it does, except for the people who are paid very well to build the automated systems (i.e. programmers). Fortunately for programmers there still isn't enough supply to meet demand, so senior developers on the frontiers of popular technologies can command outsized salaries but still can't do enough work to eliminate the need for their less sophisticated colleagues (yet).

> _specialist steeped in closed source arcana_

Sure, that doesn't really contradict what I'm saying, but I'd also note that whatever closed source project one might be working on is almost certainly benefiting from a gigantic open-source force multiplier in some form or another.

> _When the demand is met and equilibrium reached, I expect salaries to > normalize back to what other technical professionals command (e.g. aerospace > and civil engineers)._

On this we agree. I tell developers all the time that they should enjoy it while it lasts because this definitely won't last forever. I'm pretty bearish on things like AI programmers, but I think open-source and commodity B2B software solutions are rapidly approaching the point where the costs associated with running an engineering department will appear much less imperative.

</comment></comment></comment><comment> jon-wood An early stage startup probably doesn't have enough money to hire specialists, and doesn't have the workflow down to make optimal use of them even they could afford someone in every position. At that scale you need one or two people who can do everything - probably they won't do the best job of everything, but they'll get your company off the ground.

Once a company starts scaling up they'll find that they need someone with a deep knowledge of one particular specialism, such as mobile development, or backend, or maybe infrastructure. They'll pick someone like that up who likely ends up taking ownership of it.

Over time they'll end up with specialists for everything, but that comes with its own set of problems. At this point probably everyone can do a really good job in isolation, but there's someone needed to coordinate the work to make sure people aren't being blocked. That's when the first dedicated project managers start arriving and getting the team moving in one direction. Probably at this point you'll also start seeing product managers, because there's no one around with a unified high level view of what customers need anymore - everyone else is down in the weeds.

At least in my experience scaling a technical team is at least, if not more, complex than scaling the actual product that team is working on. It shouldn't be underestimated, and you should aim to have someone around who's done it before and understands when it's time to stop saying "we should just hire people who can do everything".

<comment><USER8> Totally this. The difference is not "full-stack" vs "specialist" so much as "early/small company employee" and "corporate employee".

In small/early companies, there's just a few people. The same tasks need to be done (someone has to design the database, ensure the SSL certs work, and get that checkbox looking good in Firefox). But there's less people to do it.

"full-stack" in this sense means someone who is prepared to roll up their sleeves and solve whatever problem presents itself. It might not be the best solution, and a specialist can almost certainly do a better job, quicker. But it works for now, and moves the product on to the next step.

Corporate employees can be true specialists, because there's enough work and enough team to allow them to be. But this comes with an additional required skillset: corporate communication. To be an effective member of a large team requires a communication mindset that is completely different from the "roll up your sleeves and get it done" mindset of the small/early organisation.

I'm a small/early organisation guy - I can't stand corporate communication, and love rolling my sleeves up and getting it done, whatever "it" is. I know people who are totally the other way; they just want to focus on crafting amazing UI's, or designing perfect databases, and shudder with horror at having to deal with the "full stack" in all its nightmarish complexity. They're comfortable dealing with lots of meetings and reports in return for being allowed to do their one thing.

</comment></comment><comment><USER9> I've been considering and pondering similar things for my own career. I think there are two things going on.

First off, there are assumptions that full stack developers are 100% amazing at all points in the stack. That's not the case. I consider myself more of an operator this day an age, but I still could take AWS or an empty linux box and build and deploy a java/go backend with a VueJS frontend for something. It won't be pretty, I can promise that. At the same time, that's why I have a great time with the other full stack developer who is much stronger on the frontend/backend side and kinda doesn't want to deal with the infrastructure and deployment.

And from that follows something that has taken a lot of stress from me. If the company is small, it's fine to have a full stack developer deliver something. There will be deficiencies in the stack somewhere, but who cares, there will be a minimally viable product.

Once the company scales however, people can start specializing into the areas they are good at. Why should I struggle too much with a JS frontend if I can make the entire application faster by thinking about the database? Why should the mentioned other dev struggle with one of the many ways to deploy the application if they could spend their time on features?

</comment><comment><USER10> We had this role back in 1997 We called those roles webmasters. It involved everything frontend / backend plus running a server on your bedroom floor that powered a company

I'm fine with all of those roles. I've been able to pick them up along the way and others (report writer use to be a separate role).

The one role I can't master is designer (not frontend developer). It isn't logical and it can't be learned through instructions alone. And the rules change.. what looks great today looked alien yesterday and boring tomorrow.

<comment><USER11> Have you spent any time trying to learn design? I agree there is some part that is one's own artistic style, but much of design can be viewed and learned systematically - ratios, patterns, color theory, etc

<comment><USER12> Indeed, I'm not really a designer. But I spent about a year reading Smashing Magazine ([https://www.smashingmagazine.com/](https://www.smashingmagazine.com/)) regularly a few years ago, and I have the basics down now.

Turns out it's a lot like good code: keep everything consistent (padding, colours, etc) and clear, and simple and it'll ussually look decent.

</comment></comment></comment><comment><USER13> > you don't expect the dentist to cure your heart and neurosurgeon to fix your > hemorrhoids.

That's your problem right there. Your frontend is not as different from your backend as dentristy is from neurosurgery. If you think it is, you might lack some understanding of how things work.

Tbh., whenever someone hails the specialization and how their particular field is so special, I hear them saying "I really do not want to be bothered with all these nasty details". And that's fine. But it's not something to be proud of. Personally, I would love to have a better understanding of how user interfaces or database work internally. I think the understanding would only make me better.

<comment><USER8> > That's your problem right there. Your frontend is not as different from your > backend as dentristy is from neurosurgery.

I'm not a neurosurgeon, or a dentist, but this doesn't strike me as true. Front-end dev uses totally different tools and languages, and a different set of design principles, than back-end dev. It didn't use to be this way, but it definitely is now. There's almost no cross-over in skills now, especially with Elm-derived front-end frameworks taking over.

<comment><USER13> > totally different tools and languages

do they, though? What's distinguishing JavaScript from, say, a poorly implemented lisp? What's the main difference between typescript and a poorly implemented ML? Syntax? Come on! There are maybe a handful of really different programming languages designs. And only three of them are really widespread.

> There's almost no cross-over in skills now, especially with Elm-derived > front-end frameworks taking over.

If you are talking about Elm the language then it is very clearly influenced by Haskell. It is literally rooted in FRP. So to understand elm you need to know something about functional programming and type systems. Then you read the docs and you are in the game after a few days.

<comment><USER8> yeah, I bet if you talked to the average front-end dev and told them they spend all their time writing poorly-implemented lisp, they've have a few choice words to say about it ;)

From the CS point of view, sure, there are only a half-dozen languages. From the IT point of view, having a few years of experience dealing with the exact details of the "poor implementation of lisp" makes a massive difference in productivity and effectiveness.

There are also widely separate concerns between front-end and back-end. UI patterns is a whole discipline in itself. Deployment and CI, AWS vs DO, not to mention containers and swarms, is just a subset of one aspect of "dev ops" these days. There's also the entire subject of database design, of securing HTTP/S/2 traffic, data encryption schemes, logging strategies. It's endless, on both sides. And none of the skills are transferable. Knowing AWS doesn't help you implement a UI, and knowing React does nothing to help you design a database.

I dare you to try implementing a complex UI in React after learning FP, reading the docs and a "few days" ;)

But to get back to the analogy... I can easily see a neurosurgeon saying "teeth, they're just specialised bones! Give me a few days to brush up on the basics, and I'll have that wisdom tooth out in a jiffy" in the same manner.

</comment></comment></comment></comment><comment><USER12> > Fullstack is interesting because is seems to be almost unique to the > software engineering field. Other fields mostly have more division of > labour, you don't expect the dentist to cure your heart and neurosurgeon to > fix your hemorrhoids.

What about GPs?

Just like the medical field, software needs both specialists (to go really deep down the rabbit holes), and generalists (to tie everything together).

Personally I love being a generalist. Sounds like the OP just isn't in quite the role for them.

<comment><USER14> Architectural coherence is such an important part of software design. I agree with your point completely—you need specialists for deep, specific problems, but you also need people with a view of the entire system.

<comment><USER15> Great point, and I think it relates to the market need for a "full-stack developer", an all-around generalist who understands (more or less) the entire stack and areas of endeavor.

It also made me think how, typically, the problem with "design by committee" is that it's often a mere collection of specialists, without the necessary generalists (those with an understanding of architectural coherence, system- level thinking) with the power to tie it all together.

I think the reason why many great software projects are created by an individual or a small team, is that coherence and consistent vision across the system.

<comment><USER14> This is actually discussed very intelligently in "The Mythical Man-Month." The author explains that large software projects have an inherent tension between coherence and efficiency. A small team maintains coherence, but cannot get the required amount of work done in a reasonable amount of time; a large team works faster at the expense of coherence. Balancing those two aspects effectively is what makes large projects successful.

</comment></comment></comment></comment><comment><USER16> Allow me the exaggeration but I think that if everybody would be full stack, frameworks would be much simpler, there is a lot of gratuite complexity that grows because people have the time to dedicated just to one side.

<comment><USER17> I stumbled into the realization that teams should be full stack instead of horizontally sliced. Once I figured out how to map out data dependencies end to end as part of our planning process we made huge gains in productivity and similar reductions in stress.

</comment></comment><comment><USER18> > the rabbit hole of developer-focused engineering process and developers go > on to combine more and more responsibilities beneath the surface of single > cranium.

(1) There's a strong reason for this desire. Software systems are very interdependent.

We you can see from front to back and side to side, and you can recoginze the potential for improvement or optimization.

(2) "Full-stack software developer" is more specialized then you might think.

As a "full stack" web developer, I can count on one hand the number of times I've looked at a browser's source code. Same for databases. I understand the basics of DNS, IP, TCP, UDP, BGP, but not the details. And my knowledge of common ISAs is laughable. And I have essentially no knowledge of hardware: physical CPUs/GPUs, displays, fiber optics, etc.

</comment><comment><USER19> If you are doing web dev, it is normal to require a wide set of skills (but not very deep). You are not a researcher or PHD student. Also, you are not working on a pacemaker or anything with life/death consequences, so cutting some corners like merging UI/UX/QA can only be profitable. Communication is faster within a single brain than within 'n' amount of people with slightly different jobs.

</comment><comment><USER20> Full stack engineers wear multiple hats and they have a strong incentive for picking just the right (sufficient?) tools for the job. The upside for full stack engineers are that things aren't overengineered.

<comment><USER21> I think from the client point of view the advantage of having "full-stack" developers is that it saves you some trouble of team management. With more specialized team you need some fronted developers, some backend developers and an architect to ensure that the pieces fit. And you have some inneficiencies, when front-end peoples are swamped with work, and backend guys are sitting idle, or vice versa. In a team composed solely of full-stack devs people are more interchangeable.

</comment></comment><comment><USER22> If you're a solo freelancer full-stack is exactly what you want to be. Being in charge of the whole development process is a big win. I'm not sure full- stack needs to include being an artistic graphic designer, though. Usually it's enough to be able to wield Photoshop well enough to produce business- grade (read boring) graphics. Farm it out to art school students if you need anything more exotic. They'll be glad of the extra income to supplement their grant.

</comment><comment><USER23> For me, Fullstack is only enjoyable when using JS or TypeScript both in backend and frontend

<comment><USER17> I thought I'd feel that way but it turns out I need a break from Javascript sometimes. Doing a backend story once in a while got me a little break from that before Node. Now I've only got the build system and docker as relief valves and it's not enough long term.

</comment></comment><comment><USER24> I've worked with very few developers that I could even begin to call full- stack. They either segment themselves as front-end or back-end only, and can't cross the divide. I don't much like it, because that interface between the two is usually terrible as a result, with pieces that don't match, APIs that don't even work, and generally a huge amount of work to integrate by somebody that actually understands both pieces, that rivals rewriting it completely.

Owning an entire vertical slice is so much easier, and produces a better quality product.

<comment><USER25> most fullstack developers i know have a strong expertise into something and ok knowledge (as in, they can write features, review PRs, fix bugs -- but they are not super experts) in the other areas. which makes sense, it's quite hard to be amazing at everything.

</comment></comment><comment><USER26> Try to make a company. You have to be full-full-fullstack.

<comment><USER27> Ugh, so true. The hard part is building the non-tech part of the company so you can hopefully do some coding ever again.

<comment><USER26> Haha that rings so true.

</comment></comment></comment><comment><USER28> _More and more agencies are looking for people who can do both frontend and backend, also participating in the business requirement development, writing unit and integration tests, being everywhere and doing everything_

I like working with the users directly to make sure I'm writing what they need. If I don't, I encounter too many instances of the "XY Problem".

Who should be doing the integration and unit tests if not the developer? Why wouldn't the developer be doing his own QA before he passes it off as "done"?

I work for mostly small companies so I can do the full stack - except for designing the interface. I can code the front end, backend in three or four modern languages well, know how to design and manage databases - <USER3> (OLAP/OLTP) and I know my way around infrastructure at least with AWS. I can do passable Devops CI/CD pipelines. But, this is from a long career at working at mostly small companies.

</comment><comment><USER29> In the context of a large web application what many people describe as _back end_ is hardly such. Typically that stuff is middleware. The actual back end would be things like payment processing, database access, internal services, and so forth. The code sitting on a service that issues server calls and into the business logic that builds anything client facing is middleware. I call that stuff middleware because at a large enough company they would not let anything on a webserver go remotely close to anything storing data for security reasons.

That being said _fullstack_ doesn't actually mean the entire stack as the name would suggest. It really means the front-end plus the middleware, or both ends of HTTP. For developers experienced enough to write on both sides of HTTP it makes sense to tidy that up into a single position to lower labor costs.

</comment><comment><USER30> I do have to agree with this article insofar as to what companies are expecting from potential candidates way more than is feasible that's unless the BE and FE use the same language. But as a technical founder you just do not have a choice but to wear all hats.

</comment><comment><USER31> I disagree with the argument that you can't have a high level of skill in multiple parts of the stack without sacrificing a personal life. But I do tend to believe you can't operate at that skill level for each discipline at the same time.

This is based on my own personal experience of course, but in any given job I tend to be full-stack, but with a bias towards a certain area of the stack. My contribution to the other areas of the stack is in more of an advisory/consultant role.

On the other hand, I know full-stack devs who are far better at context- switching than I am. Subjectively I don't think their output is at the same quality as mine, but there is definite value in what they're able to do.

</comment><comment><USER32> I have the (admittedly subjective) sensation that I read a similar blog article just about every week. As the author aknowledges the various opposing points, we could, perhaps, sensibly surmise that it's contextually dependent.

</comment><comment><USER33> Agree with all your points, but in my experience, early-stage startups require full-stack competency due to rapidly changing priorities and a small team.

<comment><USER17> Generally they don't require the entire team to be full stack. But being able to flip priorities from 2:1 to 1:2 front end vs backend is often necessary to maintain velocity between milestones. Prettying up the interface is a lot of work. So is scaling up your backend for the new customers your facelift just got you.

In a small place having a third of your team being full stack takes a lot of stress off the planning people.

<comment><USER33> Agree 100% on that, I didn't mean to imply startups want a team full of generalists. But engineer #1 likely has to be full-stack. As you say, once you have 3+ engineers, a mix of full-stack and domain experts can ease planning challenges.

</comment></comment></comment><comment><USER34> From my experience, as a backend engineer develops more frontend/javascript skills, the solutions tend to become more intertwined. We now have some parts of our app where you couldn't change the tiniest detail in a view method, without thinking about how that's going to break client side. I'm not sure that's moving in the right direction.

</comment><comment><USER35> you need a team for larger applications, however the members of the team should have overlapping skills. so you don't always need to do everything all the time. it is fine to be a specialist in some areas. actually, a team needs specialists, to solve difficult blocking problems.

However, when you got someone with excellent frontend skills, they still should know how the backend works since they interact with it. they should also be able to pick up changes there. since amount of work is not always balanced. further, doing work in a particular area outside of the main expertise raises the understanding of specifics there as well increses the overview of the complete system.

in the end, being full-stack dev is a strategy to prevent local optimization and comm-overhead and emphasize global optimization to develop a good application for the customer.

</comment><comment><USER36> I totally understand where the author is coming from. Though a full stack dev like an ER doctor.

</comment><comment><USER37> So is a full stack programmer someone who can write javascript for the server AND the browser?</comment>


Java Cancels Fee for new Garbage Collector - <AUTHOR>

Some of you will recall that the new G1 garbage collector introduced by Oracle/Sun required a paid license. It appears they have changed their mind:<p>http://java.sun.com/javase/6/webnotes/6u14.html <comment><USER2> "Usage in production settings without a Java SE for Business support contract is not recommended."

Sounds like they want the best of both worlds.. crowd sourced testing and a license fee.</comment>


My opinion on a recruiting tactic - <AUTHOR> http://pastebin.com/pMDEfiU5

<comment><USER2> Seems to me you made a huge leap from "lot of team interaction" to "I have to talk all the time", and it was completely reasonable for the recruiter to try and address your concern given it was potentially based on as a misconception on your part.

<comment><USER3> My thoughts exactly. Also, recruiters don't care if they're pulling in desperate engineers. It's all about the commission. He sent that same email out to as many other people he could pull out of his database, maybe a few hundred.</comment></comment>


Google to Collect Data to Define Healthy Human - <AUTHOR> http://online.wsj.com/articles/google-to-collect-data-to-define-healthy-human-1406246214 <comment><USER2> There are a few flaws in the thinking here: One, that we can define a "healthy human" or that any humans can be found that are operating at full health. Two, that there is a single set of traits that defines a healthy human, or that it could be distilled via sampling and synthesizing data about many humans. Three, that any such indicators or traits they discover will not change over time.

There is undoubtedly the need for tremendous amounts of research into human physiology and health, but there's a very naive hubris that runs through all these grand analysis projects that promise to solve all human health woes. Our bodies are the most complex systems that we know of in the entire universe. The idea that we are anywhere close to understanding how they should optimally work is just completely daft.

Just look back at the promises made by the Human Genome Project in the early 90s. Yes, we've learned a lot since then, but mostly we've learned that the relationship between our bodies and our genes is far far more complicated than we imagined 25 years ago.

</comment><comment><USER3> The limiting factor right now isn't the lack of clever algorithms or computational power, but the lack of data that covers enough people over enough time with enough depth and quality. Also, more of former can't make up for a lack of the latter, even if it's sexier, especially for a company like Google.

They should consider partnering with these guys: [http://www.nature.com/news/medicine-gets-up-close-and- person...](http://www.nature.com/news/medicine-gets-up-close-and- personal-1.14702..).

<comment><USER4> An alternative limiting factor could be the lack of great, low cost ,measurement tools. But there are some signs we're getting there, like this[1] chip based platform that can test for 170,000 proteins on a single test, cheaply.

Maybe the thing behind this google move is an understanding that it's possible, in some time feasible for google's projects, to commercialize such testing platforms, and they want in at the opportunities that will result ?

[1][http://www.laserfocusworld.com/articles/2014/03/led-based- la...](http://www.laserfocusworld.com/articles/2014/03/led-based-lab-on-a- chip-device-screens-for-170-000-molecules-in-blood.html)

</comment></comment><comment><USER5> If they can truly protect the anonymity of donator data, I wouldn't mind to be part of it.

Heck, when I donate my blood I am already giving a lot of information to the blood center and they know my blood type and can tell if I have certain diseases of not. When I volunteer to do bone marrow match test, I don't know how the firm handles my data. I supposed they can protect my data.

I am not worried about Google knowing more about me or humans. I am more worried about how safe my records are with my clinics and hospitals. See [1]

Lastly, personal question: how do you get into Google X?

[1]: [http://www.scmagazine.com/rhode-island-hospital-to- pay-150k-...](http://www.scmagazine.com/rhode-island-hospital-to-pay-150k-for- past-data-breach/article/362725/)

<comment><USER6> I would be more worried that the results of these studies are not made freely available to everybody. I prefer having research funded by public money without seeking a profit.

<comment><USER5> What do you mean they are funded by public money? I thought Google is paying a clinic to get samples and pay researchers to work on the project, but the researchers have to get approval from the review board of their respective institution. The review board is funded by public money (more or less) I guess, but other than that, what else?

<comment><USER6> As I understand it, the researcher works for Google, so I suppose that his results belong to Google. Is this not the case?

<comment><USER5> > I prefer having research funded by public money without seeking a profit.

Now that I read what you wrote twice I might interpret your original sentence wrong. I thought you were implying the work they doing with Google is using public money ("I prefer research funded by public money [done by these researchers to be non-profit].")

You meant you prefer to have public institutions to carry out the research.

Well, in that case, it's only temporary. There are public and private AIDS research, but in the end, the public research is used to seek for profit. Say Google, IBM, Microsoft donates 10B to make this a non-profit research, the end product (the algorithms, etc) will be used by private companies anyway. So I don't see how public vs private really matter if the data and results are going to be publicly known by private company later on for profit.

But if you are going for "pure knowledge", sure, public research would be ideal :D

</comment></comment></comment></comment></comment><comment><USER7> This reminds me of something Larry Page said at TED this year:

 _I say, wouldn 't it be amazing if everyone's medical records were available anonymously to research doctors? And when someone accesses your medical record, a research doctor, they could see, you could see which doctor accessed it and why, and you could maybe learn about what conditions you have. I think if we just did that, we'd save 100,000 lives this year.

So I guess I'm just very worried that with Internet privacy, we're doing the same thing we're doing with medical records, is we're throwing out the baby with the bathwater, and we're not really thinking about the tremendous good that can come from people sharing information with the right people in the right ways._

Source: [https://www.youtube.com/watch?v=mArrNRWQEso&t=839](https://www.youtube.com/watch?v=mArrNRWQEso&t=839) at 14:00.

<comment><USER8> I agree with Larry, at the same time google is one of the last companies on the planet that I would trust with that data.

Much of this internet privacy backlash is aimed specifically at Google and Facebook (and of course the NSA, but let's assume that they don't have any problems getting to your medical data anyway).

<comment><USER9> Why is that? The data are anonymized.

But then even if they weren't anonymized, I think Google would be one of the company I would trust the most for that. They know what they're doing in terms of security and of all the companies that know a lot about me, they're the one who consistently delivered great value from the data they have. I'm thinking of things like search, Google Now and the maps interface for my location history. Plus I'm happy that the monetization of my data serves to fund great projects like this one. It didn't have to be so...

<comment><USER10> Even anonimized data that seems very generic and nonspecific, when corolated with other data points paints a very precise and specific picture of an individual, including enough to accurately identify them. This is Google's entire business model.

Health data is very far from this idealized anonimization-friendly case. It is some of the most specific data avalible about you, and it can easily be abused to disadvantage you in ways you can do nothing about (insurance, job prospects, social standing, even as far as getting your life threatened by people who disagree with things like sexuality and abortion)

Im sure Google appreciates your faith in them. But you should carefully consider the consequnces. Once the information is out there, there is no getting it back.

<comment><USER9> You're making a good point with the "there is no getting back". I kind of trust Google based on their track record but you can never be sure about the future[1]. But all in all what matters is not whether I can trust them perfectly, it's that to me the expected benefits are concrete and vastly outweigh the theoretical risks. I guess I'm in a privileged position such that I wouldn't even mind having most of these data made public to help with this kind of research[2]. To me it is more about progressivism vs. conservatism than about faith in a particular company (though I do worry that one company might concentrate too much power).

[1] Although Google's direction is arguably more stable than is usual for publicly traded companies, given the particular share structure designed to keep control in the hands of the founders.

[2] Mostly, being in generally good health and living in a country where basic health insurance is guaranteed and good enough, with premiums that don't depend on your health.

</comment></comment></comment></comment></comment><comment><USER11> I'm excited to know which diets, exercises and lifestyle define a healthy human, which I'm hoping this information will give me (assuming the information will be released).

<comment><USER12> What if there is no such universal thing? What if our DNAs, tRNAs, upbringing etc. generate a very wide set of health requirements that aren't in sync between all humans but instead compete with each other? Some people eat bacon and trans fat every day and live up to 100 years. Some people die in their 30s on the same diet etc.

Are we going to end up with an average that doesn't fit anyone?

<comment><USER10> A sort of gmail interface redesign problem, but people's lives are on the line.

Google has shown itself to be driven by metrics to almost the sole exclusion of anything else, metrics often dont tell you what you think they do.

</comment></comment></comment><comment><USER13> This is very exciting at one level. We need a project like this to accomplish a "Species" level map of our biology.

Knowing a little bit about how data moves thru the Labs & clinics systems however, and the widespread tentacles of bad actors like the NSA, this could be too juicy a prize to ignore. What is to prevent the Feds (for instance) from knocking on their doors with an NSL for the data based on some trumped up link?

</comment><comment><USER14> anyone remember Gattaca ? well we could end up with data based classification version of that here !

<comment><USER15> A more mundane concern is insurance and financial (dis)incentives for behavior change, [http://www.salon.com/2014/05/30/in_the_future_insurance_comp...](http://www.salon.com/2014/05/30/in_the_future_insurance_companies_will_make_sure_that_you_exercise/)

"23andMe Is Terrifying, But Not for the Reasons the FDA Thinks", [https://news.ycombinator.com/item?id=6811167](https://news.ycombinator.com/item?id=6811167)

"23andme has suspended health-related genetic tests", [https://news.ycombinator.com/item?id=6859732](https://news.ycombinator.com/item?id=6859732)

"A problem with much statistical analysis is ignoring the fact that humans, umm, react to things around them. (Social science jargon for this is reflexivity). I know this seems so simple, but it's amazing how much predictive analytics don't factor this in.", [https://medium.com/message/learning-from- natesilver538s-omg-...](https://medium.com/message/learning-from- natesilver538s-omg-wrong-bra-vs-ger-prediction-9d47fa0611e)

<comment><USER14> That last link on the shortcomings of most predictions based on statistical analysis was a great read. Thanks for sharing.

<comment><USER16> Are humans deterministic machines, or do they impose their own freewill on to the environment? Predictions based on statistical analysis probably can't account for freewill.

<comment><USER17> Statistics can account for free will just as well as they account for other complex factors, which is poorly, with no ability to say what will happen in any particular case. There's no need to get metaphysical.</comment></comment></comment></comment></comment>


"You filthy-minded little pervert" error when registering obscene .to domains - <AUTHOR> https://www.tonic.to/ <comment><USER2> That was George Tupou V's doing. When he was crown prince of Tonga, he set up the .to registry as a business operation. The original server was in the consulate in San Francisco. When he became king, he had to sell off the business. I knew some of the people involved with ".to", which was the first of the monetized ccTLDs.

So, "The Kingdom of Tonga admonishes you" is not a joke. That message originally came from someone entitled to issue it. Topou V died in 2012.

</comment><comment><USER3> To save you time, when trying pussy.to:

> You filthy-minded little pervert!

> The Kingdom of Tonga admonishes you. Now go back and think of another name > that you wouldn't be embarrassed to say to your mother.

However:

> Congratulations!

> Your name penis.to is available.

<comment><USER4> vagina.to is available, so it seems that medical/technical/'proper' terms are not blocked, merely slang.

Edit: I love the web page design, unironically. Makes it feel like there's a cgi-bin directory full of Perl scripts in the background.

<comment><USER5> Interestingly, certain non-medical names for the other organ give:

 _Error

This word is unacceptable as a domain name._

</comment></comment></comment><comment><USER6> I recognize this may be a really unpopular opinion but lately I've been feeling like the lack of values and personality in ubiquitous apps like Instagram, Facebook, may be short sighted.

don't get me wrong. i make web software- I get it. just build an interface to the data. but I also think a little personality and good will from these apps could help make the world a better place (Facebook does this in some respects, like celebrating birthdays and friendship anniversaries with fun videos).

that all said... this kind of subjective censorship is totally not what I had in mind... perhaps it's a fine line.

aside (but perhaps more relevant): I'm curious as to who arbitrates this blacklist, and who is responsible for the funny messaging it responds with. ([https://en.m.wikipedia.org/wiki/Tonga](https://en.m.wikipedia.org/wiki/Tonga))

<comment><USER7> I've heard the "personality" that a lot of major sites use referred to as "the new sincerity," because apparently, somehow, "sincere" meant endlessly chipper and painfully patronizing.

<comment><USER8> Facebook's "on this day" feature starts its blurb with "We care about you", and that just makes me uncomfortable.

<comment><USER9> It's the same way every farmer cares for their cattle.

<comment><USER10> Not quite so. Farmers don't have to reassure their cows that they care about them. Plus they _do_ care, even if for completely selfish reasons.

<comment><USER9> Sure, you have to keep the herd together. Farmers do that other ways, but the outcome is the same. Facebook does care, and for the same selfish reasons: they're an eyeball farmer.

</comment></comment></comment></comment></comment></comment><comment><USER11> The joke is on them. I'm not a little pervert. I'm a huge pervert.

</comment><comment><USER12> First registry I've seen that lets you do a 100 year registration.

<comment><USER13> Yeah, that's pretty amazing if it's something they will stick to. Most I've seen is 10 years, which can be a bit short sited for something like a personal blog, an archive or permanent resource of some type.

</comment></comment><comment><USER14> I doubt I will ever get to write an error message as great as "The Kingdom of Tonga admonishes you."

</comment><comment><USER15> It's not a fan of scunthorpe.to yet somehow analfisting.to is just fine :-D

</comment><comment><AUTHOR> For what it's worth, our team - the Domain Research Group - specializes in this kind of weirdness.

Couldn't resist sharing this... (discovered when they decided to add support for Emoji Domains)

Here's our report on unusual characters in the dotcom world: [https://medium.com/@Emoji_Domains/all-the-dotcom-emoji- domai...](https://medium.com/@Emoji_Domains/all-the-dotcom-emoji- domains-5ad2f638b090)

</comment><comment><USER16> I found another error in addition to the pervert error... 'This name contains an offensive substring'.

Apparently that's for moderate level swear words.

</comment><comment><USER17> Looks to probably just be a banned word list as alternate/phonetic spellings get through their filter. phuck.to, kok.to, etc.

</comment><comment><USER18> Dang, dori.to is taken.

<comment><USER19> Dang! burri.to is as well!

<comment><USER20> Not stilet.to though.

<comment><USER21> To save everyone else time:

$ grep to$ /usr/share/dict/american-english | column -c 80

Akihito Maputo Shinto ditto palmetto

Alberto Margarito Soto falsetto photo

Ariosto Minamoto Soweto ghetto pimento

Barquisimeto Miskito Squanto graffito pimiento

Benito Modesto Suharto grotto pinto

Bhutto Monsanto Tintoretto gusto pizzicato

Callisto Mutsuhito Tito hereto potato

Canaletto Norberto Tonto hitherto presto

Cato Otto Toronto incognito pronto

Erato Pareto Toto into quarto

Ernesto Plato Tupungato legato staccato

Esperanto Pluto Vito libretto stiletto

Frito Pôrto alto lotto telephoto

Gilberto Quito antipasto magneto thereto

Giotto Rigoberto auto manifesto to

Heriberto Rigoletto bonito memento tomato

Hirohito Risorgimento burrito mosquito unto

Humberto Roberto canto motto veto

Ito Sacramento concerto mulatto vibrato

Kyoto Sarto contralto onto

</comment></comment></comment></comment><comment><USER22> I'm disappointed by the fact that this error comes with a response code 200. I was expecting either 69 or 666 or something of the kind! If your gonna be wonky, why not go all out? ;)

<comment><USER23> I believe 406 Not Acceptable would be the proper response.

While typically I would discourage using that response code unless the error is with the Accepts header. I would make an exception in this case

Edit: Whoever downvoted me needs to get a life. I'm playing along with the joke not trying to correct amarant.

<comment><USER24> Who made you the boss of http codes

<comment><USER23> Chill dude. I was playing along with the joke. Also, a boss would say "You must use this code!" not politely discourage it... also W3C

</comment></comment></comment></comment><comment><USER25> > Congratulations!

> rape.to is available!

I guess you're not a pervert if you're willing to engage in acts of violence and ignore consent :/

<comment><USER26> This is the first meaning of "rape" that I ever learned:

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

<comment><USER25> This is the first meaning of "pussy" that I ever learned:

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


Migrate Everything from Linux to BSD - <AUTHOR> https://www.unixsheikh.com/articles/why-you-should-migrate-everything-from-linux-to-bsd.html <comment><USER2> Uhm... I don't follow.

Sounds like a lot of yada yada yada... corporations are evil... yada yada... Google is evil... yada yada... Mozilla is evil... yada yada... ChromeOS... And on and on.

And it seems that when corporations take BSD and build their own distro that's cool - somehow, because BSD is "developed by open source enthusiasts", but when the same happens with Linux it is somehow hijacked.

Similarly when corporations contribute to BSD that somehow leads to different results compared to contributing to Linux.

Perhaps the author hasn't heard of Debian?

And then the pointless detour into Mozilla's Firefox. Perhaps BSD has a magic browser that's not Firefox (or Chrome, though I am not at all a fan of Chrome)?

For the record I have used both BSD (FreeBSD specifically) and Linux (many distributions over the years, currently I like Fedora). Both have their advantages and disadvantages.

I do agree with some of the Author's points, actually, but that article is just sensationalist and loses a lot of weight because of that.

<comment><USER3> > FreeBSD does not come with a pre-installed web browser. Instead, the www > category of the Ports Collection contains many browsers which can be > installed as a package or compiled from the Ports Collection. [1]

BSD's claim to being a complete system could be strengthened. The idea of steering clear of BigBrother corporations is a good one.

I take the eclectic view that the BSD and FSF ecosystems are together worth more than either separately.

[1] [https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/d...](https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/desktop- browsers.html)

</comment></comment><comment> m-p-3 > systemd does provide improvements to Linux, but the main problem with > systemd is that its continued development is motivated by a company's > economic interests and not the Open Source community interests

Is there any direct event to back this affirmation? I get that corporations have their own agenda, but is there any changes that systemd received that was directly influenced by a corporation and led to a behavior the community generally regarded as bad?

</comment><comment><USER4> So, tell me again, in practical terms, why I shouldn't install that Debian instance? What bad things are going to happen, exactly, that BSD will avoid?

</comment><comment><USER5> The to-and-fro can be seen continued:

* [https://fediverse.blog/~/AllGoodThings/should-you-migrate-fr...](https://fediverse.blog/~/AllGoodThings/should-you-migrate-from-linux-to-bsd-it-depends)

* [https://unixsheikh.com/articles/why-you-should-migrate-every...](https://unixsheikh.com/articles/why-you-should-migrate-everything-from-linux-to-bsd-part-2.html)

</comment><comment><USER6> What a breathless re-litigation of ancient history.</comment>


Ask HN: How Effective is YC? (For Research Project) - <AUTHOR>

I am writing a research paper answering the question: "of companies that have participated in the Y-Combinator process, what has made some companies jump into a high level of success, while others have just remained at a mediocre success level?  Moreover, what defines a high level of success within the startup industry?"  I am hoping to interview as many founders as will let me, as well as stir some discussion about this question on HN itself. <comment><USER2> YC's big offerings are advice, investor connections, and press attention. My guess is that the outcome of YC companies can be summarized as something like:

        product execution * market opportunity * utilization of YC offerings

Dropbox and Airbnb are A+, A+, A+. Everyone else is some lower grade in at least one area.

<comment><AUTHOR> Thanks, You mention these three "categories" that I could possibly grade companies on. That sounds rather interesting. How would you suggest I get data or a system to grade these?

Also, do you really think that Dropbox and Airbnb are the only A+ companies? dont you think that companies not worth a billion dolars can still have been successfull in all categories and maybe just didnt have as large of a market to tap into?

<comment><USER2> I actually meant Airbnb/Dropbox were A+ on Product/Market/YC utilization not the three things YC does for you.

As for how to create interesting research maybe you could setup a simple survey and let HN users grade YC startups in some way like this. I bet the results would be at least interesting.</comment></comment></comment>


Unraveling Why Some Mammals Kill Off Infants - <AUTHOR> http://www.nytimes.com/2014/11/13/science/unraveling-why-some-mammals-kill-off-infants.html?ref=science

<comment><USER2> I am trying to figure the immediate advantage infanticide provides. I had a few ideas but they failed briefly into cross-examination. The closest I have is allowing the new head male to instantly have children without the mothers attention being spread too thin.

I dislike this ignorance, will you help me into the light?

<comment><USER3> In some mammals like the lions, if a feeding mother lost her baby, she will start ovulating immediately. This allows for the new male to have children without waiting for the existing kids to be weaned which can be as long as a couple of years.</comment></comment>


South up Australia-centered world map - <AUTHOR> http://www.odtmaps.com/detail.asp?product_id=HDP-SU-11x17 <comment><USER2> I love this projection (either side of the map). While I've known since childhood about the size distortion of the Mercator projection (one need simply look at a globe), I never saw any of the size-preserving projections until a West Wing episode ("Somebody's Going to Emergency, Somebody's Going to Jail") featured the Peters projection. The Hobo Dyer projection shown here is even cooler.</comment>


Ask HN: What services and technologies do you use to build web app? - <AUTHOR> <comment><USER3> Clojure (Luminus) on the backend, ClojureScript / Reagent / Re-Frame on the front-end.

</comment><comment><USER4> Backend: Rails + MySQL + Sidekiq Frontend: React + Bulma Cloud: Cloud66 + Digital Ocean

</comment><comment><USER5> Laravel Php Mysql Redis Bitbucket Forge VS Code

"Seasoned" tech but works like charm

</comment><comment><USER6> Frontend: Vue Webpack CircleCI S3 Cloudfront (for EV SSL) or Cloudflare (for easy SSL)

Backend: Express, Node, Heroku Heroku CI

DB: Mongo Redis Both on Compose

Other Services Include: Stripe Twilio

</comment><comment><USER7> related: [https://news.ycombinator.com/item?id=17217210](https://news.ycombinator.com/item?id=17217210)

</comment><comment><USER8> For the backend: node.js + express

For the frontend: riot.js, pug, rollup

Databases (polyglot persistence): Couchdb, Postgresql and Elasticsearch

Queue: rabbitmq

</comment><comment><USER9> build: Modelio.org and IntelliJ Ultimate linked to bitbucket's git repository, with BDD on Cucumber and Selenide. Springboot ( java8, groovy or kotlin ) + queryDSL + Postgresql + angular.

host: private server4you centOS vps, keep running with monit and nginx as load-balancer.

</comment><comment><USER10> Vue.js, node, Mongo (maybe firebase if want to focus on frontend UI design)

</comment><comment><USER11> Backend: Python Tornado + Redis + MongoDb

Frontend: AngularjS + Bootstrap

Cloud: AWS SES + Cloudfront + S3

</comment><comment><USER12> React, Redux ASP.NET Core SQL Server AWS (EB, Cloudfront, S3) Redis

</comment><comment><USER13> Android (Java) with Firebase and Cloud functions

</comment><comment><USER14> Frontend - <USER2>

Backend - Google Firebase

</comment><comment><USER15> Ruby On Rails - still my fav

</comment><comment><USER16> The main ones:

\- aws (EB for backend, S3 for frontend)

\- node.js

\- mysql

\- graphql

\- create-react-app + redux

\- flow

</comment><comment><USER17> PHP + everything</comment>


Make YouTube better: preview ratings extension - <AUTHOR> http://youtu.be/MQ0obzYBEcs

<comment><USER2> Just a reminder: you shouldn't download extensions from non-official sources.

Here's one place to install it: [https://chrome.google.com/webstore/detail/cgbhdenfmgbagncdmg...](https://chrome.google.com/webstore/detail/cgbhdenfmgbagncdmgbholejjpmmiank?hl=en- US)

<comment><AUTHOR> This links to someone else's extension with similar functionality.

Here is the real link [https://chrome.google.com/webstore/detail/olohkebleofongajeo...](https://chrome.google.com/webstore/detail/olohkebleofongajeodnhideeiapohgi)

<comment><USER3> I can verify that snitzr's link is the extension from the video. It is also from an "official source", the Chrome store

</comment></comment></comment><comment><USER4> Neat! Thanks for that.

Edit: I wish that would work in Youtube's video search, too.

</comment><comment><USER5> I wish it would work with the cosmic panda interface.

<comment><USER6> I think the new youtube design that's still being rolled out looks better than cosmic panda, and this extension works with it.

If you want to try it, set the following cookie (and disable cosmic panda obviously):

        document.cookie="VISITOR_INFO1_LIVE=ST1Ti53r4fU";

(From: [http://www.redmondpie.com/heres-how-to-enable-the-new- youtub...](http://www.redmondpie.com/heres-how-to-enable-the-new-youtube- design-right-now))

<comment><USER7> I thought Cosmic Panda was supposed to be the future of the YouTube-interface? If not, what is it?

</comment></comment></comment><comment><USER8> I wish this was a greasemonkey script.</comment>


Ask HN: How far in advance should I look for a job in the SF Bay Area? - <AUTHOR>

I'm moving halfway across the world to the San Francisco area on March 13th. Very excited.
I will be hoping to start work as quickly as possible, but realistically I can hang in there for a few months without one if need be.  A natural progression for me would be to look in either the User Research or Product Management fields. Preferably for a startup.
Question is, when do I start approaching companies? It's over three months away, so I don't want to be forgotten about after making my initial approach, but I also don't want to leave it too late.  It's really hard to judge the state of the job market without being there (mixed messages), which further confuses the process.
Any advice would be awesome. <comment><USER2> I can speak from my experience, coming to SF from Europe and finding a design job at a corporation: As long as you are not here, or about to come here, you are exponentially less interesting to companies. If they like your email, resume, portfolio, whatever, they want to invite you, talk to you, see whether you are a cool person. And they want to do it fast. This must especially be true to small companies. Also: You will be able to make so many new PERSONAL connections here, which will make the job search much easier. It's not unlikely to fire off 100 emails to every potential employer and not get much back. But meet one person that you get along with well on a personal level, and you might get your interview right there. Everybody here knows someone who knows someone who wants to hire somebody like you.

(if you need someone to sponsor a visa though, it's a completely different story)

Good luck!

<comment><AUTHOR> Yeah I had thought about that fact - I wouldn't want to get into a lesser position by applying for a job remotely than what I could achieve applying in person. I think I will follow some of the other advice mentioned here and do a sort of email/Skype blitz in the 3-4 week period before I arrive, and just make sure that I use any responses to schedule in-person contact for as soon as I get there. Thanks for your advice.

</comment></comment><comment><USER3> About a week before my contract for my job in New York City was up, I decided to take the plunge and try my hand in landing some work in the Bay Area. In less than a week, I had been contacted by four companies here, and was offered a position by one of them, which I accepted. I asked them to give me three weeks to be able to move - This meant selling whatever I couldn't afford to move, flying out here to find an apartment and preparing to start a totally new life by myself. They had no problem with that, and let me know that if I needed more time, that I could let them know.

I'd say you should start approaching companies about a solid month before you're going to move here. That should give you enough time to find a good fit, enough time for your new employer to prepare for you, and enough time to for you to begin preparing for the long move. Best of luck!

</comment><comment><USER4> I would say start applying 2 to 3 weeks before you move to SF. Most companies want their employees to start immediately - but realise that most have a 2 to 4 week "notice period" for their previous employer.

Apply more than 4 weeks in advance will just be a waste of time, most companies wont wait that long (unless your REALLY something special).

<comment><AUTHOR> Thanks for the advice, I really appreciate it. Like I mentioned in my original post - it's so hard to keep a clear head looking in from the outside and seeing all the media reports etc.

</comment></comment><comment><USER5> If you're good, you can get a job in a matter of days. There's plenty of hiring out here all the time. We can't hire good programmers fast enough.

I moved out here over ten years ago with pretty much no place to live and a small contracting job. My only regret was waiting so long.

<comment><USER6> He said he wants to do UX or PM work, not programming. This will be a bit tougher to find.</comment></comment>


Grails 3.0 Released and the Road Ahead - <AUTHOR> http://grails.io/post/115110650393/grails-3-0-released-and-the-road-ahead

<comment><USER2> I'm interested in anyone's thoughts on Grails as compared to RoR. Which one is easier to pick up, develop in, has better tooling, etc.?

<comment><USER3> In my experience, go with RoR unless you're already in a deeply-committed Java shop. Rails has much more momentum & community support (even if Node is slowly chipping away at it.)

With Grails by comparison you're more likely to find plugins that haven't been updated in years and be constantly fighting dependency conflicts. At least that was my experience.

If you go the Grails route it's also inevitable that you'll need to learn all of the various "layers" underneath Grails nice veneer. E.g. Grails wraps a lot of existing Java technologies which are fairly complex on their own like JEE, JPA, etc. Rails seems to be "shallower" and easier to grok by comparison.

As an aside, I personally love the Groovy language and syntax too, and how easy it is to interop with any java libraries.

Don't get me wrong, if I needed to write a Java-based, user-facing web app, Grails is the first option I would look at. But short of the Java requirement I would choose RoR or even Sails.js (not as mature but rapidly improving it seems.)

<comment><USER4> You can take advantage of the JVM (JIT compilation, etc) by deploying under JRuby, the Ruby runtime implemented in Java.

</comment></comment></comment><comment><USER5> I never felt comfortable in the behemoth of a framework and the plugin system always seemed a bit odd.

We have stopped building new applications/sites in Grails where I work but still have a handful of ones running on 1.x and 2.x still in operation.

<comment><USER3> Curious to hear what you've chosen as an alternative? It seem to me that all java web frameworks follow this same "behemoth of a framwork/ plugin system" where "behemoth" is really just an indicator of how much the framework makes choices for you out of the box.

If you take something like vert.x in comparison, sure it feels more lightweight unless you need ORM and robust view layer and the things you would need for a front-end framework.

I'm not saying your observation isn't valid, but it feels like a catch-22 in a lot of cases.

<comment><USER5> Well we never were a Java shop, and we already had a lot of python in play so awkwardly enough I settled on web2py for the time being. We happen to have some legacy code that is just easier to incorporate than rewrite which did lead to some of the initial decisions to use groovy/grails.

Some other devs had taken Django on a tour back in it's 1.1-1.2 days and hated it so I was pushed to look at something else. Did not care for Pyramid and didn't have the time to "do it all" with flask so I settled on web2py.

Turns out to have been a great choice for us so far. The framework is still bloated by comparison, so I don't like it when what we should be building is really an API.

However not having a plugin dictate what version of jQuery I am using has been a boon for fronted productivity.

To more directly address my issue with the plugin system, another commenter said it well "With Grails by comparison you're more likely to find plugins that haven't been updated in years and be constantly fighting dependency conflicts. At least that was my experience."

This mirrors my exact experience on several projects I started and maintained. I just assumed it was because I didn't know how to use grail well. Then I inherited a medium sized code base from some developers who were born and bread java EE devs and _love_ groovy and grails and seemed to always know the "right way."

Only problem was, once I started following the code, it was all just java in groovy syntax and just as crusty and hard to update to new versions.

I eventually gave up following groovy releases and just froze all my projects on the 2.3.x line. I was spending more time every week upgrading plugins and fixing issues that never existed before upgrade (like broken JSON and XML parsing).

When it comes to an ORM, I often just try to avoid it unless I am dealing with an application that has data that I know will be very regular and work well as a spread sheet in a simpler context. Anything more complex and I just research it online or start poking my DBA's for proper design/access patterns. This again leads me to why I like web2py, the DAL is very similar to SQLAlchemy's core design. Just a simple abstraction layer for generating queries and maintaining connections/pooling.

We have talked about vert.x, and it seems promising. My reservation is that I am still not a fan of groovy, Jython is not version 2.7 yet, and I don't know scala or want the verbosity of java. So it just is not my first choice although certainly seems promising.

I am tinkering with flask as well. I don't mind the more DIY approach but having to stitch _so many_ things together just for basic functionality makes me glad I am keeping it for my pluggable API idea which hopefully will replace the DB calls in all our grails applications with API calls to the flask app. But that is another story.

TL;DR

Have yet to settle on a single replacement although web2py is serving nicely at the time being. Our primary concerns are ease of maintenance and number of DB drivers supported which is why Java/groovy based framework seemed to make sense at the time but python based framework and tools make more sense now.

Additionally, Node JS DB support is still pretty iffy, No one here likes using PHP or want's to deploy more of it than they have to, Scala is out because Groovy, C# is already used else where but not the best fit for our web-apps and automation, no one here knows more Ruby than what is required to write Puppet modules, Go isn't bad but can't be used to build a pluggable system AFAIK, one one person knows Perl.</comment></comment></comment>


Ask HN: What is the best WYSIWYG Website creator? - <AUTHOR>

Probably not the best place to ask this, given I doubt the majority of the you do not use them, but what is the best WYSIWYG Website creator available?<p>Edit: The replies so far cover websites to do WYSIWYG creating, which is great, but I was more meaning software if that changes anything. <comment><USER2> It depends on what you expect from a WYSIWYG editor. If you want to be able to resize and tweek elements graphically, then there are tools available for just about any platform.

On the other hand, if you're expecting the tool to replace learning some HTML and CSS then you may be disappointed. It's just difficult to debug code (which is what HTML and CSS are) graphically. At least I found it next to impossible, so I gave up and bought _Head First HTML with CSS and XHTML_. I found using a text editor and refreshing the browser much more efficient than dragging stuff around the screen. YMMV.

On the other hand, if you're flexible about the end results, you can get a lot out of a framework like Wordpress with nothing more than picking a theme.

</comment><comment><USER3> I wouldn't know since I'm a Vim zealot, but I've heard good things of Flux [<http://www.theescapers.com/flux/>] You should be giving the trials of the various apps a go instead of asking for opinions though, editors are a very personal and subjective subject.

</comment><comment><USER4> Like ojoe said, depends what you're after. <http://www.squarespace.com/> seems modern and good for design flexibility. For small businesses, I'm building one called NetMate <http://www.netmate.co>

<comment><USER5> "We are the world's first website builders where you only pay, when you get visitors."

The comma should be removed.

I'd consider rewording the entire sentence. Perhaps you could relate your pricing model to the business owner's other fixed costs.

I write poor copy, but something like:

* "No fixed costs. We only charge when a customer views your site.", or

* "You only pay when someone visits your site. Too bad rent isn't the same."

Or, you could completely ignore your pricing model.

"We've done the nerd work so you can do your work."

<comment><USER4> Thanks. Reading it again I agree with you completely.

<comment><USER5> I think it is dangerous to differentiate yourselves with this pricing model alone. You plant an immediate doubt as to whether or not the service is even going to work.

Financial advisors, for example, would be very afraid of advertising "pay for performance" -- and it's not because of the SEC. It's because commission sales lead to suspicion and dissatisfaction.

Sell relationships, quality, and reliability. Price is the icing.

</comment></comment></comment></comment><comment><USER6> ah.. nowadays there are a number of solutions available, so the best one depends on what kind of site exactly you are trying to create. ex:

virtual storefront: shopify.com blog: wordpress / tumblr.com personal identity: flavors.me something else: maybe snappages.com or wix.com</comment>


Ask HN: How do I prepare for a iOS developer interview? - <AUTHOR>

I've been doing iOS development for about 6 months now. My full time job is not a development role, but I'm looking to transfer to a mobile development job.<p>What sort of questions are common for a role such as this? What should I be prepared to answer? What would you want to hear from a junior iOS developer in an interview? <comment><USER2> Here's a good list of technical questions with answers: [http://krish.codeworth.com/development/ios- development-2/ios...](http://krish.codeworth.com/development/ios- development-2/ios-interview-questions-with-answers/)

After that, the typical "Why do you want to work here?" type of questions will most likely pop up somewhere.

Also, I've learned that appearing as if you already have the job (to a specific extent) is a powerful way to stand out from the rest of the interviewees. For example, if the company already has an existing product, make a list of EVERYTHING that you think can be improved, and always provide a solution.

"This transition might appear to be a bit awkward for a new user, but if you had the subview pop up from the bottom here..."

If it's a smaller company, then make making a simple prototype might help. I would be a bit more cautious with this route, but it could prove to be beneficial in the right scenario.

Anyway, best of luck to you!

</comment><comment><USER3> Memory management (ARC vs retain/release cycle) Notification Center vs Delegates, what they are, when to use which Some basic UI stuff Obviously some basic objective-c syntax

How would I prepare? I would look at the type of apps they create, or I might be working on and start trying to duplicate at least one of them. For instance, if they have a popular barcode reading app, create one yourself, maybe even add an extra feature. Show it to them. They'll see it and know two things a) you're capable of creating it b) worst case scenario you can add features to one of their products. aka, you'll never be completely worthless.</comment>


Latest iPhone developer contract appears to forbid jailbreaking - <AUTHOR> http://arstechnica.com/apple/news/2009/04/latest-iphone-developer-agreement-bans-jailbreaks.ars

<comment><AUTHOR> Frankly, I'm not certain that the part saying that applications developed using Apple Software may not be distributed outside the App Store is even enforceable. Where do you draw the line - if you loaded your work-in-progress on a development iPhone? what if you didn't, but used XCode as a text editor? does it kick in if you used the autocomplete feature? It all seems quite silly from a certain perspective - imagine the New York Times selling a typewriter and saying that they had right of refusal for anything you wrote with it.

<comment><USER2> I doubt they mean just using xcode, or no one would be able to distribute Macintosh apps. Linking against Apple's iPhone header files would be a clear violation, though.

<comment><AUTHOR> See, that's what I thought at first. But then I the text would talk about code "using Apple APIs", not "developed using Apple software".</comment></comment></comment>


Innovation, Or the Complete Lack Thereof, In the Start-up Community - <AUTHOR> http://kurt.karmalab.org/articles/2008/06/24/innovation-or-the-complete-lack-thereof-in-the-start-up-community

<comment><USER2> Here's my hypothesis: The cost of starting a tiny startup is now so low, and recovering from a failed startup is so easy, that people are founding "startup companies" as a way of educating themselves.

I wish _I_ had time to build a slavish, mindless clone of Youtube. I would learn a ton of useful things about the data-center requirements for streaming video hosting, the state of the codec universe, Flash programming, how to sell in a crowded marketplace, how to look at another video site and figure out if they're competently designed... I could even practice presenting to crowds of bored investors.

Who cares if the project is ultimately doomed? If you compare it to a college senior-thesis project, instead of to a serious attempt to found a future megacorporation, it all makes a lot more sense. It's _practical education_. And it's probably cheaper than a master's degree (which can't teach you this stuff, anyway).

After you graduate from the silly me-too project you can use your new-found skills to either get a better job at someone else's company, or to help found a second startup with a much greater shot at success.

</comment><comment><USER3> It's natural to lean towards just copying the latest big hit. 1) Market research is done for you, so you don't have to be as convincing to get funding, 2) there's room in any niche for > 1 competitor (first, best, cheapest, at least :)), 3) creativity is hard, new ideas are hard, _innovation_ is hard.

And there's the major reason. We all* want easy money, so we groan and slap our foreheads with poorly disguised jealousy whenever a 14-yr old girl makes a million bucks with crappy myspace layouts. But the thing is, there's positive feedback for taking the low-hanging fruit: You can make a ton of money. And if you don't, at least you didn't have to invest much thought.

The 'problem' (if so you categorize it) is that there's no promise of greater return for greater effort. You can spend your life trying to solve BigProblems until you die, and get further than anyone else, but the guy in the next dorm room retired at 25 after making a social-networking site for parakeets with dyslexia. In two days, in ASP classic.

So if you're motivated by money, success, fame, there's not a lot of reason to go for the hard problems. And those are pretty common (and powerful) motivations.

*All including you, unless you don't, in which case it doesn't.

</comment><comment><USER4> Nature works like this: stumble upon a successful model, spawn a million tiny variations and let them struggle for survival.

<comment><USER5> And there's room for more than one winner, especially if they can find a sub- niche. Flickr seems to specialize in "photographers" and Photobucket has crappy myspace photos. They both "won" in their respective areas.

</comment></comment><comment><USER6> Based on my experience during 1.0, I've been speculating a fall-out relatively soon as I've seen a lot of me-too popups from the critical areas (SF/NY). Roughly 1 year after this influx in 1.0, the bottom fell out.

During 2.0 that pattern was contradicted as social bees tend to migrate and have a lot less loyalty. Friendster > MySpace > Facebook is one example, and there have been a quite a few other. However, is it really a great migration or simply natural segregation at work? I'm beginning to think it's the latter and that being said, maybe there is a play to be made for the me-too sites this time around.

<comment><USER5> While me-too ideas have their place (see my other comment), the game has been to profit by getting VC money more than profit by having a valid business model. People know they can get funding for a relatively "safe" idea possibly easier than a "cazy-but-just-might-work" idea.

</comment></comment><comment><USER7> His point about copycat companies is well taken; one of the shortest paths to failure is to slavishly imitate someone who is already successful.

<comment><USER2> I agree only with the strong form of your statement -- the one that requires us to define _slavishly imitate_ as "with no distinguishing special feature, and targeting the same market".

But I think the weak form of your statement is wrong. Here's Eric Sink, urging you to start a company in a field where there are already competitors:

<http://www.ericsink.com/Choose_Your_Competition.html>

"The big problem with avoiding competition is that you are also avoiding customers. The existence of a competitor indicates the existence of paying customers. If you can't find anyone who is making money with your idea, you really need to wonder if there is any money to be made there at all."

Let's consider the original article's example: cloning Flickr. There may be lots of good reasons to clone Flickr. It's a really new idea, and we haven't had much time to explore the space. For all we know, there might be all sorts of niche markets for Flickr-like services: Flickr for amateur baseball, Flickr for fashion designers, Flickr for medical illustrators, Flickr for architects. Each of these apps might have slightly different features (perhaps Flickr-for- architects would allow you to estimate the sizes of rooms by pointing at the corners of various objects in the photo, or provide various easy-to-use UI elements for matching photos with locations on a floor plan), and each would certainly be sold to a different market (or else they would likely fail -- in the Generic Photosharing market, they risk being crushed by Flickr itself). But there's no reason why they should not all coexist, just as the existence of Starbucks does not, in fact, doom all other coffeeshops everywhere to extinction.

Now, if you clone Flickr but don't add a differentiator, that's probably a mistake. And if you clone Flickr but don't have a revenue model that will keep you afloat, that's a mistake. [1] But there's no reason to expect successful businesses to be _novel_. Novelty is irrelevant. Only _making money_ is relevant.

[1] This is the real reason why it's easy to laugh at many of the Flickr clones: Many of them have also cloned Flickr's revenue model, which involves being acquired by a company that has deep pockets and a large number of servers. It seems unlikely that this plan will work out for everyone...

<comment><USER7> I put the adjective in to restrict it to the strong sense, imitation isn't necessarily bad, intelligent emulation of successful strategies is the basis of progress; but it's a mistake to think that you can succeed as a follower.

The thing I see is that there are a lot of bright young things out there who want to be entrepreneurs but who have not the disposition or the discipline to be creative as entrepreneurs and who for whatever reason don't take a critical look at their goals and methods. Leaping on to the business model of the week becomes a substitute for self-assessment and critical reflection. And of course there is the "ooh that's cool, I want to build one of those!" factor to be considered.

</comment></comment></comment><comment><USER8> There is nothing wrong in being a "me too" clone.

In the early stages of a market (in any business), when someone stumbles upon something new/novel/untapped, there is always a land-grab and (initially) often plenty of users for everyone.

Ultimately success really comes down to the offering provided (e.g. you offer same service but USP being simpler GUI that saves you time) and the ability to iterate quickly and develop features that users want and find value (ideally without adding unnecessary complexity to what you already offer).

Many a successful company started as a "me too" clone (or late entrant), later becoming the dominant player.

It is only when the market is saturated do other issues such as "churn" etc. (e.g. as seen in the established mobile-phone markets) start coming into play. Now entering the market is actually not a good idea, unless you are offering something radically different (ideally a disruptive technology), but then you would not be a "me too" clone.

<comment><USER9> Correct. The problem is that I am still running into people who are making "Youtube with a twist". That boat has sailed.

</comment></comment><comment><USER10> We are constantly hearing advice like "Scratch your own itch," "Find problems close to you," and "Code what you know," which is all good advice for finding a startup idea.

What then, do you do if you're not exposed to much?

When I spent time talking to people in SV 2 months ago, I noticed something I never expected: lots of people have very little exposure to "real world" problems.

People come up with "me too" startups because that's all they know.

Sure it's easy and cheap to start a business, and if you're smart and can hack, all the more reason. But what about the giant issue hardly anyone mentions: real world experience.

I've been doing programming work in real businesses for years and _still_ get excellent startup ideas from my customers almost every day. In the past week alone, I have been challenged with problems I've never seen before that are really affecting these people. Just a couple of quick recent examples:

\- One customer is preparing blanket purchase orders for '09 models, but since the SKUs change every season, their ERP system is of little help.

\- Another is setting up a new warehouse, but their app won't allow bulk updates so they have to hire clerks just to enter 10,000 new bin locations.

\- Another has a call center whose response time has doubled with an upgrade to their app. Now they want the new release's functionality with the old release's interface.

And this is just one week! People will pay big bucks for technical solutions to these real world business problems.

My advice to a young hacker with lots of skill but not much experience (outside of college apps): you may want to consider getting a job for a year or two. I know, everyone wants to start the next <whatever>, and get rich now and no one wants to sit in Megacorp's cube farm. And a startup, even a failed one, may be a better education.

OTOH, you will acquire dozens of great startup ideas (and contacts) and avoid the "me too" trap. Something to think about.

<comment><USER2> I agree with all of this and would add just one observation: All of these valuable, profitable ideas will probably seem _really boring_ to (e.g.) the audience at the typical Web 2.0 conference. SKU's, yawn. Call centers, yawn. Warehouses, yawn.

<comment><USER10> "Boring" is in the eye of the beholder.

Once I really understood relational data base theory, those things (SKUs, call centers, warehouses) became exciting to me. A chance to practice what we preach. My customers are laboratories, much more so than Carr Hall 203 was in college.

OTOH, most people I know think _everything_ we do is boring. They'd rather watch TV and talk about each other. Fortunately, we know better.

<comment><USER11> Dude...I understand relational database theory, and those things _are_ boring. I'd rather gouge out my eye with a rusty spoon than normalize schemas for SKU databases at BigCo (I wanted to gouge out my eyes when we used them as case studies while _learning_ relational database theory!)

That's not to say that there aren't interesting engineering problems buried in there (e.g. how does one build a high-performance, distributed database architecture that can support tens of thousands of concurrent users, blah blah blah), but for the most part, the _interesting_ portion of that kind of work is done by the (small) company that developed the scalable database technology in the first place. When you're hired as the guy who puts it all together as BigCo's real-time widget tracking system, you're mainly splicing together chunks of other people's previously interesting work.

Most paying work is boring -- that's why it pays. But if you can eliminate a _class_ of boring work with a good piece of software, then you've got a business.

<comment><USER10> Dude...there are 2 kinds of things we can work on: things for ourselves (internal) and things for others (external).

"Building a high-performance, distributed database architecture that can support tens of thousands of concurrent users, blah blah blah" is an internal project. One we do for ourselves. So that we (as users) have what we need to do our jobs for others.

Personally, I prefer external projects. Both of my mentors were engineers. Everywhere we went, they had something to say about what they observed:

"I wonder what would happen if they put a Coke machine right there..."

"The plane landed 17 minutes ago, and so far 0 bags have been removed..."

"If we move the inspection table to the center of the department, we will save an average of 116 steps per person per inspection..."

That's how I think now. I have real world customers and prospects with problems like these all the time. I love it. I'm always on the lookout for problems to solve with my apps.

I simply don't care about working on any internal projects unless I have to. There is probably a solution somewhere that one of you guys already did. So I'll use it to help me do my job.

Sorry you find what turns me on as boring. I guess that's what makes horse races.

If we ever meet, remind me to hide all the rusty spoons.

<comment><USER11> I'm puzzled by this whole "external" vs. "internal" dichotomy that you've built. Perhaps noticing that your plane isn't being unloaded quickly is "external", but the likely solution to the problem (building some sort of high-performance, distributed database-backed scheduling architecture that track thousands of bags, flights and people in real time) seems to become "internal" very rapidly. Where's the line?

Moreover, what you describe as "external projects" sounds suspiciously like "walk around and fix individual problems in the world". That's great, but it's not scalable -- it's consultancy. Somebody hires you, and you tell them to move their Coke machine to save 116 steps per inspection. To me, the difference between that and an interesting _software_ problem is the difference between noticing that a Coke machine needs to be moved, and writing a pedestrian traffic simulator that can be used to optimize the positions of Coke machines in any context...but maybe we're saying the same thing?

In any case, it's never a good idea to let your spoons rust.

<comment><USER10> Those were just examples of what others did to influence me. That's all.

I used to have to write the tools I needed first just to be able to do my job. No longer. Almost all of my tools are available.

What you call "walk around and fix individual problems in the world", I call "find problems anywhere, then build scalable solutions". Sorry if I didn't make that clear.

It's the antidote to OP's original complaint of "me too" solutions.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Without specific examples, this article is as useless as the vague me-too startups the author can't be bothered to write about. Thumbs down.

<comment><USER9> I'm not going to burn bridges with people when it really wouldn't add anything. The point is valid with or without specific examples.

</comment></comment><comment><USER13> The author has apparently discovered that Sturgeon's Revelation applies as well to start-ups as as it does to science fiction.

</comment><comment><USER14> The truth is that computer programming skills are a commodity and that the silicon valley culture is no longer relevant to big problems. The world has moved on, the same way it has moved on from industrial and agrarian economies. These silicon valley folks are as desperate and clueless about solving todays big problems as the corporate people were about solving the big problems silicon valley sprang up to solve.

Getting them to understand is like yelling at water not to flow downhill.</comment>


How can I have a part-time job so I have time for my startup? - <AUTHOR>

I've been freelancing but I realized that I need to put so much time and effort in my freelancing venture than in my startup (finding clients, paperwork, etc.).  So it's finally becoming a distraction.
As said in this thread (http://news.ycombinator.com/item?id=142239) it seems impossible to find a part-time programming job.  I've been thinking even about working part-time on a retail store or a restaurant, but I would prefer a job where I can exercise my programming skills.
Is it a better option to get a full time job for a year saving money, and then quitting and working full time on my startup?
Thanks. <comment><USER2> A long long time ago I was facing this exact problem, and I decided to go for a non-programming part time job. I ended up delivering mail, and it was actually quite well suited because:

\- it's a physical job, no brain power required so you can think about other stuff while getting paid and nobody will care

\- it is not a job where you are irreplaceable, so if you call your boss and ask for a day off (because you have to meet a customer, say) it usually is not a problem

\- it won't take much to stand head and shoulders above your co-workers

\- if you take an early shift and indicate your preference for that you have to be up at 5:30, on the job at 6 am but by 1 in the afternoon your shift will be over, half a business day left!

\- using a cell phone and a headset you might even get away with keeping your business running while you are working (this option, alas did not exist when I was doing this)

Also, and this is probably quite important, if you ever need to fall back once you have seen a period of full-time employment when you are doing well and things are in the dump for a while chances are big they'd re-hire you on the spot if you were any good at all.

good luck!

</comment><comment><USER3> There are two dilemmas with part-time programming. 1) I suspect that most employers prefer to attempt to extract all possible programming productivity from their employees, and ask/expect them to work more than full-time (SV startup bias,) so a part-time employee is really like a quarter or a third -- in management's eyes -- of a "fully dedicated" employee, and may not be worth 2) the worse overhead/productivity ratio of part-time programming. Unfortunately, many organizations have high process overhead for the task of programming. This may be comprised of meetings, email and so on. A part-timer still has to be "kept in the loop", and the effort to do so does not scale back linearly with the scaling back of time worked.

Have you minimized your expenses?</comment>


Resurrecting impl Trait - <AUTHOR> http://aturon.github.io/blog/2015/09/28/impl-trait/ <comment><USER2> This would be a great addition. After non lexical lifetimes this is probably the most awaited post-1.0 feature.

</comment><comment><USER3> What's OIBIT?

And why is a new sigil required, instead of:

         fn produce_iter_static<I: Iterator<u8>>() -> I

<comment><USER4> >What's OIBIT?

Opt in built in trait. These are traits that implemented for everything by default. They are generally marker traits for some kind of functionality. The standard library has Sync (shared memory thread-safe) and Send (thread safe to send over a channel). Some more detail can be found in the RFC[1] that implemented them.

[1] [https://github.com/rust- lang/rfcs/blob/master/text/0019-opt-...](https://github.com/rust- lang/rfcs/blob/master/text/0019-opt-in-builtin-traits.md)</comment></comment>