Idiomatic means "using expressions that are natural to a native speaker." It's very possible, but not idiomatic, to write functional Java (pre-8). It's often more verbose and difficult to follow because there is no real notion of higher level functions or composition, let alone immutable data structures. The guava wiki has a good example of this: https://code.google.com/p/guava-libraries/wiki/FunctionalExp....
That doesn't mean that idiomatic practices are always virtuous, but non-idiomatic code is only virtuous because it overcomes an inherent mismatch between what the user wants and what the language provides. With many languages (certainly js, java, c++) we see non-idiomatic practices guide changes to the language and then be replaced. Java gained functions to avoid the abuse of anonymous inner classes. ES6 is stealing from transpiled javascript languages left and right.
Making idiomatic code virtuous is the goal of creators and maintainers. Writing idiomatic code means that you have chosen languages, frameworks, and libraries that are closely aligned with the code you need to write and the style you want to write it in.
Just to be clear, the criticism is of Redis Cluster, which has been redesigned because the first design was so lax it was effectively unusable. The real issue, is that as of right now I have no idea what the exact semantics and failure conditions of Redis cluster are. I'm not clear that anyone really knows. Salvatore thinks he knows, but we can't be sure that he does.
With all this talk of practicality, what really makes distributed systems practical is when someone can do a formal analysis of them and conclude what possible states can occur in the system. This is not work that database users should do, it is work that database implementors should do. The failure to use a known consensus system is a failure to deliver a database I can understand.
I find this all a bit disappointing since I've been a huge fan of Redis since the early days. It's an amazing tool that I still have in production, but I get the feeling that it's utility will never expand to suit some of my larger needs. Bummer.
They handle automatic failover, which redis does not currently do out of the box. That part is pretty cool. Maybe not worth the price, but definitely useful.
Adzerk is focused on helping publishers make more money from their ad inventory by building a revolutionary ad serving platform. We believe that making advertising a viable business model for publishers ensures the future of a free and healthy internet. We love nothing more than helping a great publisher be rewarded for their hard work and help them continue to create awesome content.
We're looking for software engineers, both senior and junior. Our needs are all over the place, from UI to data warehousing, so there is a lot of skills you can bring to the table and many areas to play around in. We've got 10 people on the team right now and we are planning to grow!
Adzerk is a Durham, NC startup that’s helping content publishers make more money from their ad inventory by building a revolutionary ad serving platform. We serve ads for reddit, stackoverflow, and other sites you've probably heard of.
The pre-internet version of this is Steve Albini's "The problem with music" which shows how major labels can end up costing bands quite a bit of money. Originally printed in Maximum Rock 'N Roll in 1993, but reproduced here on Negativland's site: http://www.negativland.com/news/?page_id=17
It's worth the read if only for the amazing end line: "Some of your friends are probably already this fucked."
Sorry, I don't make it a habit to plug stuff I submit to HN, but in case anyone is interested, I submitted Albini's article here: http://news.ycombinator.com/item?id=4901063
I used to do music and a lot of my friends and I discussed the economics of music a lot.
The funny thing is...some of my friends really ARE this fucked. As in, literally. I have friends who are signed and tour a little over 50% of the year all over the world. They get depressed and always ask us to email them to keep them from getting too depressed or from going out of their minds.
People who would work out perfectly in the R&D division of SAS Institute are not necessarily great first hires at consumer web start-ups (forgetting the potential skill impedance mismatches). There are lots of implicit ideas about "how things get done" that are part of any group. These ideas are the culture.
e.g.
Does the team practice TDD? Do they focus on unit tests or integration tests? How is work assigned? Does the team prototype ideas or discuss them in the abstract? If someone says something you think is wrong in a meeting, do you confront them publicly or privately? 12-hour days? Do you pick tools that are cutting edge or proven? Duct tape together two open source libs for one feature or write your own? And of course, the classic: Is it better to a) ship early with known non-critical bugs, b) ship on time with no known bugs, but inadequate testing, or c) when all/most stakeholders feel confident the project is bug-free?
These questions aren't nearly as binary as I've presented them (and there are many more). If you and your potential new team don't agree on these issues that's a poor cultural fit. Like a poor technical fit, it doesn't necessarily mean you shouldn't be hired, but it does merit significant consideration.
I can't agree with this. It's true that many languages work well as starters, but there are certainly some that don't. I think java is a classicly bad first language. There is a lot of ceremony which will take you a considerable amount of time to understand (public static void main) and it's also heavy handed on object orientation. Whether these things are useful in long run is debatable, but it's an amazing amount of conceptual overhead. Worse, unlike the overhead of low-level language like C, the pain in a language like Java comes from complex abstractions. Understanding pointers is difficult for many people, but it's mostly based on whether you understand how in memory storage works. There's a more straight forward path to that than to understanding the how/why of OO.
That doesn't mean that idiomatic practices are always virtuous, but non-idiomatic code is only virtuous because it overcomes an inherent mismatch between what the user wants and what the language provides. With many languages (certainly js, java, c++) we see non-idiomatic practices guide changes to the language and then be replaced. Java gained functions to avoid the abuse of anonymous inner classes. ES6 is stealing from transpiled javascript languages left and right.
Making idiomatic code virtuous is the goal of creators and maintainers. Writing idiomatic code means that you have chosen languages, frameworks, and libraries that are closely aligned with the code you need to write and the style you want to write it in.