iamed2

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).

The terraform provider has returned

Many repos have disappeared, including: * https://github.com/confluentinc/confluent-kafka-python * https://github.com/confluentinc/terraform-provider-confluent * https://github.com/confluentinc/cp-ansible * https://github.com/confluentinc/cli

It's important to resolve changes to the package environment as a whole. Pip doesn't really do this, and as of a few years ago didn't even resolve multiple CLI-specified packages together, and this causes major compatibility and consistency issues.

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.

Medications for anxiety and depression can cause brain fog and fatigue.

I still prefer to use Julia, but this is a good summary of the problems that affect me personally as an experienced user (although I do like dynamic typing for most of the work I do).

Invenia's approach to interface testing ("Development with Interface Packages" on our blog) does some of the things you suggest as a standard of practice, by providing tools to check correctness that implementers can use as part of package tests. ChainRulesTestUtils.jl is a decent example (although this one doesn't come with fake test types). I think this is typically good enough, and only struggles with interface implementations with significant side effects.

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!

I don't know if it's related at all to the decline, but "Line Goes Up" was released on YouTube at the exact peak.

I've only ever engaged on Twitter when companies do not provide an avenue for direct customer support in private, but this has become more and more important over the years. Twitter provides a platform for public shaming; if the company directs you to a private channel and doesn't respond effectively there, you can report back publicly that the company has failed to respond. The situation may be changing, but in the past this has resulted in internal escalation and my problem was resolved in a way that was not possible through official private channels (if those even existed).

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.

I'm interested in the shift in terminology. Previous coverage has referred to them as a software company or device manufacturer, but this round is referring to them as "hackers", which seems like a framing McDonald's would benefit from in lawsuit proceedings.

I'd be interested to know what size of team the Core Team wants to maintain and whether there are differentiated roles within the team.

Yes, this suggestion effectively addresses the biggest problem with the flow described in the linked post. Accidentally clobbering changes in the main branch used to be one of the top sources of bugs when I started at my current job (incidentally, switching to a rebase workflow helped with this, though I'm sure that wasn't the only route we could have taken).

There are two statements here regarding things that have happened:

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

Same with me with 1Password 4 on Windows, via Dropbox as well

You can use FFTW.jl with MKL: https://github.com/JuliaMath/FFTW.jl#mkl

This is evidently rebranded Google+, as the "See more features" link (at time of comment) points to the feature comparison chart for Google+

What's an example of a codebase where _Generic has had a notable positive impact?

I can't fault you for switching to something more battle-tested, but did you file issues for the LibPQ.jl issues you encountered? I wrote and maintain the package and we (and others) use it in production so bug reports are much appreciated.

This just isn't true. There's a lot of tooling nowadays that provides IDE-like features in text editors, or via command-line tuning. And different people work differently. Where some people use IDEs, others never leave the terminal and just use e.g. vim/emacs, a build system, and a debugger.

I have not seen one, but I would really like to! It's one thing I envy about some other open-source language projects.

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.

Dijkstra's write-up is full of subjective aesthetic judgements that certain things are ugly. I personally don't find `1:0` for an empty sequence to be ugly, and I do find using `1:1` to refer to an empty sequence and `1:2` to refer to the sequence `{1}` to be ugly. I would encourage everyone to read over his reasoning and see if you agree with his aesthetic judgements.

Smaller, 32 TiB.

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

In response to some of the complaints about Aurora PostgreSQL in this thread:

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.

One thing that outsiders miss when considering MATLAB is the incredible debugging workflow. With this release and the Juno integration, we finally have the same experience for Julia! As a developer who used to use MATLAB and now uses Julia every day I am very excited to make use of this tool.

Azure Pipelines was the first one, and would probably have a better service overall if they had better documentation and supported more languages/environments.

it requires an elastic IP which slows launch of lambdas since they have to connect to VPC

Do you have any other info/links related to this?

This is truly an important issue. Right now, every interface represents something that needs to be documented by the author. The AbstractArray and Iteration interfaces are well-documented, but the AbstractDict interface isn't. I believe that documentation for an interface is enough, but I also don't think enough people will take the time to write it. So I agree there should be a technical solution.

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!

There's an overview here: https://docs.julialang.org/en/v1.0.0/devdocs/isbitsunionarra...

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

Similar, except for this key difference:

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.

We had a similar task a year ago in a Python codebase and we ended up building a function in Rust for it. Rust's splitting iterators over `&str` return references to the same data as their own `&str`s, which is a huge performance win. We would filter the split strings and conditionally store them in a `HashMap<&str, &str>`, which we later drained, both automatically freeing memory behind the scenes as able. We also shaved off a lot of time in some cases by avoiding parsing and comparing strings in cases where we had fixed-length integers (e.g., UNIX timestamps in a known range).