It's funny because we told people not to trust big companies, they tell us we are paranoid, they do it, they pay the price for it, then they say we were right, then they do it again.

MS changed. Google changed. Apple changed. Why do one expect github to never turn evil ? Haven't learned enough from history ?

Don't let them control your entire stack! Don't let anybody control the entire of anything.

There is a difference this time though. This time, most of us will say it only once.

People act in their own interests, usually prioritizing the medium-term (eg. evaluating every few years/every decade) over the long-term. These products made by the big companies provide immense value that promises to make your life better tomorrow, so most people choose them.

It's over once we don't have control of the compilers. Look at the iPhone.

iPhone is the direction everything is trending.

Fight this bullshit. Call your pro-breakup / anti-trust representatives and give them the reasons this is bad for you and your career. Tell them the narrative and give them ammunition to fight this.

Google, Amazon, Apple, and now Microsoft deserve regulations and/or dissolution.

I don't understand the panic.

This isn't a black-box system, it's github. Owning your artifacts is as simple as setting up a job to automatically clone the repo a couple times a day (assuming your entire company is working through the cloud interface and not a single person already has a local checkout).

Lots of companies put their entire databases in AWS - owned by a company that's already evil, no speculation required - where the egress charges make offsite backups a challenge. And western civilization hasn't collapsed yet.

If GitHub changes its policies one day or shuts down the service... just push to a new repo and switch over to regular workstations.

> This isn't a black-box system, it's github. Owning your artifacts is as simple as setting up a job to automatically clone the repo a couple times a day (assuming your entire company is working through the cloud interface and not a single person already has a local checkout).

Isn't the use-case they're selling in the article approximately "the development environment setup is so fragile that it doesn't work on lots of machines?" I'd be willing to wager that after a few years of the whole team using this, the fragility will be much worse, so moving away will be that much harder.

Fragile in the sense that it might take you hours or days to get it all set up just right. It would be a disruption, like any IT problem, but it's not going to threaten an entire business.

I might be wrong, but it seems to be a combination of visual studio code + container plugin + docker. So you would need to install visual studio code, few plugins and spin up a docker to replicate that environment on the local machine.

> they pay the price for it, then they say we were right

What are you referring to?

github was already turning evil. and being bought by microsoft sealed the deal

Given the whole outrage over Apple taking advantage of customers' willingness to hand over control of their phones to them, I hope folks can see the parallels here and reject this.

At this point Microsoft's strategy around GitHub, VS Code, Copilot, etc. should be pretty obvious, and we should all be running for the hills.

> At this point Microsoft's strategy around GitHub, VS Code, etc. should be pretty obvious

As someone not following this closely, what would that strategy be?

What are they embracing, how are they extending it, and how do they plan to extinguish it?

My understanding of EEE is that it involves taking some competitive product/standard, making a cool MS version of it, and then killing off the standard version - e.g. implementing a barely sufficient POSIX layer on Windows, getting customers who have "POSIX" as a purchasing requirement to switch, and then getting them onto the NT API.

Most of the examples on that wiki page have been unsuccessful (IE trying to EEE HTML, Outlook trying to EEE SMTP, etc.), because they weren't able to get enough people to rely on the extended version and stop using the standard thing.

What is the analogy here? Microsoft wants to embrace and extend... compiling software? and will kill off... existing ways of compiling software? How will this work?

It's a slightly different flavor of the same thing.

VS Code is an amazing tool that's getting huge adoption because of how awesome it is, and how open source and community centric it is, etc. They've gotten a lot of mindshare and dev love, that's the embrace bit.

The next step is the set of closed source addons. Have you noticed that a lot of the new VS Code features are now in addons that are under a different license. This includes the new remote dev and python tooling. Still free to use and awesome tools, of course, but fully under MS exclusive and controlled. That's the extend.

I don't know what the longer-term plan is. I'm hoping that it won't lead to an extinguish. But if that's what they want, then they could e.g. cripple the open source version, moving all their dev effort into a closed-source, Azure/Github only web environment. Who knows?

Gotta love how the goal post just keeps moving forward.

I don't see what post was moved, this is exactly EEE, adopt an open strategy, extend it with proprietary extensions, don't let competition use those extensions, extinguish competition by not being able to interface with your proprietary extensions while having created an expectation from the user for them to be available.

More like you never know when they’ll initate the final part of their strategy.

Half the dev world is now used to VS code. Many junior developers have never used anything else. Whatever they do can have a big impact.

>> What is the analogy here? Microsoft wants to embrace and extend... compiling software? and will kill off... existing ways of compiling software? How will this work?

Microsoft is embracing free development tools that compete with purchased tools they sold. SourceSafe vs Git, Eclipse vs Visual Studio.. those are terrible examples but you get what I mean. So you make a free tier of VS, you buy git hub etc.

Extend.. you try to make your tools as ubiquitous as possible. You convince hobbyists and students that they should use your platform because it is more powerful /useful.. it will help you get a job later. This part of the strategy seems really hard because there are so many development tools that are open source, and lots of companies like IBM, Oracle, Google want to keep one of their own safely under their control.

Extinguish. You add features that only really work on your platform, or work better. Think about trying to develop for Android not on Android Studio. I haven't used VS for a Windows project in a long time but I assume it has similar advantages. Or Intel's compilers used to be the first to work with new instructions.

Ideally people would "have" to use your platform and you can start taxing them for that, either with fees or requirements that they implement your initiatives. Think about Google pushing Kotlin.. Android Studio kind of defaults to that now. Of how it supports Firebase, or defaults new projects in segments. I am not mad about that it or anything, it may just be a good idea. But it shows how if you control the dominant tech platform you can support your initiatives.

This isn't something that keeps me awake at night because a number of tech companies are working to promote their own semi-proprietary or open development platforms. But the fact that so many go to the trouble to do that shows it is a concern.

I understand how EEE is supposed to work. My claim is that it doesn't actually work, at least not for this use case.

So for my argument, SourceSafe vs. Git is a great example. :-) You simply can't keep up with a proprietary tool that does its own stuff. You have to use Git. Microsoft tried having a custom version of Git for Windows OS development, and decided that they weren't even able to get themselves to fall for the trap - they ended up getting involved in upstream Git development and turning all their extensions into standard features.

There are definitely cases where if you control the platform you can control what people are doing. I'm arguing that Microsoft has no actual effective control of the platform here.

EEE doesn't have to work to be considered anti-competitive. The intent is nefarious, it's trying to attract people by offering a veneer of good grace and good intentions, only to capitalize on it once you've attracted a strong enough user base that you can get away with closing things down, squeezing things in, and calling the shots.

So it be great if their proprietary remote extensions fail and they are forced to open-source them and make them a standard, but clearly the intent right now is that they don't fail and it gives them a leverage over their competitors.

They first embraced web standards by building a web based open source IDE called VSCode to get people to convert to it over using Visual Studio.

Now that they attracted people to use it, they embraced Linux containers and offered managed dev containers as a service over it called Codespaces running all on Azure.

At this point, it's all good, this is how a company profits on open source and standards.

But now they are extinguishing by adding proprietary remote extensions, see https://code.visualstudio.com/docs/remote/faq#_why-arent-the...

Those extensions being proprietary will lock you to VSCode and their own containers. As a user you might still use it for free, even though they may add future premium features see: https://code.visualstudio.com/docs/remote/faq#_will-you-char...

But other competitors will not be allowed to use them to compete, and they can't be bundled in anything else, so Sublime wouldn't be able to bundle them in or make use of the remoting features.

The remote extensions are key to the attractiveness of VSCode for use with cloud managed containers, so it's a pretty big differentiator.

On top of that, they purchased GitHub, where most open source software lives, and are now trying to move development on those open source projects to adopt their own proprietary extensions to offer contributors a way to quickly contribute using VSCode and GitHub Codespaces.

Sounds like EEE to me. Maybe it will fail to extinguish, but my guess is we will see a lot of people slowly relying more and more on proprietary extensions owned by Microsoft to the point where if you work for certain companies you might not have a choice but to use VSCode.

I think the 3rd E is more likely "extort" these days. They won't extinguish it, but you'll be paying per user per month forever and the prices will always go up, up, up.

Some could even call it Embrace, Extend, Extinguish...

hmmmm.......

The same thing was said about every programming abstraction to ever be introduced. How do we expect people to build memory-efficient applications when they become reliant on a garbage collector?

I've never seen a company collapse because their garbage collector posted an Our Incredible Journey™ blog post and then shut down a week later.

I have seen multiple companies collapse because the proprietary Backend-as-a-Service they built their sand castle on top of pulled a vanishing act, however.

There's plenty of companies that wasted a ton of resources trying to roll their own version of things that should be services. Remember when Uber built their own chat solution? [0]

> With operations in over 620 cities, it was paramount for us to identify a chat solution that would enable Uber employees to reliably communicate on desktop and mobile regardless of where they were in the world.

Did Uber really need their own chat solution? Are they not better served by a SaaS product, one of 5 that 90%+ of companies are using? Are they still using uChat today? (honest question, I don't know)

This is especially dangerous when talking about security sensitive features. It is highly inadvisable to roll your own crypto

Lot of companies shut down or fail for lots of reasons. I think a business should focus on what they do best and what's critical to their mission.

[0] https://eng.uber.com/uchat/

> There's plenty of companies that wasted a ton of resources trying to roll their own version of things that should be services. Remember when Uber built their own chat solution? [0]

Sure, there's obviously a big difference between controlling the things that are critical to your business and wasting time outside your core competencies. And part of that difference is the risk profile: if your entire backend disappears, and takes the API your frontend is built around and all of the data with it, you're basically up shit creek. If your chat app of choice disappears, you can sign the company up for a different one tomorrow – it doesn't take 8 months of crunch to "port" your employees, and likely all of your critical business docs weren't in the form of chat history.

> Lot of companies shut down or fail for lots of reasons. I think a business should focus on what they do best and what's critical to their mission.

Agreed. But very few internet companies can claim that the data in their datastore and the entire mechanism by which their product accesses said data is not critical to their business, which is the distinguishing factor here.

Crypto is almost always implemented as a library, and probably ultimately as a kernel module in most cases. There is no reason at all you should need to call out to a remote service to encrypt and decrypt data. That wouldn't even make sense, as it would need to be encrypted before traversing the network to be of any use. And there are plenty of commodity chat applications like Mattermost and RocketChat that you can self-host, again not necessarily needing to use someone else's cloud service but also not need to roll your own application.

Uber grew extremely fast in its initial years and that resulted in large number of teams starting NIH projects to "make themselves useful". Uber switched to Slack a while back, in addition to laying off a sizable chunk of the engineering workforce, and it didn't really collapse on itself.

Nowadays, there's a lot more support internally at Uber for buying off-the-shelf solutions instead of trying to reinvent wheels.

I see your point.

But at Uber's scale I can see the business need for a custom chat app. Most third party chat apps are bloated, both the cheap and expensive ones. Plus there's the need for custom integrations.

I used to work at a large bank and they operated perfectly fine with Window's messenger. As does every other bank in the US, despite having tens if not hundred of thousands of employees. Some things require more specialized features like trade tickets (which Bloomberg does), but for chatting, you're not gonna be able to build a better solution than already exists. And if you can, then you should spin that off into its own business like Goldman did with Symphony [0]

The nice thing about being a client is that they support all this stuff and it gets better over time. Also something like Slack is absurdly cheap compared to the usefulness and productivity it provides.

[0] https://en.wikipedia.org/wiki/Symphony_Communication

> but for chatting, you're not gonna be able to build a better solution than already exists. And if you can, then you should spin that off into its own business like Goldman did with Symphony

The implication that Symphony is a better solution for chatting than already exists / existed.

As a (non-trading) user of the platform, I strongly disagree.

I don't know what the traders think, but I'd hope there's a USP in there for them besides "it's cheaper than a Bloomberg seat."

I am not concerned with Microsoft posting an Our Incredible Journey (TM) blog post within my lifetime, but duly noted.

Microsoft, too, will pull projects, or just completely rewrite them and make them incompatible.

Applications using .NET Framework with WinForms are not just a dependency update and recompile away from being ported to .NET 6. WinForms got a whole new API and porting complex UI effectively boils down to a rewrite. At least if you can. Microsoft doesn't support third-party controls in the WinForms designer of Visual Studio for .NET 5+, so have fun trying out positions and compiling over and over.

Big companies put projects to rest all of the time. There are even whole sites with countdowns and all.

What’s an example of a company collapsing in that way? I actually can’t think of any.

These tend to be early stage startups who went with BaaS to get around resource constraints and couldn't survive the rapid need to exfiltrate their data and build a backend with a gun to their head. Larger companies generally have the survival sense not to sharecrop business critical functionality to such a degree.

Which is to say, you wouldn't have heard of them, because they never got big enough to be known to anyone beyond a handful of clients and employees. I've personally been hired to try to rescue such a company, and was not successful.

> Larger companies generally have the survival sense not to sharecrop business critical functionality to such a degree.

Larger companies have also been known to buy out critical service vendors and in-house them when there was a risk that they might otherwise shutdown or pivot, too; that's less often an option fot smaller firms.

Do you consider AWS Lambda and such to be BaaS? I'm pretty new to the field and have been focusing on AWS 'serverless' as the backend for most projects. Would you say this is bad practice overall?

(I'm not heavily experienced with Lambda but) I don't think you're in too bad a position, at least from what I've seen, as there does seem to be a portability story wrt those serverless functions.

The objection here isn't to hosting per-se – most companies aren't in the business of maintaining PostgreSQL and should consider outsourcing that task early on. If your host of choice shuts down, that's a standard service, you can dump and restore your DB and move on. Annoying but NBD.

The danger with jamstack or BaaS or similar approaches is working yourself into a place where a proprietary service API is baked into your product as a critical, fundamental dependency; if and when the host shuts down, you're in extreme trouble. That's what I'd heavily caution against.

(There's an argument that when the proprietary service is run by an MS or AWS or Google "they won't go bankrupt" so there's no risk, but even then those companies shift priorities and shut down services not infrequently).

I don't think it's a bad system to build on, but I would be nervous to have it as the only option in my tool belt. Proprietary cloud services often create vendor lock-in, and the skills you learn eventually become non-transferrable as you get more invested in their system. If you only want to work at serverless companies, or on serverless projects, that may be fine. But, knowing how to SSH into a machine, maneuver around, and how to set up a server will always be valuable

Any company built on a 3rd party API. Many examples on twitter.

The difference is that you don't pay a monthly subscription to use a garbage collector.

Garbage-collection-as-a-service would get a ton of venture capital though.

Oh wow, AR/VR mark/sweep applications! Those VR rooms get messy, who is going to clean them up?

At patent office right now with this. My attorney said will go through the USPO like butter.

There are a ton of a companies that help you track cloud spend, while some of it is architectural, most is really about waste, old ec2 image backups, s3 with no lifecycle policies ... garbage

Hahaha cloud-based garbage collection. Made me giggle.

There's two things happening in this post:

1. Development environments are running on Kubernetes, and VS Code is remoting into them. You don't have to pay a monthly subscription for that. VS Code remoting is free-as-in-beer and Kubernetes is free-as-in-speech.

https://code.visualstudio.com/docs/azure/kubernetes

2. The actual Kubernetes hosting is the product "GitHub Codespaces" running on Azure. GitHub certainly isn't paying a monthly fee to themselves for this; they are, technically, self-hosting it. I agree that you probably do want to have the option to run it yourself, but I think you do, given 1.

Microsoft probably does internal billing here, right?

I mean, probably for the actual Azure usage, but that's not different from billing yourself for development VMs or Mac laptops or whatever (i.e., they'd be doing that independent of this approach). I assume the Codespaces team is getting plenty of value out of GitHub dogfooding the product and doesn't need to bill themselves for its use.

This is already a thing, if you look at Java (old-school ik), Oracle vs OpenJDK [1].

I don’t see why that would be a problem though? If I can pay a company to provide improved GC for my infra, where the cost savings made it beneficial, I would do it…

[1] https://superuser.com/a/1365224

have you heard of Azul Zing?

(not entirely serious, but it has a very expensive monthly fee for what is in essence a better GC algorithm)

I bet somewhere you just gave a Lang Developer a monetization idea...

This will be coming to a cloud service near you

The garbage collector should pay _me_ to use it.

> The difference is that you don't pay a monthly subscription to use a garbage collector.

In some cities you do, and they're often controlled by organized crime.

(Whether this comment is a metaphor for SaaS is left as an exercise for the reader.)

I'd argue that it always held true to a certain extent. You don't necessarily need the underlying knowledge to be an efficient programmer in Python, but knowing C or Assembly certainly gives you an edge when it comes to, well, edge cases.

And it isn't all about efficiency. Programming and CS is such a major part of my life, that I want to know the deeper parts, and I want others to understand it too. Programmers who do not seek that knowledge I unjustly judge for it.

The opening to the second paragraph honestly reads like satire of something that could have been said at any point in the last 50 years.

You're totally right. Javascript and its ilk are clearly superior to the languages and tooling of the past. There's no doubt about that.

> If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late.

I'm sure this has been said dozens of times throughout the years as we've built more and more tools of abstraction. As software gets more complicated, it's OK if not everyone fully understands every part of the stack. People specialize, and then become experts at their small scope.

Or even if they're not experts at their slice, not every company needs a 10x code wizard who understand the system up and down. Some companies just need someone lightly technical to mess with website templates or write simple scripts and services.

Sometimes I amuse myself by thinking that fantasy games are actually a thinly disguised sci-fi commentary on the direction of modern programming. Take for example the Protoss race in Starcraft or the Sheika tribe in Breath of the Wild - the premise is basically that there's a highly advanced society using the remnants of amazing ancient technology that they themselves no longer understand.

Jonathan Blow - Preventing the Collapse of Civilization https://www.youtube.com/watch?v=pW-SOdj4Kkk

> If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late.

Bingo. The inevitable rug pull is going to be very, very expensive/catastrophic for a lot of people (though, profitable if you understand the underlying systems).

This may not be what you are referring too BUT I can say as a .Net developer it's amazing how little .Net devs know about how the low level dev related stuff works because visual studio holds there hand.

I have blown people's minds by showing them how to just call msbuild or git from the command line etc... I think it's changing since dotnet core took over in that space but had a good 10 year run where generally no one at various work places had any understanding of what visual studio was really doing and it did bite us in the ass at times.

There’s two sides to that coin. In visual studio, most of the time you don’t need to bother to see what’s under the hood, and you can focus on feature development. In that way, their ignorance can be a good sign. The flip side is when your stuff won’t build, it can be an ordeal to figure out why, but thankfully it does not happen a lot, and they can leave it to the local experts.

Yes, IDEs are similar in a way that they abstract lot of stuff, so people end up depending on them. I don't mind IDEs, but I encourage learning what they actually do behind scenes, so you won't be completely useless when you don't have them.

I think that's one of the biggest issues I have with codespaces.

ownership issues aside, the "magic" under the hood is not a problem assuming it actually works. Its when the magic breaks, or works in unexpected ways, then it becomes a problem. Magic is also progress, and progress is usually good.

I think you could look at it in terms of sustainability: "magic" progress has the potential of "magically" vanishing if it's inner workings are not sound, reliant on an unreliable other, etc.

Free software won, the commons ossified as no one cared to invest in fundamental ways, new layers are slapped on to hide the cruft, and the pendulum swings back to proprietary competition.

I assume a huge part of why GitHub is okay with this is that VS Code / Codespaces and Azure are both products from the same company. :)

I do think there's a serious autonomy question here, and I think companies do actually care a lot about maintaining their autonomy from other companies, and in many cases the incentives align a lot. The whole stack here seems like something that you can run internally / self-host:

- Codespaces are specially-configured containers. All the standard infrastructure for running containers (Docker, Kubernetes, etc.) is FOSS and is quite reasonable to run internally. It's not even like OpenStack where it's a knockoff product of what the major cloud vendors run: it's literally what the cloud vendors run.

- Shallow clones, pre-built running containers, etc. are all deployment practices, not products.

- You can ssh into a codespace.

The big problem here in my eyes is that it's reliant on VS Code, whose remoting stuff is not FOSS (and, having tried it at my own workplace pointing it at our self-hosted Kubernetes, it's been a pain to get it to work well with our authentication setup, proxies, etc. without access to the code and we have a number of open bugs filed). I think the challenge is for a free-software IDE to adopt the VS Code model of the IDE running locally but executing code (including running the LSP backend) remotely.

And, in a sense, Emacs already supports this just fine with TRAMP. It's just that the experience of using Emacs and the experience of using any modern IDE (VS Code, any of the JetBrains IDEs, whatever) are very different... and none of them are FOSS.

If you have a FOSS IDE, I think you can get this whole setup working well in a way where you have autonomy over the setup and where you can understand the details just fine. And even if you're using VS Code, you can set all of this up in a way where you're not contacting any external services.

> VS Code, whose remoting stuff is not FOSS

Do you have more details on this? I thought VC Code just uses the language server protocol for remote editing, which supposed to be an open standard. What stops say neovim adding full LSP support?

edit:formatting

LSP is definitely an open standard and you can make that work just fine. What I mean is that the components of VS Code itself that do remote execution are not open source, so if it's VS Code that you're running, you're a bit at MS's mercy for how you make it work (my current issue is that it downloads a VS Code remote agent into the container, and that download doesn't work right inside our corporate network, and there's no way to modify that).

If you're not running VS Code, then this isn't relevant to you and I'd imagine you can get a good experience via Neovim using LSP + netrw.

> The direction the web is taking is worrisome.

It's 100% economic. "Everything has to be free" means there is no money to be made in selling actual applications. That means the industry pivots to SaaS since the cloud is DRM and by running apps remotely you can charge rent and make piracy impossible. As a bonus you get the user's data, which you can do anything you want with in most cases.

As a bonus SaaS can also claim to be open source if only the client code is open, or if all the code is open but the SaaS still holds all the data and has the network effect. So you get those open source virtue points for free while still locking up the data or the network.

Of course the other response to "everything has to be free" is surveillance capitalism.

> If they start off with things like that, there' so much magic under the hood, they won't understand how anything works.

I feel like there's an ever growing tension in software development where magic like this makes us more productive but also more vulnerable.

Maybe we need to develop better benchmarks for "knowing enough" so when the magic fails, we're not starting at zero trying to figure out what went wrong.

Hire wizard consultant to fix magic and let the rest to rely on magic.

Why should you own your code or your device?

Why should you trust your computer?

Why should your career be safe?

People are fungible resources to be used when convenient and agreeable. Say or do the wrong thing, or have your utility dip below a threshold, and you can be removed.

It's happening.

> The issue is not so much senior devs, but new devs. If they start off with things like that, there' so much magic under the hood, they won't understand how anything works. They don't understand they don't own shit until it's too late.

Any good CS/Engineering program should have the students build and use a dev environment they configured to their liking.

If the only dev environment used is wrapped into some IDE magic I would be very skeptical of the program.

My biggest fear is giving up control to corporations. It starts with the honeymoon phase and once they control the market... they can dictate who has access, pricing, government backdoors etc...

jamstack is very fucked up to me, glad I'm not going crazy. you basically offload EVERYTHING to 3rd parties.

There's nothing about jamstack that requires you to use third-parties (except the CDN part, I guess, but that's just a mirror). You could just as easily host your own CMS and database and call out to it the same way.

It's just that like auth, logging, etc, CDNs have been neatly abstracted out and service-ified in such a way that it's often more economical to go third-party. But that choice is orthogonal to jamstack.

I agree on that, and was going to add that, to be fair to the stack. But the reality is, while that's doable, most people just use third-party services, at least that's my experience.

Sure, but I think that's true in non-Jamstack code as well. Datadog, Snowflake, BigQuery, DynamoDB, Google Analytics, etc. are all examples that I've seen used by non-Jamstack software, and most have a fair bit of lock-in.

jamstack certainly presents itself first and foremost as "use third party services".

I initially learned about it because a junior dev asked for advice on one of his/her apps. It was a college app, simple, it just gathered info from students. But, they offloaded all data to a third-party database. So you are actually giving a company a lot of sensitive, personal information about a fucking college.

He/She was concerned (and with good reason) about the safety of data. Had to learn the bad way :(

I would trust a service by junior devs more if it was hosted by a third-party database because so many companies have insecurely set up their environments over the years. Especially if the data is encrypted in a way the service can't read it, what would be the harm?

It's amazing how github is not open source, the biggest host of open source software is closed source?

And it might be fine as long as underlying building blocks are open sourced (git, etc).

There are open-source alternative(s) that support import of most things from github.

The real problem that Codespace for stuff like the GitHub codebase solves, is not having to bring up the dev environment. Non trivial, organically certifiably grown commercial software has bunch of services that all eat different things in winter. And things like the Rails monolith that GitHub's main service is, have a tendency of being rude to a dev's laptop, squatting the place with whatever port and file they want laying around, installing packages and software to variously namespaced-or-not locations. If you deal with any set of service, they'll all have various hygiene standards and run well or not on your machine, depending on wether your machine looks like the core dev's machine. And then everyone famously wants a custom work machine with freedom to manage it however they want.

Codespace stuff is a way out of insanity. It's a mediated common ground. You could standardize on Docker or Vagrant or whatever, but they come with a lot of pitfalls and the local dev story with them all kind of suck. Codespace on the other hand is a solution that mostly doesn't suck. It's actually a pretty decent experience.

Sure. Until you get your account banned because you went againts of obscure TOS clause, or because a powerful entity put pressure or paid their way into it.

Can't wait for the equivalent of abusive dmca to be able to put down your entire dev team.

It's really a way out of madness.

Doesn't docker solve all of this? It has for my group, even using C++, which is notoriously finicky. You can version control your docker file and bootstrap a dev environment in minutes.

> And things like the Rails monolith that GitHub's main service is, have a tendency of being rude to a dev's laptop

FUD. Everything is neatly handled by rvm (or rbenv) and bundler. You can even use gemsets if you want to be really anal about it. It all goes in version-controlled user directories. I keep my main Mac machine, my work Windows machine, and the production Linux boxes all running the same versioned stack just fine.

What do you mean FUD? Maybe you've got your own way of doing things that works well so far for you with your current projects, but a ton of people don't live with the same experience, and when they do reach a comfortable spot, it's only comfortable until they move to a new set of projects or company.

I'm saying that, while a top-tier, software-as-a-service company might have a development environment that is hard to bootstrap -- because of all the ancillary things that run alongside the "monolith" -- your generalization that "Rails" makes a mess of a development machine is FUD. The Ruby/Rails part of this equation is not the issue. As always, YMMV and TACMA.

I didn't say Rails makes a mess of a dev machine. What I'm saying is that every project makes different sort of assumptions about how it's brought up in a dev environment, and these assumptions vary wildly between projects and stacks, and usually the older and more prominent a project is, odds are it will have the most unexpected impact on anyone's machine. This is going to be true for any combination of libraries, frameworks and programming languages.

I'm not mounting an attack on Rails. Rails' fine.

(Edit) I can't answer your reply. It seems there's many ways to read the quote you brought up. I'm clarifying that the meaning I intended wasn't an attack on Rails. Take it as you will. I'm a bit confused why my original comment, which I meant as a positive-to-neutral tone, is being perceived so negatively.

> I didn't say Rails makes a mess of a dev machine.

I literally quoted you saying that in my first post. But hey, what do I know?

Codespaces doesn't magically solve that problem. You have to put in the work and ongoing maintenance effort either way.

Yeah but if before we had MxN complexity:

  - M: number of devs with their own machine
  - N: number of projects with their own way of bringing up dev env

Using stuff like Codespace reduces M to 1.

There are dozens of tools and strategies to reduce M to 1. Codespaces is just one of them.

Codespaces has the disadvantage of turning you into a renter.

I believe codespaces does directly rely on docker containers that you can customize…

Such a stale take. Can I assume you are pretty much against the cloud in general?

I'm not against the cloud, I use it in a daily basis. I don't mean you have to phisically own your servers. But it's not the same, to me, having your MySQL or Posgres DB up in the cloud, than using things like Firebase.

I just don't like the direction of moving the development environment to the cloud. It makes it easier to just consume third-party services and a) Don't understand how anything works, and b) Don't own anything.

If you know, fully aware, what the cloud implies, then sure, use it, but it's dangerous when the decision comes out of ignorance.

I guess there's not really much you can do about it though. People will do whatever is easier, and not everyone wants to know how things actually work.