51–60 of 102 posts
Earlier quoted context omitted.
Doesn’t microsoft own helm now? Nothing is stopping them rewriting it in rust since it can easily interact with kubernetes via rest api
No. Helm is owned by the CNCF.
“For comparison, last week we caught a significant race condition in another Kubernetes-related project we maintain called Helm (written in Go) that has been there for a year or more, and which passed the race checker for Go. That error would never have escaped the Rust compiler, preventing the bug from ever existing in the first place.” I’ve heard people brag that Haskell is a great language because it’s supposedly…
> One of the biggest ones to point out is that async runtimes are still a bit unclear. There are currently two different options to choose from, each of them with their own tradeoffs and problems. Also, many of the implementation details are tied to specific runtimes, meaning that if you have a dependency that uses one runtime over another, you’ll often be locked into that runtime choice. My understanding of how asyn…
That is the case, but it's super awkward to use. Basically, you cannot await a tokio future on an async-std runtime, or an async-std future on a tokio runtime. You can, however, have both runtimes running at the same time, and use some form of message-passing to bridge them. It's definitely easier to only deal with one runtime. Ideally, we should have some kind of abstraction to allow crates to support both runtimes…
That's really the case for any language where an eventloop is not part of a builtin runtime (like it e.g. is with Javascript or Dart). E.g. in C++ we also have boost asio, libuv, libevent, wagle, seastar,GUI framework eventloops in GTK, QT, etc.
The thing is once you are in async land, nothing is interoperable anymore in most environments. Whether that's ideal or not is a separate discussion.
What I experience however somehow is that Rust users raise a lot more concerns about interoperability than I've seen so far in other ecosystems. I might stem from the fact that those users often never used another native async environment.
I don't believe for one second that it takes just a couple of weeks to an average SE to be proficient in Rust.
It's a bit weird to see "several weeks" of effort being described as a problematic learning curve. At least the blogpost makes it clear that the effort pays out hugely but still, "several weeks" is not rocket surgery. It's not learning Haskell or category theory! ISTM that they're just running with an assumption that most devs wouldn't be professional and committed to this, which strikes me as an unwitting gatekeepin…
Go has a shorter time, and that’s the measuring stick in this area.
“For comparison, last week we caught a significant race condition in another Kubernetes-related project we maintain called Helm (written in Go) that has been there for a year or more, and which passed the race checker for Go. That error would never have escaped the Rust compiler, preventing the bug from ever existing in the first place.” I’ve heard people brag that Haskell is a great language because it’s supposedly…
Earlier quoted context omitted.
CNCF doesn’t “own“ anything afaik. If you look at maintainers list most seem to still belong to deis org which is part of msft now
CNCF hold the copyrights.
> we caught a significant race condition It is a data race, not a race condition. > and which passed the race checker for Go No, it is not. https://github.com/helm/helm/pull/7820#issuecomment-60436062... There is a comment by issue author which is literally a go data race detector warning. Like "WARNING: DATA RACE".
Data races are a kind of race condition, no?