Yes, we're anticipating more spiky workloads because of this. Deno Deploy is already designed to handle spikes, but we also have a few additional mitigations in place for Cron. For example, we will limit concurrent dispatches for the same project/user/organization, which may slightly delay the execution of specific cron tasks.
Or add a default randomness factor that makes it run within a certain time (like 60s or 5m) of the target, perhaps with an additional charge to run at the exact time if people have that requirement.
It would be great if that were possible. Git commit signing is something that I would love to see be more commonplace, since it is a key part of a secured code supply chain. At my workplace I lead a project to make commit signing mandatory on our git repos, which I wrote about here: https://eos.arista.com/commit-signing-with-git-at-enterprise... .
One of the painful aspects of this was using the gpg tools. They are products of an earlier age and don't display helpful error messages, nor do they display easy to parse messages. I realize that Sequoia doesn't currently have a JSON API, but it looks like one is planned for the future, so that it two thumbs up from me.
> I more often than not suggest moving from Clojure to anything else.
Rewrites are notoriously risky projects, I'm surprised you suggest this the majority of the time.
> you have to trust that the original programmers actually know the language enough to not create a massive disaster
This is my experience, but I've come across many coding disasters and none have been caused by misunderstanding the programming language. All have been due to poor software design or testing.
> Once this happens, you end up in a read-only code situation, and this is a problem because they leave the project with tons of bugs and downright stupid decisions.
Why have you pinned the blame on Clojure? What are the properties of Clojure that cause programs written in it to have so many bugs? Programming languages don't make decisions, let alone stupid ones.
> I joke that I know all 50 Clojure programmers in the US, and sadly, that's not much of an overstatement
This is a massive overstatement. Netflix, Apple, Soundcloud, and Walmart are all using Clojure. I work on a large team of Clojure developers, many of whom are located in the US. The Clojure community is large, healthy and growing. This is not an "esoteric" language.
> If you aren't located in SF, LA, or some other city that attracts talent
I work with Clojure developers all over the world, many in small towns in their respective country. My address hasn't been a factor for any tooling decision I've been a part of, it's a strange (overlooked?) criteria by which to judge technology.
> What are the properties of Clojure that cause programs written in it to have so many bugs?
Well, I can only speak from my own experience, but twice now I've personally seen enthusiastic talent python programmers create clojure projects which 'did all the things':
- used core-async heavily, including blocking channels that are never resolved in the UI.
- massive 'global application state' top level atoms that are mutated arbitrarily throughout the application
- massive complicated one line reduce/map/whatever where people are trying to be clever and reduce the lines of code, because 'fewer lines of code is better'.
I think it's telling when you get a 'walk through' from the person who wrote the code, and they have to stare at it, trying to figure out why it was they needed 10 different channels as they're explaining it.
After thinking about it quite a lot, my conclusion is that I would recommend against clojure for the same reason I would recommend against C: It's easy to mess it up.
Clojure allows you to create very complex applications; and you have all the tools to shoot yourself in the foot.
I don't think I'd tell people to migrate off clojure, but if the opportunity came to work on a new project, I would run away unless at least 50% of the people had actively used it before.
(and by comparison, my experience with a relatively novice team using elixir has been extremely positive; so yes, I do actually think this is a reflection on a clojure itself, not just 'insert any unknown programming language here').
You can write bad code using bad practices in any language. All the points you've made have absolutely nothing to do with Clojure, and are simply bad architecture.
Every language allows you to write complex applications, and shoot yourself in the foot. If I pick up Python tomorrow, and start writing a large application in it, it's pretty much guaranteed I'll make a mess.
Wow, that is a shockingly steep dropoff! If you believe this chart, clojure will be extinct in another year. Could there be some other explanation than that clojure is really in a death spiral, like maybe Indeed has been growing faster in less developed markets or something?
I can’t speak for the others, but at least for Amazon, for every clojure programmer you find, you’ll find 1000 using Java. Sure it’s a big name using it, but it’s only a few teams on a few projects. That’s kind of the point of SOA, it allows the team to do what they want without huge top level decisions on what technologies to adopt or abandon.
I think that's the point. Although Clojure has been adopted by a small cluster of big names it tends to be ignored further down the food chain. Search Indeed.co.uk's API for title:Clojure in London and you'll find 8 jobs compared with 378 for Python. For the UK as a whole it's 19 Clojure to 669 Python.
Python has been around a lot longer than Clojure though, especially if you count years of it being used in production. Clojure has only started seeing wide use about 5 years ago.
The fact that it's already used successfully at large companies shows that it is an effective language. Most companies that try it end up sticking with it. So, I'm not really seeing a problem here to be honest.
Clojure was released 10 years ago with 1.0 officially announced 8 and 1/2 years ago. Clojure adoption has been stagnant for a few years now. 8 jobs in London after 10 years, IMHO, represents a serious adoption problem.
Python was released 26 years ago, and it certainly didn't have the ecosystem or the popularity it has today 16 years ago.
There are certainly more than 8 jobs in London for Clojure. JUXT https://juxt.pro/index.html alone hires more people than that. Maybe you're just looking in the wrong places.
That is not interesting. If you are making the point that the rate of Clojure job growth is declining, it could be a data point in support of that hypothesis.
What do you think Clojure's absence from zdnet's list indicates?
I'm interested to know if anyone here has used this over an extended period of time. Does it work for you? Have you become better at estimating? Have you lowered your defect rate? Have you increased your pace?
I'm skeptical that something this prescriptive could be effective, but it'd be great if there was evidence (anecdotal or a study) that shows this is effective.
I went through a personal anti six-sigma period in the early 90s. And adopted a slimmed down version of this for myself. Rather: it had the same name and came from CMU, but I don't recall it being quite so cumbersome looking, and I adopted a slimmed down "personal-only" version of it for myself. I didn't work that hard at it, and I was able to bring alternative data to a larger meta-drama I was somehow participating in.
Later - I spun out of there and started a company and we did that slimmed down version, based on the this Y2K document's predecessor. It didn't seem to cumbersome because it was inline with a lot of things we were already doing. And we had were using this light-weight measurement practice embedded in a modified dev-team wide process based on the spiral (we were all from waterfall-world, and this fit us well).
I've gotta say: it worked very very well. Especially after a few iterations through a few spirals. Skeptics came around pretty quickly. (Well, except one guy - but he hated everything)
I can't imagine doing 100% of what's written in this document, as a dedicated, in parallel, side-car type activity - but it might still be well worth it.
The organization I used to work for used PSP and its accompanying TSP (Team Software Process). I'm trained as an Advanced PSP Developer and a TSP Team Leader.
In short: it works and it works well. The downside is that it is a very expensive process. For some types of software development (we developed medical devices) the Cost of Quality comes down in favor of PSP/TSP. For others, you may never recover the ROI.
The entire team and its accompanying management must buy into the process for it to work. SEI enforces this by requiring that a TSP organization licence materials from them and train management. An SEI-certified coach must be assigned to the team to ensure they follow process and support them, etc.
We got very good at estimating tasks. I have data spanning many years that show what my average development rate is and that is crucial to making proper time estimates. The defect estimation is based on shaky statistics (according to a statistics-expert friend of mine who has used the process), but it does help to know how many defects to expect in a given body of code and if your inspection processes are removing them at an acceptable rate.
The defect management borrows from manufacturing process theory in terms of defect monitoring and feeding back data into the development process to extrapolate quality, but obviously software is very different in some aspects, so it doesn't work as well.
If you need supporting data, the SEI has lots of it. TSP practice is based on recorded data (development rates; amount of time spent doing development work per week; defect injection and defect removal rates, etc...) from thousands of software teams worldwide that use PSP/TSP and the SEI holds an annual symposium where many of them get together to discuss how it works for them, modifications that improved it and so on.
tl;dr: It's an expensive process that works. Whether its suitable for your organization depends on a number of factors.
That isn't the case for ActionCable, which will become a dependency of the 'rails' gem [1]. You'll have to unbundle the rails gem in your Gemfile, then require the frameworks you want one-by-one in application.rb
You can just add each Rails framework to your Gemfile and be done. `require "rails/all"` catches load errors, so you don't need to require the frameworks manually in application.rb.
