This is why I love Notesnook and what they are doing with their app. Focusing on privacy, performance [0] [1] and their users. I am still amazed by the speed with which they work on different things. Definitely worth following.
Most features that appear to only be available in native apps can quite trivially be added using any cross-platform framework like Electron. Multiple windows is not something the is platform-restricted i.e. even web apps can do it if they try.
Have you given Notesnook a try? While it doesn't have multi window support they have it on their roadmap: https://notesnook.com/roadmap
Notesnook (https://notesnook.com/) - it's open source, has its own importer making it super easy to migrate, is fully cross platform, and doesn't force you to learn-and-relearn anything. It's note taking - just perfect-er.
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.
> Musk is not an idiot. He must know exactly what he needs to do.
How does this square with the attempts to get out of the deal? I think your points would make a lot more sense if he hadn’t signalled extremely clearly that he thought the deal was terrible.
There’s no evidence he wanted to walk away altogether - he just wanted to get the fairest price, and surely his investors/financiers would have been demanding he negotiate the best price he legally could.
I’m honestly flummoxed that you think there is no evidence and that you think this was his plan all along. We’ve all been very aware of what’s been happening since he made the deal in the first place. The ability to negotiate stopped then.
You don’t need to make excuses for him or pretend he is infallible!
The emotionally charged words and false/baseless assertions of my position and motivations in your comment indicate a strong attachment to a position.
I didn't say and don't think "this was his plan all along". I've done nothing to make excuses for him and I don't pretend he is infallible (indeed I once wrote an op-ed in a national daily newspaper examining his flaws [1][2]).
Occam’s razor requires us to believe what all the evidence indicates and nothing more: He was originally willing to buy it at the price offered in the prevailing market conditions in April, then the market crashed and suddenly the price he offered was too high, so he tried to negotiate/force a lower price (and we must assume his investors/financiers were demanding this as any professional investor/financier would), and when this failed he just went ahead with the purchase, which he always said he was committed to.
The only thing there is evidence for is that he wanted to reduce the price, just as anyone would after such a market decline. To believe anything else requires mind-reading, which you seem to be trying to do not only of Musk but also of me.
So, please, stop trying to read people's minds and just look at the evidence before us!
Sucrase is faster or really close to SWC (see rhe benchmarks https://github.com/alangpierce/sucrase). Everyone still uses Babel because of the transforms.
And yes, Babel can also be made faster if enough effort is dedicated into it. it's not an impossible feat.
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.
There was a back and forth on that subject a few years back: Mozilla rewrote their sourcemap parser from JS to naïve Rust (/WASM) for a 5.89x gain, mraleph objected to the need and went through an epic bout of algorithmic and micro-optimisations to get the pure JS to a similar level, then the algorithmic optimisations were reimported into the Rust version for 3x further gain (and much lower variance than the pure JS).
Sucrase consciously and deliberately breaks compatibility. Which, to be clear, isn't necessarily a bad thing for some use cases. But you can't really generalize from that to a tool like tsc where this isn't an option. There might be a performance ceiling here that can only be surpassed with a different language.
I suspect you have a point, given this line from the Sucrase readme:
> Because of this smaller scope, Sucrase can get away with an architecture that is much more performant but less extensible and maintainable. Sucrase's parser is forked from Babel's parser (so Sucrase is indebted to Babel and wouldn't be possible without it) and trims it down to a focused subset of what Babel solves. If it fits your use case, hopefully Sucrase can speed up your development experience!
I rewrote a card game engine, openEtG, from JS to Rust. It was a pretty 1:1 rewrite. 2x improvement even when I was using HashMap everywhere. I've since entirely removed HashMap, which has only further improved perf
I suppose it depends on your use case, but I don't really consider 2x to be a significant difference. Between programming languages we often speak in orders of magnitude.
If JS is only half the speed of a compiled language like Rust, that shows remarkably optimized performance.
Twice as fast is a big deal for damn near any program except like...unimportant, already slow background tasks or things that are already exceptionally fast. Cutting the frame render time in half could give you twice the framerate. Twice the performance on a server could let you handle twice as many concurrent sessions (and possible run half as many servers!). People regularly fight tooth and nail to squeeze 10% performance boosts on critical tasks, doubling it would be incredible
Plenty of game engines are already spending less than a millisecond of CPU time per frame in their own code, so 2x one way or the other makes almost no difference.
Things don't need to be "exceptionally" fast to be in the area where programming language doesn't really matter.
> Twice the performance on a server could let you handle twice as many concurrent sessions (and possible run half as many servers!)
Which might matter, or it might not. Very situational.
> People regularly fight tooth and nail to squeeze 10% performance boosts on critical tasks, doubling it would be incredible
That kind of task is a small fraction of tasks. And often you're best off using a library, which can often make its own language choices independent of yours.
JIT/interpreted languages (Java, JS, Python etc.) cannot compete with optimized code from compiled languages.
The tradeoff is that Rust is lower-level, so it is harder to write. If performance were the only point of comparison for a language, then we'd all be using assembly. We choose to trade performance for productivity when we're able to.
Average node.js app is slow. It requires godlike understanding/experience to make JS perform well. That why you see people re-writing JS to rust and go and zig, for example SWC, turbopack, esbuild and rome. For most use cases JS is plenty fast but average go code will be faster and easier to maintain.
As I am getting older, I do not want to spend my weekend learning about new features in next.js v13[1]or rewriting tests from enzyme to RTL[2]. I want to use programming language that value its users time and focus on developer experience.
Not sure if serious or not, but Firefox is a long-standing example of this. It has always been a mixed C++/JS codebase. (Since before it was even called Firefox, that is, though nowadays, it's also Rust, too.) I routinely point this out in response to complaints about the slowness attributed to e.g. "Electron". JS programs were plenty fast enough even on sub-GHz machines before JS was ever JITted. It's almost never the case that a program having been written in JS is the problem; it's the crummy code in that program. When people experience Electron's slowness, what they're actually experiencing is the generally low quality of the corpus that's available through NPM.
Arguably, the real problem is that GCC et al are enablers for poorly written programs, because no matter how mediocre a program you compile with them, they tend to do a good job making those programs feel like they're performance-tuned. Today's trendier technology stacks don't let you get away with the same thing nearly as much—squirting hundreds or thousands of mediocre transitive dependencies (that are probably simultaneously over- and under-engineered) through V8 is something that works well only up to a point, and then it eventually catches up with you.
Besides, there's no such thing as a fast or slow language, only fast and slow language implementations.
AFAIK all of the major browsers (and other JS runtimes) have implemented some performance-sensitive APIs in JS, specifically because it performs better than crossing the JS<->native boundary. Granted that’s usually specifically about JS API performance, but that’s a lot of where performance matters in a JS host environment.
How far can you get with JS/other interpreted things in e.g. optimizing for cache access etc? Sounds like you're at the mercy of the JIT compiler (which may go far, but still).
The interesting question to ask is whether these Rust rewrites are really taking advantage of cache optimization or if they are making simplifying assumptions that the canonical implementation cannot. In the latter case, Rust isn't the root of the performance difference and a JS rewrite can make most of those simplifying assumptions
JavaScript does not have any input/output (IO/syscalls) all those functions like reading a file, socket, etc needs to be implemented in the runtime language, like the browser, Node.JS, ASP, etc. So you are at the mercy of the runtime executable. The JS JIT slows down startup time as the JavaScript first have to be parsed and compiled before running, but the runtime can then cache the compiled version for faster startups. When JavaScript was new it was slow, for example string concatenation was slow, but most JS engines now implement string concatenation with a "rope" structure making it very fast. v8 (Chrome) and Spidermonkey (Firefox) have got a lot of optimizations over the years, so if you are doing things like incrementing a number in a loop it will be just as optimized as something written in a systems level language.
This can vary a ton as well. I was talking to a friend yesterday who said he was pounding a native browser interface with an iterator and experiencing slow performance. He switched to buffering the entire thing into memory first and experienced huge performance gains.
The aspect of the language you're using, if optimized, is virtually always optimized for the most common use-case. If your use-case isn't the most common use-case, you must account for this.
With stuff like TypedArrays pretty far. Where JS has problems is optimising in the face of the things you can do with the language and the current difficulty in multithreaded implementations.
As someone that contributed to swc-cli, surcease benchmarks are pretty bad. SWC run in sync mode, blocking main thread, in addition they are not using benchmark.js or isolated tests.
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.
Why would anyone take him seriously when he is making a massive embarrassment of himself on his first day on the job (after doing the same for months leading up to the takeover?)
Musk didn't know the bio of the CEO of the company he was buying (who was also former CTO, engineer, Stanford PhD (thesis topic: making decisions under uncertainty), IPhO gold medalist, top tier Indian tech student) and called him a non-technical "manager type" and refused to ask him any technical questions.
I am also excited, because I think Twitter needs to end and Musk is the perfect person to destroy it.
Why does Twitter need to end? Have you before and do you currently use Twitter? I've met and talked to a great deal of cool people on there, such as a lot of prominent people in the web dev space, as well as scientists in various fields.
Twitter is just a social network, it can be used for good or for bad, based on who one follows. That people think it needs to end for whatever reason (or maybe they're only used to the bad parts, or have even never used Twitter which is quite a many people in my experience who talk trash about Twitter) is misguided.
I agree it shouldn't end, but what I do wish would end is the new media reaching for tweets to pump drama for engagement on their platforms. The economy for attention is just exhausting as an end user, even if I agree with what's being said.
No, I do not need to be informed about X person who said Y thing on Twitter of all places, told to me from talking heads I've never heard of, that want me to be outraged for all the reasons they hate X person or Y statement.
Maybe it's not Twitter's fault, rather people using it as a tool to foment hate on principal. It's certainly not from being well informed via the platform or the news media. Thank God IRL people don't work that way.
I use Twitter and I think it needs to end - at least in its current form. It has a very low signal-to-noise ratio and doesn't offer the users adequate control over what they see. As an example, you may not want to see (re)tweets on Baseball from the prominent Web Dev space folk you follow, or the off-topic comments by trolls in replies.
> Twitter is just a social network, it can be used for good or for bad, based on who one follows.
...and the people that interact with them. There need to be more receiver-side controls. Blocking tweets by words is a first step, they should have opt-in filter by subject and raise the bar on replies that ride the coat-tails of authors authority.
Much of the toxicity and misinformation on twitter stem from the fact that there are no controls to filter out the garbage on the receiver's end, but there is a perverse incentive dir tweeter not to add these controls because the more tweets they see, the more ad slots Twitter can fill.
Well, maybe because he’s the richest man in the world? Or maybe because he’s the CEO of several of the most valuable public or private companies in the world? Maybe because he practically single handedly willed the electric car industry into existence? Or maybe because he’s revolutionized the rocket industry? Or…or…or…
Elon hasn’t whiffed on any business venture in decades. Nothing but net.
But you wouldn’t think that listening to all the “I am very smart” people on this forum. This guy, one of the most successful people in all of human history, is apparently an idiot and no one should take him seriously. He will surely run Twitter into the ground because… because… because reasons.
These takes are outright comedy. Fine if you don’t like the guy, I surely don’t, but good grief you’d think he was pissing into bottles like Howard Hughes.
I think respect is earned, not an entitlement due to someone's ability to buy a company. There are plenty of bad bosses who should not be taken seriously.
Technology is famous for inverting the classic boss vs lackey relationship. Without an engineer, the boss cannot build what they want. Engineers are your eyes and ears, they're the ones who can tell you if an idea can or can't work... and ultimately are the ones who will build the products.
Twitter engineers are the ones best positioned into knowing what is or isn't possible with Twitter's codebase, for whatever the heck Elon Musk wants to do with the code.
If Elon thinks he can just walk in with a bunch of Tesla engineers and have his trusted Tesla programmers figure things out, he's gonna be in for a surprise. Programming doesn't work like that, it often takes 6+ months for a set of engineers to reach competence with a codebase.
---------
There's a myriad of stories about how "bad bosses tell engineers what to do, instead of listening to them" around here. Why? Because we're largely a set of programmers / hackers on this discussion site. We all know how bad management can be.
What Musk is doing right now? Obviously and clearly bad management. Musk has no trust over the Twitter engineers at all.
Rights and obligations go hand in hand. Want to tell your boss what you really think about em? Sure, you can do it any day, just better have some savings and an alternate source of income :).
Disclaimer: Self-employed so I don't have to deal with that.
I have failed to source this claim after some searching:
> Musk didn't know the bio of the CEO of the company he was buying (who was also former CTO, engineer, Stanford PhD (thesis topic: making decisions under uncertainty), IPhO gold medalist, top tier Indian tech student) and called him a non-technical "manager type" and refused to ask him any technical questions.
Is there some news report you’re referencing or some non public information you’ve been privy to?
"funding secured"
"pedo guy"
and this total twitter fiasco where he was forced to pay premium to buy it.
These are few examples where he made fool of himself.
Though, people can be super smart and yet so stupid at the same time. It doesn't have to be binary. (Who am I to judge though!)
On the “Funding secured” part, I think he has proved in court (Musk vs SEC) that to the best of his knowledge, funding was indeed secured and the Arab sheikhs ditched him later. He shared text messages in the court.
And after the dust settled, it was just a couple of oddball blokes exchanging insults like children. The diver who started the fight, got greedy and wanted $190 million in damages over the pedo comment. Jury deliberated for less than an hour, and he got nothing.
In the end, the Thai Navy got a free mini sub they said could be used in future rescues. I don't see the Twitter incident with the diver as any final verdict about Musk in general, other than he can get emotional and doesn't hide behind corporate speak. The Diver-guy's initial attack really was the first foolish action in that whole saga.
Only incompetent managers (and executives) think that "authority" is interchangeable with "respect". Fortunately for Musk, incompetence rarely disqualifies billionaires from anything.
There's no way Elon would have any respect yet, there hasn't been nearly enough time (respect is earned).
There are going to be power games for a couple of months, until the new management identifies a subset of the old staff that they can trust (or, more cynically, exploit), and then that subset will be elevated above the rest. The losers will either back down, quit, or be fired.
I'm not sure you want to use "value of his companies due to things he says" as your marker for incompetence. Many of his companies are seriously overvalued precisely because the things he says drive up the value far beyond where it should be.
Someone can be incompetent at some things and not others. We know with 100% certainty that Elon Musk is incompetent at purchasing Twitter dot com in a way that is most financially optimized for himself. We know with 100% certainty that Elon Musk is exceptionally competent at procreation.
Every company I was with when it sold had lawyers come in and inform everyone that all processes are frozen, no equipment can move or be transferred while inventory is taken, everyone involved with computers surrender their passwords to their incoming engineers... etc, etc, etc. It is standard practice and there is nothing nefarious about it.
What you call entitlement sounds to me something more like self-respect. If I was asked to show the last 30 days of my code to a random engineer from another company to prove I deserved my job, I'm pretty sure I'd quit on the spot. (Though if I'd worked at Twitter I'd have gotten out months ago; I imagine the people staying through today have fewer options for whatever reason.) Luckily there's still plenty of work for programmers at companies that understand that impact isn't usefully measured in lines of code.
My comment was more about spending Tesla money on Musk's personal projects. I also think it pretty insulting to have to justify your job to some random engineer from Tesla.
> It's not so much about the code as it is about establishing an authority
I think there's a simpler explanation: he intends to fire people under the pretext of poor performance and play games with layoffs/severance and/or create a hostile environment to encourage employees to resign (no severance either).
> 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
Musk wanted out of this purchase, but discovered the Delaware Court of Chancery far less malleable compared to other regulators he's dealt with before (looking at you, SEC). Tesla is going to be a learning experience for Elon.
> I think there's a simpler explanation: he intends to fire people under the pretext of poor performance and play games with layoffs/severance and/or create a hostile environment to encourage employees to resign (no severance either).
Based on the reports that came out after your comment that he doesn't want to pay the execs their severances, I think you're spot on.
> I don't think they can get a clear picture by looking at last 30 days of code
I can very quickly spot developers who are mediocre or worse by looking at their last 30 days off code. (As long as it's a language I have decent experience in.)
I suspect he's trying to access the team's technical competence.
No you can't because being a good developer isn't always about smashing out code, I've easily spent 30 days with great developers talking about planning and implementation before much code is written.
Hopefully it's not you who is the mediocre developer?
Err, there are very obvious "beginner" mistakes that don't have to do with "smashing" out code:
Things like: State in strings instead of properly defined enums / data structures. Magic numbers instead of constants. Dangerous error handling. Compiler warnings. Missing or incomplete input checking. Anything vulnerable to SQL injection, or similar. Significant copy and paste within the same codebase.
When a developer with more than a few years experience writes code like that, (except in throwaway situations,) then there's a clear problem.
More subjective signs of a poor coder are: Super long methods, (or too many sort methods.) Passing around a single value but always picking a new variable name. Inconsistent naming conventions. Sleep statements to fix race conditions. Unnecessary special cases. Incorrectly using an ORM. Code that is many orders of magnitude slower than need be. (IE, sucking the entire DB into ram for just one value.)
Some language specific warning signs: Lots of "unsafe" (pointers) in C#. Lots of unwarps in Rust. Bounds issues is c/c++.
This is all assuming that a coders job is to just code...and make code better, which IMO it rarely is.
Honestly, the most lucrative code bases I've worked on are generally considered terrible, annoying, incorrect, frustrating but they are functional.
The most recent example I can think of was a startup I worked which sold for billions of USD, it was considered by everyone as terrible.
A large part of our job was understanding complex requirements and integrating with other companies poorly implemented APIs, wrangling XML etc, so we didn't code a lot, we planned a lot.
Fundamentally I think we're just talking about different aspect of the job and we disagree that being a "coder" is about lines of code.
In my current job, I've been helping my team, especially new comers understand complex systems and business logic which we didn't have a lot of time to document because of the insane growth our company went through and the insane amount of stress we were under to deal with demand with only 2 engineers. I've not written more than 20 lines of code in 4 weeks, really just mentored and guided people, should I be fired?
I would probably say that your role isn't a "coder," but is more of a team lead or manager without the title. Other than that, I don't understand your situation well enough.
I also haven't reviewed your code!
But if you are specifically writing code that has the kind of errors that I describe, or are continuing to "add fuel to the fire," I would set very clear standards and expect that you meet them. I understand that you can't fix every problem overnight, and that you have to pick and choose the things you fix carefully.
But if you continued to, for example, write code that was vulnerable to SQL injection, after I made it clear that this was no longer acceptable, yes I would fire you.
Edit: Likewise, if you were reviewing someone else's code and allowed SQL injection, I would consider you "the source of the problem" and fire you. If your "20 lines of code this month" contained SQL injection, I would wonder why, after setting a clear expectation that SQL injection isn't allowed, you couldn't take the extra five minutes to write parameterized SQL, and then and fire you.
To add to my reply from a few hours ago: I'm currently fixing a bug like what you describe.
The code is C# and involves heavy reflection; but if the person who wrote it used a simple lambda, it would be fine and easier to maintain.
In such a situation I'd make it clear that reflection is inappropriate in this situation. If the developer continued to use reflection when simple lambda statements were appropriate, I would make moves to fire the developer.
I suspect that not much will change for users. The folks who want to continue tweeting will do so. The folks who do not want to tweet won't. Everything else is office politics.
Yeah, I don't see the problem. Tesla investors benefit from SpaceX material science expertise solely because Elon owns SpaceX and allocates the time and resources. I don't see Tesla investors complaining about that.
I would view it as a way for Tesla engineers getting paid to go to a software conference. It is definitely possible to learn something during the code review to take back to Tesla.
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.
This is the thing that confused me. What exactly is the audience for this? It seems like more of an intricate art project than a useful piece of software.
Maybe it will also be useful some day, maybe not, but to me at least that's not the point. It's really cool that we can fund some art projects like this in the software industry!
Not a perfect comparison, but it's like how some people approach math simply for the beauty of it. That's enough of a reason! And sometimes that math ends up useful too - maybe because math has a connection to reality. So does software - it runs.
The audience is the people who contribute to the art project and want to be part of the community. A community that serves itself for no other reason than to serve itself. Seems like a good time to me
This has educational value. If you are wondering "how this part of OS would be implemented" you can look up how Serenity team did that. Also even more interesting is trying to implement this for yourself (for Serenity), if you are brave enough.
Well, more or less, at the moment it’s for fun and art. It’s recreational. Odd thing is that SerenityOS has made so much progress so quickly that it may soon be a viable daily-use operating system.
It has a nice consistent ui toolkit that seems highly productive. I hope the user-space (window manager, default apps) eventually becomes an alternative linux user-space.
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 was wondering the same. Nothing against the project, but from reading about it I’m confused why I would choose this over my preferred OS (and therefore how it makes enough money).
But then again there are so many distros it’s not that surprising.
It continues to baffle me how a newsboard called hackernews has countless people who are incapable of seeing the value in making something for the sake of making it.
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.
Html was absolutely created for writing, though it later got hijacked as a system for creating UI's inside of the browser doing the browser wars of the 90ies, but if you look at the original specs, it's a way of marking up documents and it was very much readable even without a rendering engine.
Prior to html and the web revolution people would use different macro packages for either troff or TeX and, and in the first years of HTML people would absolutely write it by hand thinking very little of it but then again that was before style elements css and javascript.
After the browser wars almost everyone who working with documentation had their own perl, or ruby scripts to take some simplified markdown syntax into html and there is of cause a risk of markdown itself getting bloated to the point where people need scripts to turn simple meta formats into correct markdown.
[0] https://twitter.com/notesnook/status/1591048432931975168 [1] https://twitter.com/notesnook/status/1588602471290572800