dbcfd

Except for studies that indicate otherwise. And that their salary is determined by a board of their peers, whose salaries are determined by boards that may include that executive.

There is no downside to increasing CEO compensation for these boards.

> less code, less bugs and less bullshit than the horrendous status quo of corporate Java development.

It may take some getting used to syntax and design wise, but being able to code things up in 1/10 the size of other languages completely blows away the disadvantages of Scala.

> Coming to Scala from experience including C, Java and Haskell, I intially found Scala quite difficult.

I think because it allows you to do OOP and FP, Scala becomes difficult since it is so easy to mix the styles. Similar to C and C++, this is very powerful, but also very dangerous. The main learning curve is programming in a way so you don't shoot yourself in the foot while using its flexibility.

Make it a product, and I'd be more interested. A number of companies have their own hosting, so the hosting part is not only unneeded, but is also usually a non starter.

Not really. They handle querying and aggregation much differently.

For people coming from SQLServer/MySQL/Postgresql, the functionality differences between the NoSQL flavors is something they don't expect, and often don't explore. There are a number of heavily used NoSQL solutions because they're focused on specific use areas.

What is the syntax on finding an array value matching some key? E.g. given a user with field "favFoods":[String], how do I determine that pizza is in there?

Querying, and querying immediately after insertion. If you want queries after insertion (which require views), this can be slow in couch. Also, if you want to query, but don't want to add a view, wait for it to populate (causing a performance hit while it builds, plus while it is up), then remove it.

If you're doing primarily insertion with querying via id, and using views in which stale data is ok, then couch is far superior to mongo. But that's not a use case everyone has.

> Keep in mind the constraints in the article, for example: some shows have 20,000+ episodes, actors show up in 100s of shows, and "We had no way to tell, aside from comparing the names, whether they were the same person".

As others have pointed out, it requires two trips to the database. Given their architecture (distributed nodes), network latency is minimal, so this is essentially two calls to the database.

show { _id, title }

actor { _id, appearedIn : [id] }

db.find({"title":"awesomeshow"},{"_id":1}) db.find({"appearedIn" : showId})

Each actor is unique in the database, when you query, you get back unique actors. I'm not sure why they're scared of joins (or multiple queries in mongo).

The question you ask yourself is not whether you're joining, but how often you're joining. If you're not joining often on actors and shows, document databases can work better, since you represent the show and all its episodes without having to join.

From my tests with couch, the view isn't populated immediately after a document has been inserted, and may take some time. I think I tried this doing insert bulk, wait for view, insert 1, query, but I'd have to double check.

From another comment I made, on why I don't think is a good article even using the proposed thesis of "mongo doesn't work for graph like relationships":

Even though their data doesn't fit well in a document store, this article smacks so much of "we grabbed the hottest new database on hacker news and threw it at our problem", that any beneficial parts of the article get lost.

The few things that stuck out at me:

* "Some folks say graph databases are more natural, but I’m not going to cover those here, since graph databases are too niche to be put into production." - So you did absolutely no research

* "What could possibly go wrong?" - the one line above the image saying those green boxes are the same gets lost. Give the image a caption, or better yet, use "Friends: User" to indicate type

* "Constructing an activity stream now requires us to 1) retrieve the stream document, and then 2) retrieve all the user documents to fill in names and avatars." - Yep, and since users are indexed by their ids, this is extremely easy.

* "What happens if that step 2 background job fails partway through?" - Write concerns. Or in addition to research, did you not read the mongo documents (write concern has been there at least since 2.2)

Finally, why not post the schemas they used? They make it seem like there are joins all over the place, when I mainly see, look at some document, retrieve users that match an array. Pretty simple mongo stuff, and extremely fast since user ids are indexed. Even though graph databases are better suited for this data, without seeing their schemas, I can't really tell why it didn't work for them.

I keep thinking "is it too hard to do sequential asynchronous operations in your code?".

db.find({"field":"value"},{"field":1,"someotherfield":2})

Finds all documents with field having value, returning only field and someotherfield. That part is similar to the map portion of a CouchDB/Couchbase view. No reduce portion though.

If field is what the index is built off of, it should be similar performance wise to a view. Just like views have to be created beforehand, so do mongo indices.

The difference is the find of a mongo document will happen much more quickly after insertion than the find of a couch value by view. Views require rebuild in couch which is not instantaneous.

Even though their data doesn't fit well in a document store, this article smacks so much of "we grabbed the hottest new database on hacker news and threw it at our problem", that any beneficial parts of the article get lost.

The few things that stuck out at me:

* "Some folks say graph databases are more natural, but I’m not going to cover those here, since graph databases are too niche to be put into production." - So you did absolutely no research

* "What could possibly go wrong?" - the one line above the image saying those green boxes are the same gets lost. Give the image a caption, or better yet, use "Friends: User" to indicate type

* "Constructing an activity stream now requires us to 1) retrieve the stream document, and then 2) retrieve all the user documents to fill in names and avatars." - Yep, and since users are indexed by their ids, this is extremely easy.

* "What happens if that step 2 background job fails partway through?" - Write concerns. Or in addition to research, did you not read the mongo documents (write concern has been there at least since 2.2)

Finally, why not post the schemas they used? They make it seem like there are joins all over the place, when I mainly see, look at some document, retrieve users that match an array. Pretty simple mongo stuff, and extremely fast since user ids are indexed. Even though graph databases are better suited for this data, without seeing their schemas, I can't really tell why it didn't work for them.

I keep thinking "is it too hard to do sequential asynchronous operations in your code?".

There's also the fact that what they were trying to do in Mongo was not what you should do in Mongo. Use a relational or graph database for data that is best represented as a relation or graph.

Nothing like using a hammer to paint a wall and then say you should never us a hammer.

I think this is the first post on HN I wish I had a downvote button for, just for the reason you list. There is a reason there are different flavors of databases, and MongoDB most definitely would not be my choice for representing graph like relationships.

It's also scary that it has 217 points because it bashes Mongo.

No RAII is one of the things that really bugs me about go. I can't just construct an object and have it be ready, I have to remember to call some other method. Rust's memory model is also better, since it's akin to shared pointers (which you know the lifetime of) rather than garbage collection.

I'm a serious C++ programmer, and I'm also in the Rust boat, rather than the Go boat. I've tried Go. More than once. And each time, I feel really restricted. I feel like I have to solve problems a certain way, rather than the way that fits the problem. With C++, I have multiple approaches to solve a problem, and can choose the one that offers the best trade off of performance and maintainability.

For now, if I'm really wanting concurrency, and don't feel like C++ is doing what I need, I'll grab Java/Scala with Akka. They allow me to create a solution tailored to a problem, rather than tailoring a problem to a solution.

I think he's trying to get at what happens if an operation becomes non-atomic. In the case of the long long, there could be two register loads, rather than one. Normally, you would expect calc(1) to return m1 at t0, or m1 at t1, dependent on when the change thread hits. However, if your operation requires two register loads (long long on 32), you would have a third value produced, which is neither m1 at t0 or m1 at t1.

This could be considered a non-thread safe operation.

I'm not sure how it would produce varying behavior if it satisfies the const contract, in regards to the object itself.

You're passing in a non-const reference, so wherever that came from would be expected to change. However the object itself would not change. Your object would be at StateA regardless of who gets the mutex first.

const_cast = code smell mutable = code smell

Pretty much anything that breaks the contract is readily apparent when reading/searching the code, and indicates that something needs to be rewritten.

Just because you can break the contract doesn't mean you should break the contract. Const correctness produces more readable/easily understood code.

Don't be lazy, and make life better for anyone that has to maintain and use the code after you.

And that's where functional programming languages are gaining over imperative/oo languages for multi-threaded behavior. Because you have the ability to break the contract, it produces code that is harder to follow, harder to learn for beginners, and harder to debug in parallel/concurrent contexts.

It's a shame that this is more best practice. Hopefully the specification will address this in the future that you can only call const from const, and cast from const to non-const can't be used.

The only time I could see that not being threadsafe is with something like a double on a system without native support, such that bits could change during operation. Even then I think the information gets pulled out.

On most systems, the value of calc will still be a race condition dependent on what thread gets there first, even if you lock around m1 or make it atomic. Calc will pull the value from m1 into a register, perform the operation, then return the newly calculated value. Another thread changing m1 will not matter.

C++11 is finally saying that this is not ok, as it really breaks the const contract, and can produce varying behavior in a threaded situation.

You could also argue that read/write locks aren't legitimate applications (starvation, increased contention, alternate solutions).

No.

If you used const correctly, you couldn't change anything about the class, therefore it was also thread-safe. If your class had mutable members or got around the const guarantee through backdoors (e.g. pointer passed in that modified another object, or member pointers that called non-const methods), it wasn't correctly const and shouldn't have been marked as such.

There is nothing wrong with the const keyword, just with programmers who marked things const that broke the const contract. There is no language ambiguity on this.

I was more surprised by a technical post complaining about workers, waiting on io, and context switching. There are ways to handle concurrency and network communication without large amounts of context switching and threads.

> Don't want to sound like a snob, but it really looks more like a design problem than a language problem.

I stopped reading about halfway through as most of the code samples reinforced this.

Just make sure whatever you do on the side is truly on the side. Even if you code something up at work they may help some open source project you're interested in, recode it away from the office on your own computer.

In terms of your projects, stick to the "in no way competes with their business". This gets harder with larger companies, but after working there for any amount of time, you'll readily see which projects of yours will conflict with their business interests.

If you're worried a project might conflict, propose it as an internal research initiative. You may luck out and get to work on something you really enjoy at work.

Good luck getting a power user (or god forbid, a community moderator) review removed.

A number of them feel they deserve preferential treatment because of their Yelp status, and will go out of their way to bash you when that doesn't happen.

> The very first four-star filtered review this business has mentions the waitress and host by first name (she goes on to sign it). Many of the other reviews for this business are similar and come across as fake or by people who mean well, but go overboard on behalf of their friends.

Or they actually really like the business? It's not staffed by 30 different no names, and you never get the same server? The owner will actually be present and greet customers?

That's not gaming the system, that's providing great service in a fast food lifestyle.

As a business owner, I have also seen the extortion for advertising model. Businesses that advertise with Yelp have low star reviews filtered, while businesses like mine that do not, have reviews from valid customers (often with friends and other reviews) filtered, to lower star ratings.

I have also seen reviews that are blatantly fake (e.g. reviews from Santa Claus, comical reviews, etc.) persist, until a significant amount of time passes. This indicates manual removal, and no actual Yelp filter.

That's what it seems from the comment that as the noise increased, 66% of the zero error workers still found the level acceptable, while only 8% of the one more defect workers found the level acceptable.

I think it's less tolerance and more focus. Workers that can focus appropriately can store the requisite information to solve the problem in their mind. Those without focus will introduce defects as information not task related is encountered and processed.