jasonpbecker

Julia was designed to unsettle a creeping set of python in the domain of Perl, C++, and Matlab in scientific computing and various quant analysis that’s pretty distant, IMO, from what industry data engineering, ML, and analytics work was doing.

As an R user who can't stand working in Python, where Elixir I think has the most potential is not the data science part but data engineering. The whole world of ELT/ETL pipeline and workflow tools written in Python is a mess IMO, and Broadway/Flow + Ecto + what's going on with Explorer etc I think can quickly replace a whole mess of python/scala/EMR type workflows in a language and environment that feels way better suited to the problem space, in my experience.

Flow/Broadway + how nice Ecto is already had me thinking, "Elixir is super interesting for data engineering." Explorer and Livebook have me thinking, "Elixir has the best shot at unseating Python."

My only quibble with this review is the USB-A port thing. 6 devices is a lot, but even if that were the real number, if the problem is the type-C connector, you can buy very inexpensive cables or even "caps" (like $5 maybe each) to get your USB-A device into a type C port. This is a thing on your desk, so there's no reason not to have it just plugged in all the time with a new, inexpensive cable, or have the cap on the end of your existing cable.

I think the use cases in this announcement are well-laid out. There's not _a ton_ that I think fits well for these container apps, but pganalyze or New Relic monitoring etc are great examples. Some of this stuff being just _a little bit easier_ to maintain and manage is a big help to smaller teams.

I am looking forward to reading this but I need to point out that section 1.3 Ignorance is both interesting and necessary. What 1.3 basically outlines is, "I used R for a year, but the way I used R is very different than what most R people use R for."

Neither of these things are actually deprecated; both remain far more stable than any web framework.

We use Jenkins for essentially this right now, and it works fine (especially if you have someone who knows Jenkins already).

The tone of this article is bizarre, ignoring the fact that Apple is implementing an ISO standard. It's interesting that states interpreted this conversation as a procurement conversation, since it's not clear the government is being asked to buy anything but instead to see where they are on the mDL standard and whether they'd be interested in participating in Apple's early phase release of support for that standard.

The information is useful, but the whole framing is very strange and conspiratorial that's not supported by the emails or the facts.

For what it's worth, this was hastily written as I was thinking about what was happening at Basecamp. I would agree that it's very important to ask the questions you're asking-- that's why I added the final bullet. It wasn't the set of issues that were top of mind for me in the context of what was happening at BC, but I think they are critical, political questions that companies should ask.

I'm glad you enjoyed my post.

psql is easily one of my favorite tools. What makes the CLI "horrible" in your mind?

Also, database/schema/tables is great when doing things like multi-tenancy where you split customers by schema (which also makes horizontal scaling super easy if needed).

I just wanted to jump in and say as a sufferer of KC with pretty nasty scarring, scleral lenses were a life changer.

Thanks! This is helpful context, and supports my notion.

> With the release of Apache Arrow 3.0.0 there are many breaking changes in the Rust implementation and as a result it has been necessary to comment out much of the code in this repository and gradually get each Rust module working again with the 3.0.0 release.

This appears to be an issue with Arrows implementation hitting a new major version and the Rust libraries not yet being compatible with the newest versions of Arrow. That's not something specific to the Rust ecosystem. It's not like a new version of Rust broke this project.

But even if it had, maintenance is always hard and the health of a project is better measured by how long it takes to be working with new, major, stable versions after widespread community adoption of those new, major, stable versions.

I don't know if Arrow 3.0 is the most commonly used implementation-- it may not have even reached that milestone.

Especially since he references the Metro section... which is exactly that.

Fixed the typo. Thanks!

I sounds to me like he wants [micro.blog](https://www.micro.blog) which is what I use for my site [micro.json.blog](https://micro.json.blog). It's Hugo under the hood, but with a human-focus for the interface that allows you to ignore Hugo if you want and some nice social-like features.

* Edited typo in link

I remember these days when it helpfully pre-filled in Bronson as my probable location as a freshman. That was back when you could list all your courses and sections, which was incredibly helpful to find people to complain about Math 17 problem sets.

That assumes a very OO mindset. method(object, args)/function(data, parameters) works better in other languages, and IDEs can handle this quite well without dot syntax.

Which goes to your point-- form follows function, in syntax as with many other things.

Actually, pensions are paid for by returns to investing funds, not the next generation-- at least that was the idea. The problem is that:

1. Governments don't put even the actuarially required amounts into pension funds that assume 7-9% rates of return on fund investments. 2. Governments have been slow to adjust their expectations on returns, since 7-9% is far less achievable than it was in the 80s and 90s when interest rates were much higher.

Permanent low interest rates, economic downturns, and underfunding pension funds together have created an untenable environment. The cash isn't there in many municipal and state pension funds, and earning that much in returns is laughably difficult or requires an inordinate amount of payments now.

Now, it's absolutely true that the USPS is being held to a ridiculous and overcorrected standard in this case. But it's not the case that our current pension obligations, in many of these local and state retirement funds, can be paid for through current employee cash receipts.

That's true that most people don't have an RSS reader. It's also true that:

1. Most people don't want your newsletter in their inbox. 2. Most people still find content on social media. 3. RSS _as a technology_ can be used to syndicate to both newsletters and social media.

That's why I think POSSE[^1] is the right, powerful concept.

On "not-completely-public" content-- I don't think that this post, and most of the "leave Twitter/Facebook" posts are directed at the small number of private accounts-- private accounts don't have the same discovery problem. The exception is if you're talking about "not-completely-public" for the purposes of monetization. To that I say: 1. Twitter doesn't solve that; 2. That's a completely different problem; 3. A blog, syndicated to social media, is still probably the best tool to enable new people to discover your content.

Any number of mechanisms, whether Patreon, Locals, Substack, Mailchimp, Memberful, Github Donations, and on and on may make sense for monetization. Wordpress and Tumblr also have built in mechanisms for monetization. But people aren't using Twitter for gated content that folks pay for-- that's just moving the goal posts.

[^1]: https://indieweb.org/POSSE

Writing blogs, and writing response to blogs, is a significantly better mechanism for most conversation on the web. Short posts, and replies, have all the problems that comments have had all along.

Still, short posts are great, and represent probably 90% of my own blogging. Webmentions/ActivityPub are great starts to getting all of this tied together better.

Kind of silly to insist on a newsletter versus a blog and direct folks to a $30 a month service. You can get a free blog on Tumblr or Wordpress.org. You can get one for $5 at somewhere like Micro.blog. There's plenty of ways to setup a personal blog that works well for both long posts and short posts. All of those have mechanisms to crosspost to social media or turn into a newsletter, if you want. But the focus on that solution is silly-- the open web is here, it's great, and blogs are a solid technology. RSS works well and makes it easy to syndicate all over.

I am personally quite happy using Micro.blog for my blog [micro.json.blog](https://micro.json.blog). It's hosted Hugo (which is what I used for my blog before) setup with a micropub service already and hooked into most of the tech and standards coming through the Indieweb movement.

Blogs are the answer to twitter. Newsletters are just a potential answer to monetization for a limited set of folks.

Most apps I use that have free trials implement it as a one time, in app purchase for $0. This doesn't have the subscription implication or the auto-charge, and has been entirely acceptable under the rules.

Honestly, sounds like micro.blog and how I use it. Most importantly, micro.blog uses Micropub, an existing W3C standard API for blogging which is why things like Drafts, iAWriter, MarsEdit etc can all support it.

Don’t get me wrong, this is a very cool project and it looks like you’ve done a great job. I would recommend looking into Micropub support though rather than role your own API. The IndieWeb group has worked hard and built up a lot of easy to use and powerful standards around this stuff.

Moving up to a major version (1.0) implies there could have been breaking changes if you follow semver. And including something like `unnest_legacy()` is helpful for people making the transition.

Just like `stringsAsFactors=FALSE` happened on a transition from 3.x to 4.x, because it is breaking, dplyr 1.0 had breaking changes.

I’ve been using this as a part of my Setapp subscription and loving it. It’s the only tool that has replaced DBeaver (which is still more powerful, but I hate the interface).

In general, I think there should be a high burden for most folks on whether custom code should be permitted in these cases. I have absolutely seen the same, and this almost always comes after someone makes a reasonable decision to go with COTS, followed by new folks in the role abandoning that rationale for that commitment and companies not knowing how to tell customers "no" or even more importantly "We don't solve that problem, but we're happy to support ways for our system to work with something you procure or build that _does_ solve that problem."

I think a lot of this advice does not apply widely outside of the federal government. For example, I sell COTS software to school districts. There are 15,000 jurisdictions in the US that operate autonomously, but to achieve very similar goals and with very similar operation. While there are differences in state law that can be important, there's far more in common across school districts than not.

To pick on one part of the bureaucracy, if you're the Department of Health and Human Services in the US, there may only be one of you, with pretty unique requirements that change when the law or regulations change. If you're a state agency who largely implements federal programs, there may only be 50 of you. Yeah, that's a market, but a pretty small one and more likely to have meaningful quirks. But a lot of the US is not like this-- school districts, municipal and county government, etc would do pretty poorly to follow some parts of these guidelines, and quite well served to follow others.

With a document like this, I feel like it's important to state the audience and some assumptions up front. They try to do this with some basic definitions, but I've too often seen someone take a document like this to justify maintaining a custom built municipal accounting system on an AS400 that three people in their sixties know how to maintain, as though there isn't a very robust COTS accounting system market for municipalities.