Zed should focus on basics. When it focuses on basics Zed is good.
<a href="https://github.com/zed-industries/zed/discussions/54150" rel="nofollow">https://github.com/zed-industries/zed/discussions/54150 failing to show newly created files and declining to provide a refresh button, instead adding a polling backend, breaks Zed on WSL.
Why a new version control system? Why not git, jj, or another existing system?
There should be a concept called "engineering privilege".
I see some companies do things that are widely out of their core product and engineers there just having fun with a bunch of different stuff with seemingly no commitment to bring in revenue. They'll re-invent/re-write things constantly, write a new compiler/package manager for their chosen language, create new frameworks, new open source projects unrelated to their companies, etc.
It must be awesome to be able to work in these conditions and still get paid. I'm not hating on it, it's how we get a lot of the good stuff we use.
Because every company may have different needs that are not fulfilled by standards software. We have seen the large number of companies whose goal is to make custom software for other companies So is not always that reinventing is fun, but it may actually be needed.
The same logic also applies for software that is used internally. It's not always that developers want to rebuild stuff, but that they need to rebuild or alter software to fit their / company needs.
We have not even talked about cost or licensing or other issues.
Yes except a lot of it isn't even fit for their purpose and they don't rely on it. Facebook switched from Cassandra to HBase because "eventual consistency is a difficult pattern". No shit, really?
> Every change is linked to the agent conversation that produced it. From any line of code, find the conversation. From any message, jump to the code it touched.
This is how Zed leapfrogs the field and becomes a centicorn.
If you can train a model to operate at a higher level and with looser requirements, you've gotten rid of engineers in the loop and built a system for the automated synthesis of high quality software.
You're training systems to produce higher quality chain of thought across the entire software development lifecycle.
My favorite example was from Joel Spolsky's company, where bright engineers got bored with working on bug tracking software so they wrote their own C# compiler.
It may seem weird nowadays but at the time it made sense since wasabi was "transpiling" VBScript (on which their existing codebase was written since they were all into Microsoft products at the time) to other languages in environments where VBScript didn't exist (e.g. IIRC they could transpile to PHP - and there isn't "one" PHP).
They were basically making shrink-wrap software running on an environment (the web) that wasn't made for shrink-wrap software (especially at the time) and came up with a technical solution to it.
FWIW they weren't the only to attempt something like that. HaXe is basically the same idea and was used to port a ton of games from Flash to all sorts of platforms and Monkey was another similar attempt (i think most people aren't aware of these two because they were gaming related and really limited to indie games).
> They'll re-invent/re-write things constantly
Re-invent is fine, that's how we actually get the good stuff we use.
Re-write (frequently) is usually a sign of bad power dynamics in the team, code rot and generally bad engineering management, in my experience.
That's why most React shops end up in this vicious cycle of constant re-writes of a perfectly fine working system for this reason. Yeah, must be really nice getting paid for it too.
Ah, but with re-writes you get to post those blog posts for Reddit and HN front page to drive traffic to the company's site, isn't that great?
Sometimes I feel like the software field is just begging to be "disrupted" by AI. So much bad management and useless wheel-spinning, all with salaries far above what is typical for any given area.
It's like taxis and Uber. Yes it's probably bad long-term that local taxi companies have been replaced by a mega-corporation. But there were so many bad taxi companies with rude dispatchers, lazy drivers, cars that show up 30 minutes late, drivers that don't run the meter, artificial supply restriction in NYC (medallions), etc. If taxis didn't suck so much, they might have been able to fight back better, and got more sympathy from the public along the way.
You see similar claims leveled at certain unions like the ILA and police unions.
And the cherry on the cake: you get paid to work on your engineering project, get traction around it as opensource and if there is enough traction, leave the company and spin-off a new one to sell the same product to other companies!
It's surely a lot of work but you get basically the discovery phase til market fit with your ass covered. Kudos to the engineers that pull that out, I really mean it!
That’s why nowadays every company will require that they legally own projects you work on during work hours unless explicitly asked. And many ask you to sign non compete clauses so you don’t take all the knowledge you acquired on the job to the competition, including your own projects, through this is quite hard to really enforce.
I remember thinking the same about a bunch of friends I know who were working at early GitHub. What are you all doing build a replacement Campfire? Omg, now there's a team building an IDE because they don't like Textmate? And dozens of similar ones I've forgotten over the years. But both of those lead to Electron, and Atom, and ultimately VSCode. Which given they ultimately ended up at MSFT probably didn't hurt when the acquisition conversations started.
> But both of those lead to Electron, and Atom, and ultimately VSCode
You just gave an example of 3 unprofitable projects.
That's pretty much my point: great that we got all of this stuff out of it but in any company not propped up by massive amounts of VC money you can't pay tens of millions of dollars in engineering salary for no immediate gain.
They're projects where there's not a payment page to buy a copy sure, but VSCode especially has I'm sure indirectly led to a ton a of profit - its the natural home of Copilot, integrated with Github (including in their paid product Codespaces), and has I'm sure led to a ton of standardisation and productivity increases across the company.
Correct me if I'm wrong, but the company that invented Electron was Github, and you could argue that Github's technical investments did all pay off very richly.
NoDodgeQuestion · · focus · HN ↗
<a href="https://github.com/zed-industries/zed/discussions/54150" rel="nofollow">https://github.com/zed-industries/zed/discussions/54150 failing to show newly created files and declining to provide a refresh button, instead adding a polling backend, breaks Zed on WSL.
Why a new version control system? Why not git, jj, or another existing system?
dlisboa · · focus · HN ↗
I see some companies do things that are widely out of their core product and engineers there just having fun with a bunch of different stuff with seemingly no commitment to bring in revenue. They'll re-invent/re-write things constantly, write a new compiler/package manager for their chosen language, create new frameworks, new open source projects unrelated to their companies, etc.
It must be awesome to be able to work in these conditions and still get paid. I'm not hating on it, it's how we get a lot of the good stuff we use.
tomnipotent · · focus · HN ↗
[dead]
benjiro29 · · focus · HN ↗
The same logic also applies for software that is used internally. It's not always that developers want to rebuild stuff, but that they need to rebuild or alter software to fit their / company needs.
We have not even talked about cost or licensing or other issues.
jeremyjh · · focus · HN ↗
plaxiotech · · focus · HN ↗
echelon · · focus · HN ↗
This is how Zed leapfrogs the field and becomes a centicorn.
If you can train a model to operate at a higher level and with looser requirements, you've gotten rid of engineers in the loop and built a system for the automated synthesis of high quality software.
You're training systems to produce higher quality chain of thought across the entire software development lifecycle.
This is training data for the next stage.
gcr · · focus · HN ↗
grey-area · · focus · HN ↗
When do you expect them to become a ‘centicorn’ based on this fabulous technology?
andsoitis · · focus · HN ↗
techpression · · focus · HN ↗
nocman · · focus · HN ↗
<Accept> [Decline]
FireBeyond · · focus · HN ↗
senderista · · focus · HN ↗
badsectoracula · · focus · HN ↗
It may seem weird nowadays but at the time it made sense since wasabi was "transpiling" VBScript (on which their existing codebase was written since they were all into Microsoft products at the time) to other languages in environments where VBScript didn't exist (e.g. IIRC they could transpile to PHP - and there isn't "one" PHP).
They were basically making shrink-wrap software running on an environment (the web) that wasn't made for shrink-wrap software (especially at the time) and came up with a technical solution to it.
FWIW they weren't the only to attempt something like that. HaXe is basically the same idea and was used to port a ton of games from Flash to all sorts of platforms and Monkey was another similar attempt (i think most people aren't aware of these two because they were gaming related and really limited to indie games).
ubercore · · focus · HN ↗
ChadMoran · · focus · HN ↗
neya · · focus · HN ↗
Re-invent is fine, that's how we actually get the good stuff we use.
Re-write (frequently) is usually a sign of bad power dynamics in the team, code rot and generally bad engineering management, in my experience.
That's why most React shops end up in this vicious cycle of constant re-writes of a perfectly fine working system for this reason. Yeah, must be really nice getting paid for it too.
pjmlp · · focus · HN ↗
gwerbin · · focus · HN ↗
It's like taxis and Uber. Yes it's probably bad long-term that local taxi companies have been replaced by a mega-corporation. But there were so many bad taxi companies with rude dispatchers, lazy drivers, cars that show up 30 minutes late, drivers that don't run the meter, artificial supply restriction in NYC (medallions), etc. If taxis didn't suck so much, they might have been able to fight back better, and got more sympathy from the public along the way.
You see similar claims leveled at certain unions like the ILA and police unions.
NoDodgeQuestion · · focus · HN ↗
manmal · · focus · HN ↗
darkwater · · focus · HN ↗
It's surely a lot of work but you get basically the discovery phase til market fit with your ass covered. Kudos to the engineers that pull that out, I really mean it!
brabel · · focus · HN ↗
phoghed · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
glenngillen · · focus · HN ↗
ajmurmann · · focus · HN ↗
dlisboa · · focus · HN ↗
You just gave an example of 3 unprofitable projects.
That's pretty much my point: great that we got all of this stuff out of it but in any company not propped up by massive amounts of VC money you can't pay tens of millions of dollars in engineering salary for no immediate gain.
jon-wood · · focus · HN ↗
dlisboa · · focus · HN ↗
My point yet again: only companies with money to burn can take that gamble.
conartist6 · · focus · HN ↗
worldthruword · · focus · HN ↗