remon

I definitely know what "A" and "model" means.

Totally worth an article.

HN is inundated with posts announcing paper thin abstractions on top of existing technology or utilities that just move the goalpost of what you knowledge you need to be effective. It's a weird trend that seems almost entirely motivated by people wanting open source projects in their resume, or seek funding if its a startup.

Millions? His work? Come on now.

I've read the introduction and descriptions two times now and I still don't understand what this adds to the proceedings. It appears to be an extremely thin abstraction over object storage solutions rather than an actual DB which the name and their texts imply.

The argument you'd think at least one reviewer would mention ;)

If we lower the bar on papers getting published even further it'd be on the floor. Even with a simple physics argument you can immediately disprove the claim. Human brains have a known amount of compute (as in, we are at most an order of magnitude or two off) within a specific volume. We are already capable of that amount of compute, we just don't have a way to use that compete for AGI yet (and THAT may be hard or impossible but it's certainly not energy resource constrained). We also know the abilities this paper claims are not possible to achieve can be achieved by pretty much every human being within years of being born.

How they managed to massage white supremacy and sexism into this is...well...wow.

Netflix should make a documentary on why people in this modern day and age still gravitate towards Twitter-esque social media platforms. It has been shown over and over that they make people less happy, less productive, more stressed and (ironically) less social.

Managing people is such a wildly different skillset compared to engineering that it still puzzles me the former is the assumed "next step" for an engineer. Managing engineers is a facilitating job and should be viewed (and paid) as such. Companies valuing a principle engineer lower than the person managing the day to day of that engineer is a crazy bit of corporate legacy.

Content is great but boy that site is not helping getting that content across.

That site has incredibly annoying scrolling behavior. Scrolling up instantly pulls down the header again.

solution > problem

Ah! That's the bit of context I was lacking. Thanks

What problem/niche is this language a solution/fit for? I've been clicking around for 30 minutes now and have yet to find a defining feature that makes it (significantly) more productive and/or robust than Java or C#.

Every time I see a post like this and read the comments I'm more convinced that there's a division between programming language enthusiasts and developers and only the former group cares about any of this.

Sort of a tangent but I feel it's a little troublesome that the Supreme Court can deny appeals without even a paragraph of motivation. Clearly they need to filter based on some criteria or another so denying the appeal is fine. But I feel that shouldn't ever occur without some sort of reason as to why. I enjoy listening to the oral arguments for certain cases in the USSC (https://www.supremecourt.gov/oral_arguments/argument_audio/2..., it's interesting) and I can't help but feel that a lot of the cases that are accepted are of somewhat less importance than "can an effective monopoly be forced into less monopolistic business practices" or some variation of that.

There's plenty of good reasons to charge different amounts for the same services. There's nothing immoral about that. People can simply say no to making the purchase for the price offered to them. Again, this is completely besides the point of the Apple case.

In Apple's case there are no reasonable alternatives and no practical way to say "no" to the service if you want any business at all. That and that alone should be the issue at hand. What Apple is doing should not be legal on that ground. Either they allow third party stores, or they adjust their cut to a level that can reasonably argued is aligned with the value they're adding to the publisher of that app or service. Now they're in "we can charge whatever because we're the only route to getting your product on Apple products" land, and that's just not where we want to be.

And yes, loan sharks are legitimate businessmen in the US. Not most other places mind you because *there's legislation preventing it*. You're conflating "can" and "should" consistently, much like most other people in this thread. It's just not a moral business. Much like gambling isn't, selling addictive unhealthy products isn't, and so on. It's legal though, and if you want to change it vote for people that can turn that into law. Welcome to democracy.

Are you being intentionally obtuse? Those two things are, again, completely unrelated. As a person I do feel capitalism in its current form results in demonstrably unethical practices, and I do think Apple overcharges for the value they bring to the table in the specific case of their 30% cut. That's a subjective ethical and moral assessment of Apple as a company.

But that's not the topic at hand, and strawmanning one problem by pulling in another is just lazy. Ruling on this will not just affect Apple but any company with a similar modus operandi in the future, including smaller more ethical companies. Why people have trouble keeping legislative challenges (what you can do) and moral challenges (what you should do) apart is beyond me. You can have more than one opinion in your head at the same time.

This is exactly the wrong argument to make and a perfect example of why internet discussion is becoming harder.

None of what you said matters. It does not matter how much money a company makes or if you personally think they're charging too much for a service. They're allowed to. The open question is if they're in a position where there's no reasonable alternative for developers and/or consumers which you can make a strong case for. That line of argument would not be affected at all by how much money Apple makes, their cut or if they're spending their money in a socially productive way.

The fact that this is the second highest upvoted comment is a rather sad datapoint on issues related to internet based conversation where opinions consistently trump fact or reason.

That's just working around an artificially and unnecessarily introduced constraint. There's little zero upside to doing it this way. It's not even more convenient since it incurs pretty heavy refactor costs for even small changes.

Exposing your schema directly is an anti-pattern for good reasons. Don't do this. You want to be able to change a contract/interface/API independently of your persistence strategy.

Your examples are very reasonable, and somewhat at odds if what the author is advising I think. As you say the advice is vague but I suspect it's also just fundamentally flawed.

There are very few real world scenarios where "just make it work" is a good approach to tackle engineering problems that require senior developers (read; developers with extensive experience in the related problem domain) in the first place.

My approach, which is I suspect it similar to what you're describing, is to define functional contracts first. Making them work is actually pretty low on the priority list, since that's consistently also the easiest thing to get right.

The hard part is correctly defining expected behaviour, interfaces and so on. In your example the hard part is constructing an interface/API for a payment processor that satisfies your business needs on the consuming side and is reasonably implementable for the relevant major payment providers. Actually implementing one, the making it work bit, is just not where the senior expertise adds value.

Unless, of course, you enjoy shipping glorified POCs to your customers because your stakeholders "saw it work" and blissfully ignored the metric tons of tech debts you just introduced, not to mention a skewed perception of the amount of effort needed for a that deliverable.

As opposed to a 2D Game Engine in Kotlin Working with Kotlin? Why?!?

I could not agree more. And that's coming from someone that converted to almost completely async/reactive/flux-y code. Reactive frameworks, almost by necessity, force developers to write less maintainable and readable code (objective fact, not an opinion). Lightweight threading is a significantly better approach to the same problem space.

I quite like this approach to system spec languages. It feels a bit more modern than the rather unwieldy TLA+. Can someone explain how a spec language can exist without sets as a first class datatype though? (admittedly I only had time for a cursory glance at Fault).

Also had a quick look at the codebase and was positively surpised by it being Golang. Oh and just in case the author has a peek at this thread; the only source file I opened had this interesting typo :D "NewProcesser() *Processor"

A particularly low value contribution. The title is a copy of the article's title and pretty accurately captures its content. This is being difficult for the sake of being difficult.

Subscribe-on-update databases are, almost by definition, problematic to use at scale as a generic storage solution. The fundamental problem is that they do not solve many real world problems efficiently enough to warrant the significantly higher running cost. Of course there are exceptions but it'll be hard to launch a MongoDB type of product that uses a subscription only model (see Firebase RTDB and its problems and lack of adoption in this space)

The reason developers gravitate towards subscription/rx based paradigms is because it results in very clean architecture and code. Unfortunately it comes at a cost which increases rather than decreases per client/user when volume increases. Some companies or projects can absorb that cost but not all, and typically less so when the project or its userbase grows.

A subscription based model will do work whenever data changes for each subscriber whereas more traditional pull based architectures only do work when a client specifically needs the data. This can be mitigated to some extent by being micromanaging subscriptions but that kills most of the value of the model.

There are also plenty of issues with this model if multiple clients are allowed to write to the same data which every single example project seems to try and do. There's a reason master-master updates, consensus algorithms and CRDTs all come at significant cost. It's usually hard. And when it's easy you probably don't need it subscribe-on-update in the first place.

How is this different from Firebase RTDB? And perhaps more importantly, does it address the scalability and consistency issues associated with Firebase RTDB? Google introduced Firestore to Firebase specifically because RTDB has limited usability for larger real world applications that go beyond "sync device state to DB".

Even the offline first paradigm is fundamentally flawed in general and certainly when it comes to offline data manipulation. Either you can afford to mutate your data on the local device and sync it when possible, in which case you clearly don't need subscriptions to real-time mutations of remote data because within that scope you are the source of truth. Or, you're interested in mutations of real-time data from multiple clients in which case you need to deal with conflict resolution (mutually exclusive changes of data) which is not reliably possible with this model and scalability (linear increase in pub/sub * increasing query cost = exponential scaling).

Are there any large projects or companies that currently have this in production?

"Detailed Agenda for a Domain-Driven Design Design-Level Event Storming". That title is worth a lot of consultant scrabble points.