longrod

I think this is nothing except shitposting. The whole blog reads like an angry rant of someone who didn't get what he wanted. This is not new. Layoffs are not a new thing. New management, new rules, it's always been like this.

Do I feel sorry for the people who got layed off? Of course I do! I wouldn't want to be them right now. I feel for them. But the consequences mentioned in this post is completely unreasonable. These are the kinds of points you hear from a depressed person who thinks the world is going to end because all the toilet rolls are suddenly out of stock.

The amount of doomsaying I see everywhere regarding the Musk takeover is baffling. I am no Musk fanboy but this is completely irrational. The fact of the matter is, people don't like change. That's all there is to it. Change automatically makes people cry out.

Here's a scenario for you:

What if the new Twitter is better? What if it isn't the toxic place you expect it to become? What if you are completely wrong? Have you considered that? Here's how I see this situation:

Musk is not an idiot. He must know exactly what he needs to do. This isn't his first rodeo and comments like "running a service of this scale and size is incredibly complex with downtime and uptime and blah blah" is incredibly naive. Musk runs at least 2 companies that require a huge network & availability guarantees. He knows what's needed there.

Twitter is going no where and if you think it'll go down in the coming years, you have a surprise coming your way. I am optimistic because of Musk isn't known to give up. This can fail for sure but I don't think that'll be the end of it.

The next step in my opinion is cutting down on the Twitter codebase. Trimming features. Shutting down unnecessary stuff. They laid off 25% of the workforce so at least 25% of Twitter will be affected. Let's see which parts though. There's a lot of unnecessary junk in there (communities, spaces etc.) that I'll be happy to say goodbye to.

Sucrase is proof that JS is not the problem when it comes to slow performance. JS is not slow. NodeJS is not slow. It's the code that is slow. All these people wanting to write it in Rust or Go or XYZ programming language need to acknowledge this.

Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as it is being spent to rewrite it in Rust, I have no doubt that it can become faster. Perhaps it'll require some big changes but it won't create compatibility concerns and it won't be a cat-and-mouse race between the Rust version and the TS version.

I don't think "Write it in Rust" is always the solution to fast programs. Rust itself can be pretty damn slow if you don't keep performance in mind. That is why you have to optimize and profile and optimize over and over again. Can't the same be done for TSC?

I think the biggest reason devs don't do this is because no one likes profiling and optimizing since it is a slow and boring task. Rewriting is so exciting! It's the thing you do when you are tired of maintaining the old codebase. So just ditch it and rewrite it in Rust.

I have nothing against Rust, mind you. I love what it has done but I don't think rewriting everything is either feasible or even the solution. And waiting for that to happen for every slow tool out there is utter foolishness.

The audience is hackers as it should be. You can't cater to daily users at this stage. You want people who can potentially fix the bugs they come across or add the features they miss. A usable OS is no joke and it certainly isn't a one man project. If enough people get on this, it might actually become daily-usable.

I think people are looking at this the wrong way. It's not so much about the code as it is about establishing an authority. Musk takeover is often regarded as banditry and I wouldn't be surprised if the employees didn't take him seriously in the beginning. This is his way of saying, "I don't trust you, I don't know what you have been up to but things are going to be different so better get used to it."

Using Tesla engineers is just to get everyone talking. I don't think they can get a clear picture by looking at last 30 days of code but they can use this as reason to lay a lot of people off. Not that Musk needs reasons, obviously.

In my mind I think Twitter is going to go on a very, very different direction than we all expect. You have to understand that Musk isn't after the big dollar here but rather he is experimenting which has a lot of chances to fail. Twitter could become extraordinary or it could become utter trash, we'll have to wait and see. Personally, I am quite excited to see where this goes.

Thank you for sharing Andreas! It's absolutely phenomenal how far along SerenityOS has come and it's also a peek at how FOSS is supposed to be - a way to learn, hack on something fun, share it with others but without any huge expectations.

Building the next unicorn is awesome and all but in my opinion, this has it's own place. I am glad some people out there get to work on their dream projects and actually can make a living out it. Kudos to all the supporters, obviously.

I also love how focused SerenityOS is and what kind of audience it caters to. Some people might say, "make it for everyone" but that doesn't work most of the time. Having a focused audience allows a lot of freedom in the way of UX/DX, docs, communication etc. So I am glad Andreas set that down upfront.

HTML is not for writing but for creating UIs. That was why it was created anyway. Markdown was specifically created for writing. It has no other purpose.

Saying that Markdown is bad is really naive. There are not many ways to specify formatting without it getting in the way of your writing. Markdown is popular because it strikes the right balance where reading a markdown document requires a lot less visual strain compared to the same HTML document. It requires the least amount of letters to specify formatting - italics is 2 chars, bold is 4 chars, underline is 2 chars etc. Lists are mostly inferred and require no additional formatting. Compare that to HTML which requires 5+n chars (where n is the number of chars in the tag name) regardless of which format you want to use.

Markdown does have it's quirks but they don't come up 99% of the time unless finding them is specifically your intention. Knowing whether *__hello__* is bold italic or italic bold is not important unless you are writing a parser.

The downsides of Markdown are much, much less than the downsides of HTML. Writing is not the same as designing a website or a UI. It's not meant to be pretty and typesetting + styling should not be the concern of writers.

Looks cool but...why not just send the .ics file directly via your IM of choice? Am I missing something here? I don't see the benefit if you still have to click, open file in your calendar, add it to the calendar.

Can you tell me why the above wouldn't work and why this is better?