carllerche

Help normalize saying no? As an OSS maintainer, the sense of entitlement many have is quite frustrating. After years in OSS, I have built up a thick skin and am fine saying no, but many aren't.

I 100% agree with this. It also is 100% OK to fork aggressively and patch yourself.

You are very confidently incorrect. So incorrect, it is hard to even start correcting you.

* Inflation is not caused by "putting your money somewhere" What on earth. * At a high level, inflation is caused by either "too much money chasing too few goods" and/or the cost of producing the goods rising. Money supply can increase without causing inflation if the supply of goods can also increase. In short, the supply of money can increase without causing inflation if productivity rises to match it. * Most people do not "put money" in loans what are you even talking about there? * Bank loans do not automatically increase the supply of money. When a loan is taken out, it is (mostly) deposited to another bank, resulting in a net-zero change in money. Increasing the supply of money requires the federal reserve to take steps.

I doubt it. Eating healthy is already cheap and easy (rice & legumes as a base, fresh or frozen veggies based on what is cheapest at the time). It just doesn’t taste as good and gets boring fast.

I respect that some prefer just to use SQL, but that isn't where most stand.

Also, instead of a reactionary "all ORMs are trash," where ORM probably means different things to different people, maybe you could provide some value to the conversation by providing specific points and/or arguments supporting your feelings about ORMs. At the very least, you could provide some citation to an article that does the summarization.

It happens in the US with how fed, state taxes interact with social security and Medicare (income capped)

The easy solution is to tax vacancy at a rate that makes this strategy not profitable.

IMO corporate ownership isn't bad as corporations rent housing to individuals who can't afford mortgages. Let's say corporations are 100% banned from the housing market. 85% of Americans cannot qualify for a mortgage, where would they live?

Good thing this would have no impact on home values. Hedge funds getting involved is a symptom, not a cause. Hedge funds buy properties *because* home values go up due to limited supply. The only thing that can lower housing prices is a dramatic increase in supply.

The issue here is that, after M110, there is little the police can do to prevent *public* usage of hard drugs like fentanyl. Drug addicts will be smoking fent in front of a K-5 school and all the police can do is fine them. There is more enforcement of public alcohol consumption than fent / meth.

It isn't a question of backwards compatibility, it is just way easier to iterate / evolve in a crate than it is in stdlib.

For example, Tokio has the concept of "unstable" features, which have stronger stability guarantees than Rust nightly. First, you can use them with the stable rust compiler, second we guarantee that unstable features will not break across patch releases. This may seem small, but it lets us experiment with new functionality and get real world usage. Many of our users cannot use Rust nightly but can use Tokio unstable features.

Can you elaborate on "heavy weight"? Tokio lets you opt-in to only what you need via feature flags. This lets you use a small subset of the lines of code & transitive deps.

Here is the PR: https://github.com/rust-lang/futures-rs/pull/2551

Yield = wake the `waker_ref`. Avoiding the yield would be clone().wake().

That said, "poll immediately" isn't actually a thing nor was it ever a thing except in incorrect implementations.

It wouldn’t be too hard. The trickiest bit would be putting together a consistent API.

It wouldn’t be too hard to tell it apart. A yield is defined as the task waking itself vs something else waking it. The yield methods already do this.

I don't think it is an issue w/ the pre-emption code. I believe FuturesUnordered is just doing the wrong thing: not respecting yields.

IMO FuturesUnordered should stop executing futures when it sees a "yield". An explicit yield signals control should be returned to the runtime. FuturesUnordered does not respect this.

Tokio author here. Generally speaking, I recommend strongly against using FuturesUnordered unless you know all the pitfalls. We are working on an alternative utility that should hopefully avoid the issues described here and others: https://github.com/tokio-rs/tokio/pull/4335

Would love a real GUI but we have no design talent and stuck with something simpler.

It does not have a hard dependency to Tokio. Any runtime can use tracing to emit the necessary instrumentation to work with Tokio Console.

We would love a web view but don’t have any ability to design or much experience with building web apps, so we stuck with a terminal UI.

Yeah, it is decoupled from Tokio. Tokio emits instrumentation via the `tracing` crate. Tokio Console just listens to the tracing events. Any runtime that emits the same events can be used with Tokio Console. This is the tracking issue: https://github.com/tokio-rs/console/issues/130

Not too many now. What it really needs is real usage to find any potential limitations.

Dumping to a file for later analysis is on the roadmap.

It is fairly subtle and mostly an implementation detail. In Rust, the concept of "polling tasks" was very exposed before the async/await keywords were introduced, so the lingo kind of stuck. There is an argument that we should move away from that lingo now that it is mostly hidden as an implementation detail, but we haven't yet.

The current release of `tracing` includes the predecessor of valuable (https://docs.rs/tracing-core/latest/tracing_core/span/struct...). Valuable extracts this functionality and improves on it, but hasn't quite made its way back into tracing yet. I expect that it will be included in upcoming releases (I know eliza has been poking me to release valuable and get it in tracing, I probably should get on that!)

Also, thanks for the thought re: digit precision. I am tracking it here: https://github.com/tokio-rs/console/issues/224

This first release is geared primarily towards local debugging. That said, it is designed to be able to enable / disable instrumentation at runtime and it will be able to support connecting to a process in production, enable the instrumentation, and debug there.

Right now, we wanted to get the first release out and start getting people using it and collect feedback to help prioritize future development.

I'll answer the polling question. The Tokio runtime (and async rust in general) works a bit differently than other async runtimes like node. With node, callbacks are provided and executed when an OS event is received. With Tokio, there are no callbacks. Instead, async logic is organized in terms of tasks (kind of like async green threads). When the task is blocked on external events, it goes into a waiting state. When external OS events are received, the task is scheduled by the runtime and eventually the runtime "polls" it. Because the poll happens in response to an OS event, most times, the poll results in the task making progress. Sometimes there are false positive polls.

This page goes into a bit more depth and shows an example of how one would implement a (very simple) runtime/executor: https://tokio.rs/tokio/tutorial/async

Exactly, this is the first release of Tokio Console. We will keep adding functionality over time, which will help inform the APIs in Tokio to better provide the necessary instrumentation.

I expect the new APIs like the task builder will stabilize (no longer require the `tokio_unstable` flag) over the course of 2022.