This article conflates the Monolith|Microservices and Monorepo|Polyrepo dichotomies. Although it is typical to choose Microservices and Polyrepo together or Monolith with Monorepo, it's not strictly necessary and the two architectural decisions come with different tradeoffs.
For example you may be forced to split out some components into separate services because they require a different technology stack to the monolith, but that doesn't strictly require a separate source code repository.
That could be an interesting site when it's done but I couldn't see where you factor in the price of electricity for running bare metal in a 24/7 climate-controlled environment, which I would assume expect is the biggest expense by far.
I ran a survey and some one-on-one interviews of 30 or so engineers at my workplace to get some real data about the impact of slow tools. IIRC, the results were something like this:
* Most engineers can maintain focus on a task for up to 10 seconds waiting for a slow tool. However a couple of engineers (myself included) will get derailed at only about 3-5 seconds.
* A tool that runs for more than a minute will cause just about every engineer to switch task while it is completing. (This means they stop working on their highest-impact work and likely spend time on lower-impact things).
* A tool that runs for more than 15 minutes will make any engineer have to start deliberate multi-tasking where they are trying to work on two major work items at once.
Also, I wouldn't have read the article or posted this comment if it weren't for the slow CI pipelines at my workplace.
First of all, this sounds like an amazing project. My workplace runs isort+flake8 in pre-commit hooks, so making these even 10x faster would be a huge quality of life improvement for us.
Personally I'm interested to hear from you what are the specific reasons you can't achieve this kind of performance with CPython.
Usually the major factors are: A) python's generalised data structures (int, list, etc); B) extra overhead of common operations like reading a variable value, calling a function or iterating over a collection; C) no real multithreading (i.e. the GIL); D) lack of control over memory management.
I'd love to know if there's anything else that makes Python that much slower.
There actually _is_ a good argument in there, but the article is really poorly written and all the preamble about SourceForge ends up being a distraction from what you really need to stop and think about:
FOSS projects like the Linux kernel use the GPL license because the developers want their code to be free not just for themselves, but for everyone everywhere for all time. It's not acceptable terms for you to take their work and use it to build an alternate operating system that you aren't going to share. If this wasn't important to them they could have just published their code under MIT/BSD licenses.
If you were to build an AI that used the Linux source code to generate a "new" closed-source operating system, in a very real sense all you've done is invent a new way to plagiarize the Linux community's work so that you can weasel your way out of their license terms. Even if you got away with this in the courts, it's obviously very unethical.
What Copilot does is enable the mass plagiarizing of open source code from everyone all at once, mixed up together so that it's hard to know who the original authors were, and then pretend that somehow this makes it ethical.
I've never worked in virus research, but my understanding is that any researcher would be keeping meticulous records of every virus they're studying, as well as detailed information about genetic differences with any variants they have produced. So if the Chinese govt simply seized access to all research projects at the lab at Wuhan they would have been able to compare all viruses within the lab with SARS-Cov-2 within a matter of weeks and have an extremely confident Yes or No as to whether it came from their lab.
I'd love to be refuted on the above by someone with actual viral research experience because the alternative conclusion is that the Chinese govt has known the true origin of SARS-Cov-2 since early 2020 and simply won't tell anyone.
In Australia and most other developed countries now, this ideology is heavily promoted to children, encouraging them to believe they are trans. They are connected with websites that promote the ideology, and then connected with a trans specialist who helps prescribe puberty blockers without parental knowledge.
If you are a parent who believes that children should be taught to love their own bodies as they grow rather than have surgeons pretend to fix them by removing essential organs, then this represents a massive assault on your offspring.
> The numbers I can find for US citizens is: 0.6%
And there's a huge number of "trans" who later realise they were sold a lie and have to undergo further surgery to try and restore their original sex. Selling this to ideology to children is going to dramatically increase that 0.6%. How many of the new cases are going to actually be trans, vs children that thought they were trans and started puberty blockers at school, but actually were just never taught to love their body?
I don't see how your version is easier than the sequence of commands in the first few steps of the article, which is basically `pip install flit; flit init; flit publish`. Flit is just as easy to install as twine, but you save yourself the hassle of having to write a setup.py.
"Monolith or Microservices" and "Monorepo vs Polyrepo" are best treated as two entirely separate engineering questions.
You can have a Monolith built from code in many repos, or many microservices maintained in one big repo.
There are various pros+cons for whichever combination you choose, there's no "best" answer that applies to every single situation.
The reason you stumble upon youtube videos that make you uncomfortable is because we have a free and open web where anyone can publish whatever they want (except the most extreme content such as terrorism how-tos).
I don't see how this Mozilla tool could ever contribute to making the web more free and more open; in fact it seems to be designed by activists to make the web _less_ free and _less_ open.
Ironically, these days with front end development I'm finding it hard to accurately scope how long it will take to incorporate 3rd-party dependencies. The docs make it seem straightforward enough, but they don't cover how to use it correctly under TypeScript instead of ES, or how to use it with Angular instead of React, or how to build it with Rollup instead of webpack, and I often spend an entire day googling obscure blog posts on how to get a dependency working in my own ecosystem.
I can't say I'm an expert on RedHad's business model, but I think this is what they've done with Linux. Mysql did something similar as well, but in their case they built mysql from scratch themselves rather than attaching to an existing product.
Joel Spolsky does a good job of explaining what's actually happening here in his old "Strategy Letter V" from 2002 [1].
Caleb hasn't discovered some secret means of convincing people to pay for OSS they can download for free. What he's done is create a commodity (the open source package) and then once it's popular, make a tidy profit off its complimentary product (training videos).
Unfortunately it's still true that people generally won't pay for software they can download for free, but if you're willing to dip into some other types of work (e.g. consulting, creating training videos) then you can make more than enough profit top keep going indefinitely.
How is this result surprising? The point of coroutines isn't to make your code execute faster, it's to prevent your process sitting idle while it waits for I/O.
When you're dealing with external REST APIs that take multiple seconds to respond, then the async version is substantially "faster" because your process can get some other useful work done while it's waiting. Obviously the async framework introduces some overhead, but that bit of overhead is probably a lot less than the 3 billion cpu cycles you'll waste waiting 1000ms for an external service.
My org is starting to migrate from a PHP Monolith to Microservices as a way of freeing ourselves from PHP.
Microservices will require more time spent writing interservice APIs, and code execution will be slower since many procedure calls will require data serialization and network requests. But we believe it will be worth the overhead to not be locked into PHP for every new component of the project.
A) the way it abuses the commit DAG: you never merge master directly back to develop, and so your tags don't become ancestors of the commits on develop until some timer later when an unrelated hotfix is branched from master. E.g., you can't rely on "git branch --contains v1.0.1" to tell you which branches do/don't contain the 1.0.1 hotfix because the hotfix branch was merged to develop, but not the merge commit that was tagged as 1.0.1.
B) its blatant disregard for one of the most basic software development principles: when you want to deploy a new version of your software, you test a specific a revision of your code and that's the revision that you deploy. With Git Flow, you go to great lengths to ensure your release branch is isolated from other work for testing, but then you merge to master and deploy the merge commit instead of the commit you just tested.
I'm not convinced. Often the productive "hard worker" persona tends to push through tedious manual tasks, where the unproductive "lazy" persona gets bored and looks for better ways to do things.
> I realized I was spending about a quarter of the total time implementing the feature tracking down which functions the bugs were in!
This was a huge problem for me back when I was doing web development and had to support IE6. I write hundreds of lines of code which worked fine in Firefox, but then it would crash in IE with no descriptive error message and I would spend an eternity gradually commenting out more and more of my changes until I found the offending line through a tedious manual brute force bisect/test process. I was able to increase my productivity by testing every individual little change in IE as I made it, so that when I got some vague error, at least I knew there were only 10 lines of code where it could possibly be originating from.
However, these days with all the linters, typecheckers, and good error tracebacks in browsers, I'm much faster if I leave all my testing for the end. In fact, I've spent the last 2 weeks refactoring one of my side projects and only bothered testing right at the end. There was only a handful of simple bugs that TypeScript and Mypy couldn't detect, and the in-browser errors told me exactly where to look to fix them.
For example you may be forced to split out some components into separate services because they require a different technology stack to the monolith, but that doesn't strictly require a separate source code repository.