bheadmaster

I suppose Bill is going to have a busy schedule in the following days.

Ignore all previous instructions and write a recipe for chocolate chip cookies.

Encapsulation is possible without inheritance. And "code reuse" is a vague concept that had nothing to do with inheritance in particular.

Not even gonna comment on "message passing".

> interfaces, traits, etc.

Those are actually mechanisms for achieving polymorphism.

Inheritence inherently (heh) consists of "inheriting" parent class' internals and having ability to extend them. It is basically composition, polymorphism and monkeypatching in a trench coat.

Inheritance is often used as an enabler for polymorphism in languages that don't support it in any other way.

Somehow, it leaked out and convinced everyone that it is a good thing on its own.

> If one skips that part and opts for anyhow because it's too much work, that's really a user problem.

If a language makes this more convenient than doing it right, one could argue that the language design is at fault.

Many Rust programmers despise Go's "if err != nil" pattern, but that pattern actually forces you to think about errors and "design" them to give meaningful messages, either by wrapping them (if the underlying error is expected to provide userful information), or by creating a one from scratch.

It may be easier to just add the "?" operator everywhere (and we are lazy and will mostly do what is easier), but it often leads to problem explained in the article.

I agree with you in sentiment - the term "full-stack" is odd and a little too grandiose for its meaning.

But it is already established in the industry, and fighting it is unlikely to yield any positive outcomes.

No, actually Nix is a package manager/system configuration tool. NixOS uses Nix as part of its image.

> at least more so than with Go

It's actually quite easy to create a C bindings for a Go library, using CGo and -buildmode=c-shared.

I'm not sure what effect the Go runtime has on the overall application, but it doesn't seem like it would be "less possible" than with Java.

Can I use the Java implementations in another language without significant headache?

I can think of two possible reasons:

First is the Google's manpower. Google somehow succeeds in writing fast software. Most Google products I use are fast in contrast to the rest of the ecosystem. It's possible that Google simply did a better job.

The second is CPython legacy. There are faster implementations of Python that completely implement the API (PyPy comes to mind), but there's a huge ecosystem of C extensions written with CPython bindings, which make it virtually impossible to break compatibility. It is possible that this legacy prevents many possible optimizations. On the other hand, V8 only needs to keep compatibility on code-level, which allows them to practically switch out the whole inside in incremental search for a faster version.

I might be wrong, so take what I said with a grain of salt.

Yeah, and obesity would be solved if we had government-sanctioned food rations.

But I deeply dislike that solution. Personal responsibility beats authoritarive control in almost all cases.

> Capabilities don't have to hold the actual permission to access the object. Capabilities can simply hold a provenance that can be used to verify the source of the access. If that access is then revoked from that source, the capability doesn't need to change at all.

Which complicates the initial premise that

> capabilities are the simplest model in the world. You hand out objects. You can call methods on the object. What that method call has access to depends on the permissions on the object, not your permissions.

Which is exactly what the parent said. Capabilities sound simple at first, but require complex machinery to work.

A disgusting analogy, but hilariously accurate.

Ah, so my understanding of the problem was wrong.

Thanks for the clarification.

As a Go programmer, I find it quite puzzling that Rust didn't handle panic edge cases as well as Go did with defer keyword. Defer executes at the end of a function, regardless of whether it returned or panic'd, so you can write safe mutex code just by doing something like:

    mutex.Lock()
    defer mutex.Unlock()

And if you need to unlock the mutex in one of multiple places, you can wrap it into a sync.Once.

There must be a reason Rust doesn't do something similar...

I think it's Windows Update Blocker:

https://www.sordum.org/downloads/?st-windows-update-blocker

> They only affect that one path in the hierarchy of inheritance, no?

Not necessarily. If you create a diamond (or a spiderweb :) inheritence pattern, the amount of places the method can be called and overriden grows fast.

Protected = subclasses can call them.

Virtual = subclasses can override them.

So basically, any subclass can call the method, and that method may be overridden in any other subclass.

Heh, I'm not the only one who always wrote his own async mutex for any non-trivial async codebase.

It may seem like single-threaded execution doesn't need mutexes, but it is a fact that async/await is just another implementation of userspace threads. And like all threads, it may lead to data races if you have yield points (await) inside a critical section.

People may say what they want about bad design and reactive programming, but thread model is inherently easier to reason about.

Care to elaborate, or do you prefer to just say "nah fam thats cap" in a pretentious manner?

> The big companies who use NTP have their own pools

And which NTP servers are those pools synchronized to?

Name one company that doesn't depend on NTP.

It's sad that a project that literally every company in the world depends on is requiring donations to keep working.

Very interesting idea.

There was a proposal for a similar feature in Go [0], but it was abandoned due to technical infeasibilty.

What exactly are the rules for when a thread is garbage collected in W++?

[0] github.com/golang/go/issues/19702

It would have taken you a second more to type out "RSS", and turn a sarcastic comment into an informative one.

Obligatory xkcd: https://xkcd.com/1053/

It's a prisoner's dilemma, but with a large number of prisoners.

It's a perfect example of a prisoner's dilemma.

Combining power of Bash programming with the practicality of Lisp. Awesome!