I wonder if this means they migrated away from Honeycomb, which often lists Stripe as a prominent customer (e.g. "HelloFresh, Stripe, Slack, Fender, Vanguard, LaunchDarkly, and many more rely on Honeycomb" in most blog entries).
320 karma · joined March 15, 2013
Doing this correctly can be difficult to get fast, but performance does matter. Resolving Conda environments adds way too much time to CI jobs. The Pkg.jl resolver is pretty great and we never have to wait for resolution. It's my understanding that this was a non-trivial technical problem that went through a few implementation iterations.
Explainability on failure to resolve is a really useful tool that becomes more difficult the more features you add. Pkg.jl has struggled with this in some cases where it hides certain version restrictions (e.g. "by explicit requirement" is rough when your project hasn't set that particular requirement). Lots of people have spent lots of time trying to identify incompatibilities over the years, and we've had to rely on people developing arcane knowledge to interpret resolution failures.
Immutable, cached packages is important for avoiding spending a lot of time downloading. It's very important to completely distinguish different versions/configurations though, i.e. you don't want a configuration setting that affects which code gets put at `~/mypkg/packages/<pkg-version-id>`.
The package source should be reliable/redundant. People will install packages in the course of normal work (automated updates, testing, etc.) and will need an always-on package manager. GitHub has proven not to be reliable enough.
At the same time, an offline mode should be available.
Getting installation configuration options right can be a big value add. I love cargo's feature flag implementation, and even Python now has "extras".
Every package manager eventually regrets not adding a "yank" feature.
Enterprise users will always eventually want to see multiple sources (private and public).
I appreciate when package managers consider the audience for their output and don't output line-by-line progress meters when running in a non-interactive environment.
Querying the package dependency tree is really useful! Both dependants and dependencies, flat and recursive. Even better if there's a library to do this that you can script and experiment with.
One little win could be publishing interface tests like these for Base interfaces in the Test stdlib. I appreciate that the Generic* types are already exposed in the Test stdlib!
IMO the best way to avoid publicly advertising when you've failed a customer is to provide a clear and effective private avenue for complaint resolution. Most people who are looking for a resolution will only resort to social media complaints when they're desperate, either because they can't figure out how to get help or they are being denied help and/or communication.
> the Core Team placing themselves unaccountable to anyone but themselves
> we have been unable to enforce the Rust Code of Conduct to the standards the community expects of us and to the standards we hold ourselves to
It's possible that there were CoC violations that they were not able to moderate, that the actions available to them were limited (e.g., they would have initiated a ban but they were not able to ban a core team member), that a core team member intervened to prevent effective moderation, or that the core team prevented the mod team from being able to access official core team channels in order to moderate.
Seems to be a wide variety of possibilities and leaving the nature of the situation ambiguous* will likely make it difficult for a new mod team. I hope the now-former mod team are open and direct with new or potential mod team members about the environment they're entering.
* I do think it's right for the mod team to not reveal the specifics in public; that would likely provoke targeted harassment and make the situation much worse
I also think Julia would benefit a lot from a list of "we want these but haven't had time for them". People like contributing things they know are desired, and with Julia it's hard to know whether people want or will accept something until you make the PR.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
Aurora PostgreSQL Serverless should be considered a different product with different performance characteristics. We've been experimenting with Aurora PostgreSQL and have encountered the same memory issues mentioned here and elsewhere. It's impossible to autoscale read replicas based on memory usage, and there's no swap for temporary spikes. We haven't yet seen those problems with Aurora PostgreSQL Serverless. There is swap, which handles spikes, and whatever automatic scaling Amazon has implemented adequately deals with increased memory usage (if you're okay with a few terminated connections). I can't comment on the index-related issues, but I do suggest considering this product separately from Aurora PostgreSQL.
Do you have any other info/links related to this?
The main reason this has not been implemented as a language feature is that people are worried about settling on a design that would be impossible to make fast and concise. It is certainly on the designers' radar, and was discussed specifically at JuliaCon 2017 in Jeff Bezanson's talk.
There are some people who plan to attempt a trait system as a package on Julia 1.0. Perhaps this will be successful and we won't need language changes! Stay tuned.
As an aside, I wouldn't take the lack of action as lack of interest. People are interested, but it wasn't prioritized yet. It will get effort and attention!
In terms of the Julia changes that were needed to support this, there were two key PRs:
https://github.com/JuliaLang/julia/pull/20593 https://github.com/JuliaLang/julia/pull/22441
> A substring holds a reference to the entire storage of the string it comes from, not just to the portion it presents, even when there is no other reference to the original string.
Rust's `&str` doesn't do that, since the borrow checker will ensure at compile time that the `&str` reference doesn't live longer than the data it points to. At runtime there is no structural difference between an "original" `&str` and a `&str` pointing to a substring of the original.