phodge

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.

`set confirm` is another great option to turn on all the time. It will save you having to retype a command with the `!` added.

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.

[1] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

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.

I've never liked git flow due to:

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.

A branch is merely a pointer to the tip of a series of commits.

But this is not actually correct because a branch can often point to a commit that is not the tip.

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.

Because of git's shortcomings polyrepo is a near necessity

I'm intrigued by this claim. I've come to the opposite conclusion - that monorepo is near necessity with git because there's no tools for branching/rebasing multiple repos at once.

Possibly Typescript. Try finding documentation for the bundled "Record" type. It seems you're supposed to just know how to use it already.

I'm keen to have a look. I've been frustrated with other tools because they're too focused on splitting everything into identical monthly budgets when that's really not how finances work IRL:

1) My driver's license costs $150 to renew once every 5 years - I don't want to split that into 60 monthly allocations of $2.50 and end up having over $100 sitting in my account for an expense that's still not due for over a year. I just want a tool that knows what expenses are coming up over the next 3/6/12 months and let me know if it thinks I'm going to overdraw my account. $150 is actually really easy to scrape together when you have 6 months notice that you're going to be short.

2) I spend $100 on public transport every 2nd Thursday because I get paid every 2nd Thursday. That means either $200/month or $300/month depending how many Thursdays fall inside the calendar month, and whether they're actually the Thursdays that I get paid on. Having a monthly budget that allocates $217/month on public transport (because that's the monthly average) makes me set aside $17 most months unnecessarily, or possibly leave me short $83 and unable to get to work if I spend the remainder.

An example of this is the concept of resumable exceptions. During Semantic's interpretation passes, invalid code (unbound variables, type errors, infinite recursion) is recognized and handled based on the pass's calling context. ... Porting this to Java would require tremendous abuse of the try/catch/finally mechanism, as Java provides no way to separate control flow's policy and mechanism. And given Go's lack of exceptions, such a feature would be entirely impossible.

Not knowing much about FP, It'd be great to see a more in-depth article explaining this problem domain a bit more and showing some side-by-side examples of Haskell's specialized call sites compared to a Java try/except/finally solution (although Python would be a better procedural exception-based language to compare to)

One of the main reasons I don't care much about Haskell is because without any side-by-side comparisons of Haskell vs <insert procedural language> I don't understand what the Haskell advantages are, and I don't know when I'm dealing with a problem space where Haskell would help me.

Comments are washed out because the compiler/interpreter will completely ignore them. That's what your syntax highlighter is trying to tell you - that these lines are unimportant because it they have literally no effect on the program.

I built something like this in ~2006 called "PHPinPHP" because I wanted to generate PHP classes from my mysql schema. It even used "[[[...]]]" blocks like cog does.

I eventually realized that A) generated code is completely unmaintainable; and B) the reason I thought I needed code generation is because my base language wasn't flexible enough.

Later on I switched to python and haven't yet hit a problem that I need code generation to solve.

Loosely related - this is what terrifies me about deploying to cloud services like Google which have no hard limit on monthly spend - if background jobs get stuck in an infinite loop using 100% CPU while I'm away camping, my fledgling business could be bankrupt by the time I get phone signal back.

Most programming languages pass function parameters by value

The biggest irony here is that if you wrote your code in C instead, you would actually pass more arguments by reference than in equivalent python, because you're going to use pointers for everything but primitive integer values.

First up, thanks for dedicating a big chunk of your life to building tree-sitter! I had a go making a similar parser last year (fast, dynamic-grammar, self-correcting) and had to give up when I started to realize what a ludicrously complex undertaking this is. The fact that tree-sitter works at all is nothing short of amazing.

Question: do you have any plans to integrate tree-sitter with the language-server project(s)? If fast, accurate parsing of any programming language is now easily implemented in language servers via tree-sitter, it seems to make sense for LSP to expand its protocol to include syntax highlighting as well.

I applied for the remote full-stack eng role back in June but never got a response. Was my application forgotten or just dismissed without a response? (Trying to work out if I should apply again.)