Yeah I can't take Marc Andreessen seriously any more after that incident, no matter how hard I try. He wrote that surreal letter objecting to building multifamily/affordable housing, claiming it would immensely reduce the property value of his walled mansion in Atherton. It just reeked of pettiness and hypocrisy.

Agreed, although I wrote him off much earlier than that. I can't decide if he's actually disconnected from reality or if he's just saying whatever he feels will make him more money.

The difference between the two is purely academic, though.

Habitually doing the second inevitably leads to the first.

It has to be both.

You don't get to be connected and lust after 'moar money'. The two are incompatible.

This is just a sad attempt at marketing to OSS maintainers. Whoever came up with this idea has no idea how OSS maintainers operate.

Yet it's good enough to scale Pinterest, Instagram, and Youtube.

>You can't use it for anything serious that needs to scale due to the lack of concurrency and significant memory overhead.

Please actually think about what you are saying instead of just parroting off stuff you read on blogs.

Python has concurrency. Its called multiprocessing. Of course, there is startup overhead, but it achieves the same functionality. Furthermore, processes that are most commonly threaded (like fanning out network requests) are well suited to async, which has less overhead than threads.

Also, memory considerations are relevant only for embedded systems, for which you would never use Python. Memory is dirt cheap these days.

> Python is great for small scripts or explorations.

I've used Python on program with >30000 LOC without any problems.

Typically large code bases have problems that are more intrinsic to organization than what language its in. Huge code cases in any language are usually fine if discipline is exercised.

And concurrency issues and memory overhead problem are from not knowing the right way to do it. Although I will concede that naive approach to both of those is sub-optimal.

> Although I will concede that naive approach to both of those is sub-optimal.

Paradoxically, this can actually lead to a better understanding of how to write performant code. When I first learned some of the be implementation details of python, I couldn't believe it was performant enough to work for anything ... after optimizing enough of it, I understand better what actually matters

Also people seem to forget the rule of premature optimization. Worry about performance when performance starts to be a problem. You identify the area with performance is lacking and optimize that. Compute is cheap, manpower is expensive.

Python has types now (though it didn't when I wrote the 36kLOC program I had in mind).

What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?

> though it didn't when I wrote the 36kLOC program I had in mind).

Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript. And even though it is much better after 3.8 and 3.9 updates, the adoption of typing in various useful libraries was relatively low as far as I remember.

> What problems are there with python variable scoping -- you can have global and local variables, shouldn't that be enough?

Maybe it is just me, but the scoping rules feel weird: blocks like "with"-statement or for-loops don't create scopes. There is no distinction between declaration and assignment. Sometimes you have to use those weird "nonlocal" and "global".

The scoping is bad, they should have copied Perl's "every block is a new scope" and added an explicit "let" keyword to define variables instead of overloading assignment. The "nonlocal" and "global" and stuff like "lambda x=x" is a big giveaway that their approach was wrong, but I guess it was too late to change it.

The typing has been great in my experience. Most of my deps have types and if they don't I can autogenerate them. The powerful typing of TypeScript is mostly not needed if you're not interacting with JS code.

> Yeah, that was my assumption. Still, typing in Python feels very clunky compared to TypeScript.

I used comments in the code to say what the types were, e.g.:

    def processNotesForm(d):
        """ process the notes form
        @param d::{str:str} = the form data
        """

Of course in modern Python one would simply say:

    def processNotesForm(d: Dict[str,str]):

Lack of typing support is a major advantage. If you don't have types you don't need interfaces, generics, etc. The resulting code is shorter and less bug prone.

You still need all of that. You just have to store that information in documentation and do analysis in your head instead of relying on a static analyzer.

No, you really don't. Static typing is very complex and error prone compared to dynamic typing.

There is a lot less stuff that needs remembering.

Languages like Python and TypeScript support 'any' as a type, so you can always opt out of strong typing if you want. Most of the time generics are preferable to things randomly dying at runtime though.

Things don't die very often due to typing issues. The unit tests always pick up typing problems.

Testing the code's behavior implies testing the code's typing. And if you are not testing the code's behavior then the code isn't really tested at all.

Does your code check every single variable is not null before using it? That every function argument is of the expected type? That every attribute exists before it is accessed? And do you have unit tests for all of this too?

If so - then you're writing a whole lot of manual checking that a strongly typed language would perform for you, at compile time. If not - well then you're doing less testing than a strongly typed language would.

I agree that these issues are rare, and there is evidence that strongly typed languages have a similar number of bugs to dynamic ones. But suggesting that because you have unit tests, you don't need strong types, is a bit naive to me.

I don't actually care about any of that stuff. You are confusing technically wrong with not working. If the code works in production it doesn't matter that the code is technically wrong.

Testing via typing is very weak testing. Almost worthless. Type checking doesn't find many bugs in general.

Strongly typed languages have 2.5 times the number of bugs as dynamically typed languages per software feature.

Why would you intentationally add bugs to your code?

It doesn't make any sense to me.

Thinking using static typing in a scripting language is a good idea is pretty naive. It's like creating a version of Haskell with mutability.

Very insightful indeed. "I never lock the door to my house but it's never been robbed"

Once you have got 5 years real world experience and find programs in production that work for the wrong reasons, you will understand. (And I'm not just talking about programs with dynamic typing either)

I'm aware of one case where a program traded 10 million dollars, made 5 million profit. There was a serious jaw dropping error in it. Did it matter? (and if so, to whom?)

The alternative is pretending your house is a treasury and buying a lock which costs more than any other item in your house. While your roommate develops kleptomania.

One data point: my wife and I were set in getting a Tesla as our next car. We are now in the market for a new EV, but we both decided against Tesla due to Elon's shenanigans. We will wait for the Kia EV9 or something coming out next year.

Everyone knows it is trivial to host a read-only static website with the traffic of Substack.

It’s the read/write part that gets you.

Doubt you could do that in a way where you'd attract users at the level of Substack.

You could if you gave people $400-500k to move over.

If my grandmother had wheels, she would be a bike.

They were fronting people 250k+ for their first year. IIRC

Umm maybe it’s the fact substack is outright paying for traffic and lying about it? It’s just their own paid influencers who use it.

Perhaps I'm a bit old-fashioned, but paying writers to write doesn't seem like a particularly nefarious activity to me. I mean, I believe the NYT does it too, and a few other organizations.

Where are they lying about it? They openly admit to paying writers. And no, it's not "just" their influencers using it.

To be brutally honest it does not seem like Slack is the actual problem. I think you are having difficulties performing and are looking for an excuse, and Slack seems convenient. Just uninstall the Slack desktop client and use the web browser once or twice a day. Get real work done.

We used to pay CircleCI $200/month to run CI on a widely-used open-source project, which was set up before GHA was available. Around one year ago we switched to GHA, which was significantly better, and cost $0.

At around the same time we made the switch, we got an opaque email from CircleCI about their new `performance plan` which would have increased the cost to $300/mo. This was more metered pricing.

Anyway GHA has been a breath of fresh air and I have convinced several open-source maintainers do dump CircleCI in favor of GHA.

When I read this, not judging or anything, no ulterior motive, I'm reminded Microsoft and embrace, extend, extinguish.

When and if they get rid of the competition, it likely won't be free aka 0 monetary costs again.

I am surprised to see that GitHub staff are still working on GitHub Actions. It's hard to tell because it's been almost two years and it's still not possible to have a self-hosted GitHub Actions runner on Mac M1: https://github.com/actions/runner/issues/805, even though the community has made PRs for it.

Self-hosted runners at scale are a nightmare. Random failures all around, exit code is whatever it wants to be... you'd think with the runner code in the open all that could be fixed, but no, it's a very confusingly written MS C# codebase that has clearly grown over the years as TFS Pipelines. Even the GitHub developers get confused when they tried to implement ephemeral runners and then figured out the scheduler just pipelines new jobs to runners and drops them permanently (shows as "waiting for runner for 15-20 minutes, then cancelled to the user) if you kill the runner anyway. And the worst: The component failing most often is the scheduler, and that runs at GitHub. It feels like it was written by an intern. It doesn't even do FIFO. Old jobs generally wait _longer_. We also have stuck jobs all the time because the scheduler lost it. GitHub Premium Enterprise Support just keeps saying to contact them whenever it happens and they're "working on it". My team has been working on making this entire crap work for almost an entire year on and off, and things only got marginally better. To the point we'll be using the new hosted runners with fixed egress IP and custom sizes instead.

Good job, you filled a hole in your spec sheet with literal shit and then sold us the only alternative a year later when it is unfeasible to migrate away again ("but we have a large Microsoft contract" politics keep us from doing that anyway, but that aside).

GitHub Actions are extremely actively developed and from what I can tell quite strategic. However, the action team's acceptance for outside contributions across all their projects (runner, toolkit, actions) seems surprisingly low for a company that runs a "social" coding service.

This is seriously bizarre.

Arguably the world's leading CI/CD tool doesn't support iOS builds on M1.

But yet they can deliver 100+ far less fundamental features: https://github.blog/changelog/

You can do it by running your terminal in compatibility mode. I’ve been running our iOS CI pipeline on an M1 for almost a year flawlessly at this point and it’s blazing fast.

People use mac m1s as servers?

Mostly the Mac Mini to run CI workflows or build iOS and macOS applications.

Macs are the only way to build iOS apps. And the M1 macs are several times faster at this task than the old ones.

I think the primary use case is building the same code on multiple platforms. A developer can write a single CMakeFile and then CMake will generate Makefiles/Ninja files/VS soln files/etc depending on the underlying platform.

I've used CMake for a number of larger projects. When you start having to deal with external dependencies or cross platform support it definitely fills in some of the holes in the C-style build ecosystems

One of the things I've never been a fan of is that for whatever reason, the build steps that you see in basically every project are: - mkdir ./build - cd ./build - cmake configure ../ - make build

Has no one thought of simplifying that??

You can simplify it to cmake -B build && make -C build for example

Yes, we write a shell script and move on.