I can actually see why some VCs would invest that way though. A startup proves that there's a massive market opportunity (think Uber's initial days), it's still not a certainty that that startup will be the eventual winner. So, I can see some VCs thinking: Now that one of the biggest risks (finding whether there's a market at all) is reduced, we can just build a better team and maybe become a much better second-mover. Or, although I am convinced that there's a massive market, I disagree with how the first-mover is trying to handle it.
> what are the odds that an overseas call center would cost more than anticipated (often the case), lower the quality of service and thus the company's reputation, or actually be enough to stop the downwards spiral rather than just signaling that you're in a low value-add commodity business?
I would imagine that a company as large as LS would have used some analysis and external/internal data to estimate the overall costs of such a move (which would include the cost of lower quality of service etc). And they must have still found the move cost-effective.
It's slightly insulting to LS employees to think that they would know less about the cost-effectiveness of this move than us. Moreover, this move seems drastic. When you're making such drastic moves, you're likely doing so to be able to survive. In such cases, lower quality of customer service and poor signals etc take a back seat.
Whether a shareholder will get any returns in Living Social is not what I'm talking about. As a company, their job is to do whatever they legally can to protect (and grow) a shareholder's investment. If hiring Americans goes against that, then they should not hire Americans.
If you had your savings in this company as a shareholder, and if you knew that the company could survive and maybe prosper (unlikely in case of LS) by reducing its cost of customer service by outsourcing it, then would you not support this move?
This is not very different from when you decided to buy a decent quality product made in China when you could have bought a slightly better quality product made in USA for 2X or 3X the price. I'm obviously guessing here to be more dramatic, but the point is true in general.
Cost has always been a major factor in many decisions we make as individuals or organizations. And for a company (which has fiduciary duty to its shareholders), cost is definitely a more important factor than being able to hire Americans.
The most interesting bit for me was about "Social Screen." If I understand correctly, this will allow two people to play non-VR games on the same PS4 without splitting screen on TV. One person will be looking at the TV, and the other person will be looking at the VR headset. This means that even if we get no good VR games for a while, there will still be nice benefit of owning a VR headset.
Consider doing this "Moneyball" experiment using Football Manager [1] games. Those games are made for soccer/football management simulation. And your "Moneyball" kind of playthrough is called LLM (Lower League Management) in the FM community.
Thank you for sharing this. If you are open to some constructive feedback, I'd say - The best help that Elixir can get at this moment is endorsements / detailed-examples from large and respected companies. That will help a lot of developers convince themselves and their teams that Elixir is ready to be considered seriously. So, although the brief mention (and some data) that Pinterest is using Elixir for Pinterest API and Ads API was helpful, more details about how Pinterest is using it and more details about what benefits it's getting because of that would help Elixir and its future users a lot!
Yes, I'd say modern Java is a good candidate too. However, the verbosity is a deal-killer for me. Go's error handling can be verbose, but while scanning the code, if I want/need to, I can easily skip through the error handling parts mentally. Java, though, is verbose everywhere. EDIT: Actually mtrn said it better: Java feels over-engineered.
In addition to what melted said, Go has strong opinions about things (we want to keep language simple, we want to encourage writing maintainable code, we want fast compilation, etc) and it's okay if those opinions mean it can't please some critics. For example, Go isn't against generics. They just don't know (yet) how to do it while keeping language simple and compilation fast.
Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes.
EDIT: I must highlight the point about checking lot of boxes. In many discussions about features of programming languages, we get responses like, "language Y does that too. Why not choose that language?" Well, because we don't pick languages for one specific feature. We pick them for the combination of features.
I'm not sure how I feel about it either. That's why I decided to ask for feedback. As for responding to sarciszewski's comment, there will still be a salt on the client side. We obviously don't want to use a fixed salt for all users.
Very valid questions. Let me try to answer them and let's see if those answers are valid or not.
Yes, the scrypt hash just becomes the password for the server. However, this password is going to be unique and almost impossible to guess. Salting this password on server side doesn't give us any additional benefits. The server can store the salt that the client used, though.
Yes, the MITM point was minor. Just another minor security benefit on top of TLS (which takes the majority of the burden of securing against it). So, maybe I shouldn't even mention this point.
I think as HNers, we're focusing too heavily on niche cases (like running your own email server). But, for general public who is still sharing their own (and more importantly, their clients') SSNs, passwords, and other very sensitive information on email, this may be the trigger that educates / trains them to be more careful. I am definitely looking at this as a positive.
I wonder how much of that revenue came from VC-backed startups that just want to acquire a user-base whatever the cost. Mobile app install costs $4+ for iPad and $2.5+ for iPhone. Even at a 100% install to launch rate and a 5% conversion rate, companies need to make $80 per paying users for the numbers to work. This just doesn't seem sustainable to me.
You may be under-estimating how competitive and difficult becoming a big fish at Goldman Sachs is. And in many places (ex, banks), your technical chops are not appreciated as much.
A chess game is, in the end, a massive tree of all possible moves that can be made. Once computers are powerful enough to simulate all those possible moves, they can be sure of winning (or at least not lose) every game against a human starting from move #1. Just like tic-tac-toe.
Maybe you can consider getting someone at Let's Encrypt review diafygi's acme-tiny code and, if approved, propose it as an alternative on the Let's Encrypt site. This will be very useful for users who get turned off by the root requirement or the number of dependencies.
This is good news (hoping the github link etc will start working in a day or two)! One side effect of swift being open sourced is that more developers will start looking at it for server side development. However, I personally think that Swift will continue to have strong reliance on Apple (esp considering that most external Swift developers will come from iOS development). So, till I see Apple showing interest in Swift getting used on server side, I'll not use it there.
Well, there's also a self-fulfilling aspect when it comes to top ten VCs doing consistently well. Entrepreneurs and startups that are somewhat successful / proven can pick any VCs they want. And they pick the well respected (ie, historically successful) VCs.
I think one reason is that you use your Mac to create/develop, whereas you use your iPhone to consume (I'm obviously generalizing). You need more flexibility and control with tools that you use to create/develop.
We're considering using API Gateway and Lambda for our upcoming API service. Would love to hear feedback from anyone who's tried it. From the linked article, I got one gist [1] which wasn't very favorable for the API Gateway + Lambda setup.
Diane was 43 when she founded VMware, and 56(?) when she started Bebop. That's encouraging. Does anybody have details about her background in the years 1978 to 1998?
Both Apple and Google take 30% cut. There's no way a game developer will want to use a PlayStation or Xbox VM and pay them another 20% (that's what console makers get today I think). They'll rather use an engine that already supports multiple platforms. All app developers are already building apps for Android and iOS without using any VM in most cases anyway.
Microsoft and Sony make billions of $s in revenue from their console platforms. It's not easy to switch to a VM play where you're a "nice to have," not a "must have" and continue making billions of $s.
Sony, Microsoft and Valve need to push for their hardware because otherwise there will be no need for their platforms. Why would Bathesda create games for the PlayStation VM or Xbox VM if in the end the VMs are running on iOS or Android or whatever else OS? They'll directly create games for the App Store or Play Store instead. Nintendo makes enough first party games to consider doing what you're suggesting. Just what Sega did in the past. Valve had to work on their own hardware due to the threat of the Windows App Store.
I see. So goroutines are just green threads with a nicer name? Thanks for correcting me. EDIT: Editing my comment because I can't reply to your reply. Yeah, I used "just" with the intention of saying that goroutines are well within the category/definition of green threads.