Hacker Newsnew | past | comments | ask | show | jobs | submit | biokoda's commentslogin

Schemas are per actor type and you can have many types. Actors are active or inactive. When you run a query against one, when it becomes active it will check if schema has changed and apply that before processing any query.


It's raft; thus firmly CP.


That does not always follow. A db designer still has the flexibility to give a client less than serializable/linearizable consistency if the client so wishes.

For example, it is possible for the db to allow direct access to any replica, not just the leader, and if the replica is not part of the quorum, the client will see outdated information. This may be just fine for data that seldom changes, or where a certain amount of staleness is just fine.


From that point of view yes you are right. There is a ton of nuance in CAP. Usually in these discussions the CAP question is if it is eventually consistent or not.


That's the problem... There's not a ton of nuance in CAP. CAP has a formal definition and a system is provably at most CP or AP. Other terms that people often associate with CAP is where the nuance comes in. The reality of the matter is that systems claim to be CP or AP, but most have assumptions or bugs that violate it, so in the end, most systems are just P.

Stale reads technically violate the definition of Consistent in CAP. Using raft means unavailability of some subset of nodes can make the entire system unavailable, violating the definition of Availability in CAP.

So the parent comment's suggestion of serving reads from any replica would result in only a partition tolerant system, without any formal availability or consistency guarantees.


Yes a user space thread pool which is what node.js does on top of libuv.


> Waiting 200ms for the database + an additional 20ms for rendering

Those are pretty awful numbers. https://blog.gigaspaces.com/amazon-found-every-100ms-of-late...


History has proven that anyone no matter their abilities is going to shoot themselves in the foot regularly while using C. Some just less frequently.


That is entirely untrue. Releases are regular, big changes are anything but.


Responding "this is entirely untrue" to someone who is saying how something feels to them is not only overly harsh, but entirely inappropriate. You cannot dictate people's feelings. You might think they have misconceptions that are leading to how they feel, but that doesn't make how they feel untrue.

I can understand if you feel frustrated because you don't think this feeling is warranted, but this is not a constructive way to express that, nor fix the problem.


I think there was just enough content in his reply to escape the accusation that he was merely gainsaying (which would be dictating feelings, as opposed to providing information that might dispel them.)


Depending on how you define "big changes". For example, I consider the static reference convenience feature described in the 1.21 release announcement to be a small new feature, but it does affect how people write code (that's kind of the point! :P ).


> Depending on how you define "big changes".

The way every reasonable person would. This release being the obvious example.


> Well, someone probably said the same about Go or React-Native when they first came out too

RN came from a giant company that uses it in its core product. Big difference.


Use to be that if there was a nice open source project that solved most of a problem you had, you'd jump on, if you had the ability, and contribute back to it. Now I guess we just wait for random handouts from big companies so we don't have to do any work ourselves. Bit of a shame, the appification of open source, but I guess that's where it's going. Big and supported, with no room for newcomers. I wonder how this is much different than what people say about net neutrality? Once the big guys are there, they'll actively do what they can to kick the latter down so no upstarts can chase them up it, and I guess this is just as true of the web. Hope we can find a big company to release us an open source web replacement one of these decades, since I guess we won't be able to band together and build it for ourselves.


I see it as a sign of maturity. People now realize it's completely unreasonable to think about debugging or maintaining some codebase as a hobby themselves (aka: in addition to the product they're building). For a cross-platform dev framework on mobile, knowing the pace at which those platforms are moving, you need something that has both the team , the fund and the stakes.


> Now I guess we just wait for random handouts from big companies so we don't have to do any work ourselves.

Yeah the kids nowadays are terrible.

Large codebases have never been particularly welcoming to newcomers.


We grew up and realised that only open source from big companies actually pays the bills.


Painful but honest at least.


As did Go - Google is as equally giant as Facebook and uses Go in it core products.

cf https://talks.golang.org/2012/splash.article

(Agree with parent but not wanting Go to be left out of the "giant company" bucket.)


You're comparing Go to RN. The comparison he's making is Matcha to RN. Matcha doesn't come from a giant company. The language it's in does, but that doesn't mean anything for framework momentum.


We are discussing about the framework itself and not go as a language.

The framework is a nice idea, and will definitely help into diversifying some of the mobile frontend stuff.

On the other hand you can't compare RN to this framework.

As the person you commented on, facebook has been using RN on its main products like instagram, so it has proven that the framework can be placed on production ready apps with a massive userbase.


That's not really a direct comparison. We're not talking about languages here - it's the framework. React Native is used and developed by Facebook, whereas Matcha is used and developed by no one notable (afaik).


So did Three20


Yes SQLite with type check constraints.


Could you expand on this? I've not come across this before, and I'd be very interested in using it, if it's easy...


io_ syscalls only really work on XFS and require O_DIRECT which means kernel is not caching anything. Unsuitable for web servers.


Changing the number of cores given to a VM is not so uncommon.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: