abacate

Original post: https://archive.is/wNLqY

Updated version: https://archive.is/TpsUW

I believe you are understanding the opposite of what was said.

I understood it as "there cannot be trust anymore" - mostly because different people are at risk of becoming a victim in different ways: from a crime itself, or from being falsely accused of committing a crime.

Individuals will act in a way that makes sense for them. Asking them to "just trust more" does not solve the problem - it needs to be addressed at the root (education, communities), which goes far beyond the individual level.

Trying to convince people usually makes any resistance worse.

Using it, solving problems with it, and building a real community around it tend to make a much greater impact in the long run.

nix, which has its own share of problems.

Care to elaborate?

Christoph seems not to have actually looked at the patch before rejecting it.

I had the same impression as well, in particular due to his wording:

"No rust code in kernel/dma, please"

When, in fact, the code is in "rust/kernel/dma" not "kernel/dma".

It seems like he missed this and then doubled down on his stance when questioned.

The reason is entirely technical and I think it has been formulated clearly [..]

He clearly expressed a technical opinion based on his own beliefs, and that’s all. There was no reasoning.

He did not even acknowledge the fact that it is going to be maintained separately from the actual generic kernel code (rust/kernel/dma vs kernel/dma).

Anyone can easily formulate a sentence that seems coherent and correct, but it can be proven completely false in 15 seconds with actual data.

IOW: just because someone calls it a technical argument it doesn’t make it one.

This is a matter of opinion - specifically, the opinion of a single person.

If there's a single most reason why Rust-in-Linux will fail it is going to be because of the immaturity and entitlement of individuals in Rust community.

Indeed there was immaturity from several individuals.

One question: if you act immaturely towards someone and they react immaturely, who's fault is it? The person who reacted or you?

I do not believe there is a widespread issue of entitlement: if you follow the discussions on the ML and observe how the R4L project has progressed so far, the only "entitlement" that individuals in the R4L project may seem to have in common is the desire to be treated with respect and for discussions to focus on technical arguments.

For me, this is the bare minimum to be expected.

There is a large difference between "I do not think this is a good idea" vs "do not do this", in particular given the position Hellwig has in the kernel as a listed maintainer of the DMA mapping helpers.

No single technical reason was given besides a non-specific opinion on the "messiness" of multi-language projects.

If you search for "concurrent hash table <language>" or "concurrent map <language>" (being <language> Rust or C++) you get a number of open source libraries written using different techniques. I consider "exotic" a matter of opinion.

You can easily write a concurrent hash table in C++ or Rust. I fail to understand your point.

I read this article and the original one.

I don't see any reasoning besides "I think it's not really needed".

The reasoning in the original article is shallow at best, and the presented alternatives are not discussed in the depth I was expecting for an article questioning the whole architectural basis of a very popular IaC stack.

On the second article, I don't see a self critique of the actual points raised during the original article.

The two articles sound much like a collection of statements based on personal opinion.

I see the value in an article like this for starting a discussion but not into taking any sort of conclusion.

I would want this over docker and docker-compose any day.

I've been using docker compose in production for a couple of years now and it adds another layer on top of systemd that is a continuous source of headache, especially during updates.

Podman gets it right: no central daemon, can automatically generate systemd services for a whole pod. Updates are seamless.

This by itself is enough of a reason to me.

It's not the punishment but the likelihood of being punished.

Even if the punishment is not that severe, a high probability of being caught is a much greater deterrent.

I don't see how this reasoning makes any sense: you just need to look at the actual clock time to find out if the alarm went off or not.

For instance: alarm set for 8 AM.

You wake up, look at the clock: if it says 7:59AM or earlier, you woke up before it had a chance to ring. If it says 8:00AM or anything past that, it already went off.

Unless, of course, you have an alarm that does not show you the current time. Otherwise, it's pretty easy to figure out what's happening.

Algebraic effects are going to put OCaml on a next level in terms of expressivity, abstraction and decoupling capabilities of separate tasks. It would be like going from a type system like C, with only concrete types, to parametric polymorphism and/or generics.

Multicore is a very nice addition, but the fact that it is going to be coupled with an effect system is a game changer for the language as a whole.

Any language with a large enough lexical set or enough meta-programming capabilities can be classified as "write-only" from the point of view of non-experienced users. It's the everlasting battle between learning curve and expressiveness.

This looks like someone trying to build a story with snarky comments and funny observations to get audience interested. The parts about C sound amateurish indeed.

I've been using Zim [1] as a knowledge database for around 2 years. I don't like depending on online solutions which may suddenly disappear.

Together with some plugins for managing tasks, git and some script for synchronizing repositories, it has been working great.

There are some limitations on this approach (ie, two persons editing the same page concurrently is a no-no), but for my use-case it works perfectly.

I find it much more intuitive than org-mode, and the fact that it auto-generates a "global" task list based on items spread across the whole notebook makes it much easier to prioritize things.

[1] https://zim-wiki.org/

The queue is a single contention point which will have a considerable overhead unless the work takes a long time to execute (ie, enqueue is infrequent).

This kind of approach is usually not what you want: either you want to spawn threads as new work arrives (when each work unit is independent of each other), or you want to have a static number of threads each doing some predefined work (ideally one per core).

Scheduling pieces of work like this is going to be terrible for cache locality and will probably result in a number of threads waiting for each other and result in underutilization of the available cores.

The only valid options for performance sensitive functions are JS, Python and Go.

I can think of a number of other languages that would probably easily surpass these, especially on latency.

Dumping a big database continuously for any reason (including backups) is a terrible design decision.

As usual, it's not that complicated, and it's not that simple.

The simple solution would be for the network providers to validate the caller ID numbers for its subscribers, but that requires changes to punish the ones that don't do it.

I've worked with telephony for 15 years and I know the big providers do this for most common telecom protocols, but VoIP providers tend to be more lax. But that's where they shouldn't, and the ones that break this shouldn't be allowed on the network.

Please stop talking about Brazil as a single reality. Murder rate is completely different across state lines. And guns play zero role into the causes, as others have already pointed out.

Any serious analysis on USA is done in a per-state basis, and the same applies to Brazil.

I never understand this kind of reasoning. Sure, C++ has exceptions, but you are not forced to use them. Just because you go to a restaurant and they have dessert on the menu it doesn't mean you have an obligation to order it.

In fact, you can easily define a result type templated by your result/error code (similarly to Rust or OCaml/Base) and use it in your whole codebase.

I never use virtual or exceptions in my C++ code, for instance, and I rarely need anything fancy like smart pointers.

Maybe one could argue that the language is too complex and supports too different programming styles, but that doesn't justify when the programmer chooses the worst way to do it: that's on the programmer and not on the language.

C++ template system is too generic (Turing complete), and it is usually the one to blame for the verboseness of error messages.

Something like Concepts would probably make it more like a proper "generics" mechanism and allow better error messages - ie, "this type does not implement EqualityTrait" instead of "signature mismatch <detailed and very verbose function declaration 1> and <detailed and very verbose function declaration 2>".

Despite this, newer g++ versions have better error messages overall - but sometimes you are stuck with an older version of the compiler as well.

The article is indeed interesting when it goes to the GC/allocation part and it's a nice read, but it really gets C++ wrong when talking about values/references. C++ is not "reference oriented language" the same way it is not an object-oriented language.

For instance, what restricts one from doing:

    int blah(myobj a);

    int blah(myobj &a);

The usual argument is efficiency - since "myobj" may be a big and have an expensive copy constructor - and you may happen to see this pattern being commonly used in C++ programs, but restrictions? There are none. C++ even makes it possible to assert coherency with copy/assign constructors, and modern C++ supports the more efficient moving as well.

So, the point is: nothing in the language restricts you from passing things by value. I'd go further an say that blindly passing things by reference is bad practice and detrimental for simple objects - since you now have to consider lifetime/ownership of the reference you passed along, and this will probably complicate an otherwise simple piece of code.

The argument about fields in memory also makes not much sense. How is that different from C++? Keeping references/pointers in structures is possible but not exactly what one needs to do.

Otherwise the article is great I just think it misses the point when comparing to "C and C++", since they are not the same language - even though syntax is similar and there is some level of compatibility.

The idea is interesting, though the results have indeed zero applicability unless a few additional rules are added to the system - like proportion of macro-nutrients (fats/proteins/carbohydrates) and some sensible variability to the meal plans (ie, no point in suggesting "1 gram" of some food source, either you suggest a "portion" or nothing).

Personally, I think it would be easier to start with one's own dietary approach and try to put that into rules, then optimize it using additional guidelines (or removing some rules) instead of starting with something too loosely defined and letting the program choose different sources randomly.

Any micro performance gains from a function call will become rounding errors compared to the extra cost of any arithmetic operation on a dynamically-typed language.

It may be an interesting article for describing how JIT and some late-optimization techniques can produce optimized code given the right optimization preconditions, but I fail to see how the title is supposed to describe the contents of the article.

Last, but not least, performance-sensitive C code tends to be statically linked.

I'd suggest addressing non-English to non-English translations first, which is usually limited in most engines out there compared to translations to/from English.

It does not solve anything, just pushes the problem a little further.

D's const is also transitive, meaning that if something is const, then everything it contains or refers to is also const. If D code has the equivalent of const vector<T*>, then not only is the container treated as const, but the elements are as well.

And that is not necessarily what the programmer wants.

There are a number of uses for a constant vector and non-const objects. Adding "const" in front of "T" should make everything constant, but just assuming everything is constant does not allow one to have non-const objects.

Unless there is a way to override this, it looks like a severe limitation in the language.