C++ build times get high only if you start messing with the type system and ask for it to be recompiled every single time again and again.

Rust is slower overall, which is why people tend to complain. And if you start messing around like in C++, then you get even crazier times.

But in neither case it is a dealbreaker compared to other languages. Go proponents claim compilation speed is everything, which is suspicious. I do not need to run my code immediately if I am programming in C++ or Rust. And if I am really doing something that requires interactivity, I should be doing it another way, not recompiling every time...

I think it's fairly naive to say build times get long "only if you mess with the type system" whatever that means. It's pretty easy to tank your compile/edit/debug cycle just by adding or removing things to a header file. Maybe modules will improve things.

I've worked in C++ code bases with just a few 100k loc where one starts architecting the software to avoid long compile times. Think about how insane that is, you choose to write and structure code differently as punishment for the sin of writing new code. Not to improve the software performance or add new features.

The worst example of this is the pimpl pattern. You make th explicit choice to trade off compile times to hide everything behind a pointer dereference that is almost guaranteed to be opaque to the compiler, even after LTO, so the only "inlining" you may see is from the branch predictor on a user's machine. That's bonkers!

Of course compile times increase with code size, that is not what people are talking about when they say "X language compiles slowly". They are talking about time per code size.

Messing with the type system is using it for things you really should not in any reasonable project. For instance, some of the Boost libs with their overgeneralizations that 99% of users do not need.

>"only if you mess with the type system" whatever that means

I think they're talking about the STL.

Boost.

Having a fast feedback loop helps with staying in the flow. Compile times need to be short for this.

That’s why you write unit and integration tests :) That’s how you get a fast feedback loop, instead of looking for it in compilation

What is "staying in the flow"?

Recompiling fast helps the most when learning to program, but not for actual applications with some complexity.

Many applications do not even have meaningful output by just running it, for instance they may take a long time to compute something meaningful.

> What is "staying in the flow"?

Run the code (with some debug logging statements, very likely), find a small mistake, make a few characters worth of correction, press your IDE's keyboard shortcut for recompilation and re-running.

If the last step is slow you can lose momentum and motivation to iterate quickly on the problem at hand.

Sure it doesn't apply to a lot of projects, that's true. But it's not charitable to claim it only applies when learning.

it depends on the problem domain. when working on say a desktop app with graphical ui features it can be very useful to be able to change/experiment quickly.

with an n tier web application you wont often be able to do that anyway.

And this is why in its current state you wouldn't be seeing something like RustUI or Rust Playgrounds.

> ... web pages that talk to ... health devices ... there is no way to block ads in an app

Wait, what?? Why on earth would you use an app with ads for health devices?!?

Moreover, why on earth are you using apps with ads for anything?

Please, please, please, pay for your apps and games. Stop making everything an ad service. The race to the bottom in the web and mobile world is disturbing.

Would you want to pay for your house plumbing by being forced to watch an ad every time you shower? Think about how dystopian that sounds. There are even Black Mirror episodes on that.

> Wait, what?? Why on earth would you use an app with ads for health devices?!?

GP said they want to _write_ a web app that talks to health devices. And that they like the web platform because it's easy to block ads shown to you by other web apps.

I will add that it's also easier to detect/block tracking. Browsers such as Firefox even try to do this for you these days. And to generally examine what the app is doing (e.g. by running it in JS debugger).

Yes, paid apps usually (but not always) remove ads. They keep the telemetry, though.

> ... web pages that talk to ... health devices ... there is no way to block ads in an app

You’ve selectively mixed two paragraphs to change the meaning of what I actually said.

I did not say I want to use apps with ads with health devices, at all. That’s a complete straw man.

I said I want to access my own sports equipment via Bluetooth from a webpage I’ve written myself.

I also said that I dislike apps because the user looses control over things like tracking, selecting text, zooming and whether adverts are shown.

On the privacy end of things, ads certainly aren't helping, but a pretty large number of even paid apps are happily vacuuming up data and sending them to the developer and often third parties (vendors of analytics/debugging platforms in particular). I tend to think of an app for most things as a loss of privacy and try to avoid using them when possible.

There are many apps that continue to show ads even in their paid version / upgrade. Might not be an option for him?

Why would you ever want a PWA when a native version exists?

And "heavy client" is a fallacy. Operating systems come with runtimes too. Very complex native app can be very small in size if it uses the native controls and APIs. They can be KB in size. Any asset is going to be bigger than the binary itself.

The web-as-native apps are the ones that are huge, because they embed a behemoth (a browser) which is akin to an entire operating system.

PWAs run from the browser sandbox which is generally much stricter than restrictions for native apps. Permission systems for native applications seems to be starting to follow browsers (flatpak, snap, .appx, etc.), but don't offer nearly the ability to restrict what a native app can do like the browser does.

In theory native apps are "trusted", but I think for the vast majority of users the trust between a companies website and app are equivalent, vetted the same, and probably do an equivalent amount of tracking if not more by the native app (facebook SDKs are pretty common in native mobile apps).

I already have a browser, and the PWA uses that.

That's not true at all! Free native apps abound. Web apps tied to subscriptions are also plentiful.

Open source is neither here nor there: both web sites and native apps can be open source. In fact, the web is unique in allowing you to actually inspect the source that is running on your machine, you have no way of verifying that the code in an open source repo is what actually runs inside your iOS app.

> In fact, the web is unique in allowing you to actually inspect the source that is running on your machine

To be fair, this is changing with WASM. On the other hand, there are tons of obfuscation opportunities with native executables that don't exist for WASM.

What about Facebook? A native app, free, tied to a business and utterly motivated to violate your privacy.

> False: you can definitely verify that a binary matches the source code in deterministic builds

If I want to check an app I have installed from the iOS App Store matches the code provided in an open repo, how would I go about doing that?

>Truthness: many webs are obfuscated on purpose like native apps are.

True. But their underlying behaviour, i.e., what data they send and where they send it, is viewable and blockable by browser extensions.

I agree overall, but:

> That's why you pay $1000 for a phone, so the manufacturer protects you from these risks.

is wishful thinking. You pay 1000$ because that is what people is willing to pay.

The average customer is not paying 1000$ for getting "protection from those risks", and it is that customer that drives the price, not the average user in HN.

And that is assuming they are trying to "protect you", but that is a different discussion.

> they are trying to "protect you"

They certainly are trying to protect you but I am not naive to think it's out of the kindness of their corporate heart. It's because that's what many people want right now. Apple tried to compete with Google and Facebook at their own game, predictably lost, so changed the rules of the game. Which was a brilliant strategy and if next year they change their stance I will happily reconsider my opinion.

And people don't have to know explicitly every feature and how it's achieved technically. The phone is now almost a commodity, like toothpaste. You buy one because that manufacturer built a trust. You probably buy Colgate, Sensodyne, or OralB (Crest). But not because you carefully analyzed their chemical composition, or pored through study after study. You just trust one, a friend or dentist recommended it, it just works for you, and so on.

That protection the phone affords you may not be immediately apparent but enough people start noticing eventually even if they don't understand the underlying technical part.

A thousand dollars is 1/12 of the average Chinese annual salary

That's why they buy 99$ phones

You're comparing a few millions people living in SV with billions of people making less than 10 dollars a day and assuming that they have the same PPA and that they represent the entirety of the World's user opinions and/or will

Average users won't do it.

Epic paid obscene amounts of money to studios to force them come to their store and force exclusivity on them.

They basically exploited their Fortnite money-making machine to try to become a monopoly on PC.

How is that not anti-competitive?

For reference, Steam has never forced exclusivity on partners to distribute their games.

As for cheaper, Epic didn't become they couldn't charge the same. As simple as that.

How is obscene amounts of money forcing anything?

This sounds good for developers all around, and a minor inconvenience for gamers who are free to buy from as many stores as they like on PC. Yet could benefit gamers long term as it motivates Steam to be more competitive.

Anti competitive would be buying up competing battle royale franchises to reduce consumer choice.

Intel vs AMD in the past is a typical example on how money + exclusive deal could almost kill off a competitor.

Then Intel would enjoy a monopoly and instead of being stuck at Skylake for 4 years, we may have been stuck at Core 2 for 10 years.

Or maybe ARM, MIPS, Power or Itanium (!) would have had better opportunities to catch up with x86 and would be the dominant CPU.

Who knows, but AMD dying would have not benefited anyone who was stuck on x86.

Except Intel was the behemoth in the case. Here Steam is the one with marketshare, mindshare, and no serious competition before Epic. These exclusives are also usually time limited. This isn't Facebook buying whole studios and locking up content indefinitely.

> How is obscene amounts of money forcing anything?

Indie game studios have a very hard time surviving.

Giving them instantaneous access to a huge pile of money that allows them to declare success even before releasing a project is something most people cannot reject.

> Anti competitive would be buying up competing battle royale franchises to reduce consumer choice.

That is what they are doing but with game stores. They are effectively buying everything to dry the rest of the stores, reducing other stores choice of customers.

> This sounds good for developers all around

Not really. Devs get money, but they lose the product. Indie devs are not independent anymore. Etc.

If Epic had success building the monopoly, everyone would have suffered, not just devs.

What monopoly? There is a monopoly today; it's called Steam. It has an immense userbase and plenty of user loyalty; it's not going anywhere. If Epic succeeds, there will be two major stores rather than one.

Steam isn't a monopoly though. They don't force exclusivity on their games and many Steam games can be purchased elsewhere (like on GOG).

>Steam isn't a monopoly though

Are you a pc gamer? Because if you are, I don't understand how you can't see Steam as a massive monopoly.

Perhaps you don't because they have done almost all GOOD with their monopoly power. Offline mode, library sharing, massive sales, etc.. but they are quite a monopoly.

If 99% of my library is on Steam, why should I bother buying somewhere else? It's just an inconvenience to me. Ok I can buy off GOG and have no DRM.... how does that really help me? I can already play it on steam with no problems, my friends can play the shared game on steam, I don't have to worry about multiple platforms etc..

Anyway- steam is a massive monopoly and we are lucky they use their powers for good!

The statement is from the perspective of the studios, not customers (studios want to sell in every store they can, customers only buy the game once).

Network effects make Steam a practical monopoly. And it's probably no coincidence it has lower rates for AAA studios since Epic has gained a foothold in the market.

Yeah, but that is a monopoly for the publishers dealing with Steam, not for gamers which don't care as long as it is not broken.

Like Walmart or Amazon, the problem is for devs, not customers.

Epic does not want to be a major store. They want to be the only store.

That is why they have been forcing exclusivity. That is the point: they are anticompetitive.

Steam has plenty of money and users. It also had little serious competition before Epic. While I'm a fan of well regulated markets, I don't think punishing Epic would benefit anyone except Steam shareholders.

Except gamers do not care about Steam being a monopoly (they are just a distributor and does not set prices), but would really be hurt if Epic and exclusivity of titles starts to take hold.

> Markdown is not consistent across the platforms that support it.

That is not true anymore. CommonMark is the formal spec everyone follows now, including most major sites out there.

> If I wake you up at 3AM would you remember the format of links? is it parentheses first or brackets?

Well, yes. Markdown is super easy to remember.

> LaTeX support. I can write some complex math formulas.

On top of CommonMark you can add extensions to render LaTeX just fine (like MathExchange does, for instance).

> That is not true anymore.

GFM, ExtraMark, MultiMarkdown, MarkdownExtra, Gitlab, Taiga, Showdown, Markua, CommonMark, RMarkdown, etc., etc.

I can promise you, there will be more flavors and extensions in the next 20 years. And if I'm still alive then and we don't invent anything drastically different from keyboard input, I'd probably still be using Org-mode. Among thousands of others.

GFM, Gitlab and others you list are CommonMark plus extensions, which is what I said.

What is the problem? It is like saying JSON is useless because YAML exists, or that ISO C, C++, Fortran, IEEE 754, etc. are all useless because compilers and chip companies implement extensions.

You're still comparing just one aspect of Org-mode with Markdown. You're trying to convince me as if I was a pro-photographer and you'd tried to convince me that .jpeg is a fine format and everyone uses it and it's more popular, even though I'd still prefer RAW. Using .markdown is not appealing for me because .org allows me to do way more. If you're not convinced, then perhaps you don't need it. But don't expect me and thousands of other users of .org to switch, we'd be like: "Sorry, but you don't know what you're talking about". No offense.

Actually, YAML is probably worse than JSON, but JSON is really crappy compared to EDN. It's unfortunate that JSON has become the lingua franca for services, because it's really a stunted, primitive thing.

An engine like UE which has decades and decades of work does not care about what a small engine like Godot does.

The grant is more about avoiding monopoly claims, getting good PR and attacking Unity.

I didn't know about Xi, but JSON, RPC, multiprocess, microservices, Async... are all red flags.