mckravchyk

If you wanted to develop a cross-platform native desktop / mobile app in one framework without bundling / using a web browser, only QT comes to mind, which is C++. I think there are some bindings though.

C++ does not have a function keyword at all, I wonder why did they add it in the first place.

I'm using typed IDs in TypeScript with template literal types. I.e. `type UserId = `user_${string}` I've written a blog post about it a while ago [1] One can argue that this pollutes runtime, however, it is a feature to me. When the ID pops up in the logs, it is instantly obvious what the object is, error messages are more meaningful. You can notice that Stripe uses such approach in their API.

[1] https://www.velopen.com/blog/adding-type-safety-to-object-id...

I think the bigger problem would be license key sharing. If there's no server involved, there's no way (?) to prevent the same license key from being shared freely on the Internet and being used an unlimited amount of times, is it? This allows pirates to use a clean version with 0 risk of installing some malware.

The same Europe that introduces Cyber Resilience Act? Good luck. Imagine how many businesses will not be created because no one wants to risk burdening themselves with obligatory by law, 5 years of security maintenance of the product. It does not just suffice that you risk failing, you risk having to maintain it for years after the potential business failure.

I remember that another comical argument was performance. Supposedly, having extensions run in the background all the time is bad. So it's better to constantly, completely re-initialize them whenever an event wakes them up.

If I ever have time for it, I would love to program a rotating LED display [0] Looks like magic.

[0] https://www.youtube.com/watch?v=LIvihYPq_mQ

Is it possible for steam from boiling water to contain any impurities?

> No magic.

There's plenty of magic. I think that Electron Forge does too many things, like trying to be the bundler. Is it possible to set up a custom build system / bundling with it or are you forced to use Vite? I guess that even if you can, you pull all those dependencies when you install it and naturally you can't opt out from that. Those dev dependencies involved in the build process are higher impact than some production dependencies that run in a sandboxed tab process (because a tiny malicious dependency could insert any code into the app's fully privileged process). I have not shipped my app yet, but I am betting on ESBuild (because it's just one Go binary) and Electron Builder (electron.build)

This is a sabotage so the next major release doesn't get any attention ;)

> Additionally, it eliminates the need to parse HTML, as every node state is represented in a Go-based virtual DOM, with only updates being pushed directly to the actual HTML nodes.

That looks really interesting. I'm curious, are there any performance drawbacks to updating DOM via WebAssembly or is it negligible? I.e. let's say you are building an editor of some kind. If the entire app is in Go, that means sending the keydown event to the WASM module and having it update HTML back. Is it not better (from performance perspective) to just use JavaScript all the way?

> Just as I disagree about "full stack" developers. People that call themselves "full stack"are a backend developer that dabbles in frontend or a front end developer that can dabble on the backend. Almost never have a met a person who was equally good at both.

I would not be surprised if in 10 years from now, there will only be full stack web developers.

I am a desktop developer (yeah, Electron). There's really no front-end / back-end split in this domain. Electron is pretty much everything web front-end (in a "SPA, choose your own adventure" way rather than relying on a framework to do the heavy lifting) and all the business logic that is self-contained within the app and putting it all together with the APIs Electron exposes. I know that a local self-hosted back-end does not have the complexity of a distributed web-backend, but it's still much more than just front-end and there are areas of development that are probably more "wide" and definitely more complex than this anyway - like video game development or C++ / QT desktop development.

Now what happens to the front-end now? Full-stack frameworks like Next.js. They also simplify the front-end part to death, where you do not even get to think about state management anymore. Then you add generative AI...

Also consider this, is a front-end and back-end engineers with 10 years experience at a large co that much better at their respective domains than a full stack with 5 years of experience at a startup? I cannot say for the back-end, but I can say for the front-end - there's a ceiling and it does not take long to reach it (maybe 5 years). You stop getting much better once the ceiling is reached. So what makes someone good is both reaching the ceiling and continuing to do the work on a daily basis, rather than specialising in an area, in my option. A video game dev with 20 years of experience probably is much much better than one with 5y. But front-end? I don't think so.

I don't think it's that at all. The motive is quite clear. It's right there in the article:

> We’re excited to return to active contributions to WordPress core, Gutenberg, Playground, Openverse, and WordPress.org *when the legal attacks have stopped*.

This is a move to show how much the development of WordPress depends on Automattic (some 4k hours per week) and how WP Engine is using the product of that effort without giving much back (45 hours per week) - "A Level Playing Field". It all started from this and it sends a message "don't take it for granted".

https://web.archive.org/web/20240927025102/https://wordpress...

https://wordpress.org/five-for-the-future/pledges/?order=hou...

> But there's also a large discrepancy between Chromium's budget (Google) and The Qt Company. Also The Qt Company tend to prioritize advancement in the embedded world (where it probably gets most of its cash) rather than regular applications

Yep. That's precisely the point, you get all this stuff from a billion dollar project for free.

I really would not mind writing some C++ instead, even if it was more difficult. If anything, it would only be better because of higher moat of the project as well as my own skills. I agree 100% on the principles that native is better, faster and JS is an unnecessary layer of abstraction slowing things down.

However, if I can compare 2 timelines, one where I am using QML for a project, another one where I am using Electron and think about the time spent working around bugs, reporting bugs and the users of the app complain about crashes in the former, or not have any of that at the trade off of having something slightly slower, to me it's a no brainer.

In the context of what you wrote in the article:

> One of the most frustrating aspects of developing a Qt application is the slew of Qt bugs you encounter along the way. During ten months of development, I reported seven bugs, three of which were assigned 'critical' priority—two of which resulted in crashes. I also came across many bugs already reported by others that remain unfixed.

I would rather have an app that is slightly slower than one that can crash unexpectedly. Even if they are quick to fix bugs, new bugs may be introduced in new releases. Your intent was to promote QT in your blog post, but unfortunately it has only affirmed to me that it's not something production-ready (QML on desktop).

That's just the unfortunate state of industry where we are at. Hopefully it changes one day. Maybe Chromium could be forked into a C++ GUI toolkit where DOM could be manipulated directly by C++. Has anyone ever considered that?

I am not sure if it's worth it though.

As you have pointed out, QML is buggy. Chromium's rendering engine is probably the most stable and polished GUI toolkit there is, not to mention a cross-platform one too. Throughout the last 10 years I only had to deal with 2 Chromium bugs and they were very minor. Well-written JavaScript is fast and the machines are getting faster every year. It does not take much real time computation to provide a UI for a desktop app, it's not a video game. And many of the those things that are real time, like the caret in the text editor or hover states are implemented in native code by the web browser, with no JS interaction. I agree though that a block editor is a little more real time than the average UI.

The key word is well-written JavaScript. What is the most popular state management framework? Redux, possibly. What is the most inefficient state management framework? Also Redux. With Redux, if you have an app that displays a timer that updates every second, every subscription to any piece of the state throughout the entire app will trigger. I'm not sure if the app used Redux, but I used to use a time tracker app that would use 30% of my CPU when idle (I since moved to a CLI C++ solution and it is so much faster, but that does not mean a decent time tracker could not be built with web technologies). So if Redux is the most popular framework, you can see just how little the average web dev cares about writing apps that are not slow resource hogs.

> Also, all web apps couldn't handle loading a very large text file (they were all hanging).

Could it be that QT has some optimisation technique to not render all those lines out of view? I.e. if you have a huge file that can still be loaded to RAM, C++ won't sweat it, but is it actually getting all rendered at the same time in a savvy implementation, whether at the level of the app or the framework? Probably not. On the other hand, the textarea element or a contentEditable div just was not made for something like this. It could still be developed by implementing a custom element / component that loads the text dynamically while scrolling. If it's too much for JS to hold, it could use WASM or another process and pass it with IPC. It is definitely possible to write an Electron-based text editor that can open a 1 GB text file efficiently, it's just not out of the box experience and most people do not think there's a need for such a use case.

A country that was aligned ideologically with USSR is an understatement. They were under occupation as a satellite state. Those people did not sign up for communism in 1945 willingly.

> Look, Automattic can change their license away from the GPL any time they wish. The new license will only apply to new code, though, and WP Engine, or anyone else, are eligible to fork the project. That's what happened with Redis after Redis Labs dropped their BSD license and went with a commercial source-available alternative.

No, that would not be a possibility. Since Automattic is not the copyright holder and GPL prohibits redistribution under an incompatible license, unlike BSD.

It's a completely different thing. You are talking about civilisation constructs, parent is talking about things like mental fitness, abilities to perform tasks in real-time by yourself.

For example, card payments are a crutch. If you pay by card / phone everywhere and then out of the sudden you are to pay in cash, it becomes mildly challenging vs. if you are used to pay in cash you don't think about it. The brain is capable of a great deal of automation, performing learned actions is effortless. Unlike a calculator or a spreadsheet, the buyer is not doing anything, just buying. It's not a bicycle, it's a crutch. It simply atrophies the mental bandwidth. The mind becomes more lax, less sharp, when it does not engage.

Now imagine what it will do to people's brains when instead of thinking about solutions themselves, they will ask the AI for everything. Those neurons will atrophy and the person will be even less skilled to ask the AI the right questions than if they did not use the AI in the first place. I think the key will be a balance between doing the work yourself and delegating the stuff to AI, but it will be difficult to find that balance. Just like smartphones can be very useful but in the end are a net negative to society.

No, Rider is also a C++ IDE but it's focused on gamedev. Live++ is mostly meant for gamedev, it only works on Windows.

> The need for icebreaking vessels will remain even as climate change reduces the extent of sea ice: paradoxically, as new polar routes become accessible and sea ice becomes more mobile, the demand for icebreakers is likely to increase.

And it really does permeate it. I'm on Linux but I run it on an Intel Mac. It will be very hard to find a non-Mac replacement. I look at the laptops at the electronics store and simply nothing comes even close. Beautiful products, it's very unfortunate though that they become ever more closed.

I for one started working on a new project in C++ rather than Rust. I think it's unclear whether Rust is going to be the successor at this point. It's probably never going to pick up in the games industry, QT is C++ (and Rust bindings will always be second class or they could end up unmaintained), has better compile times and is said to be undisputed when it comes to high performance. Obviously the tool for the job factor is most critical.

Career wise, many people are picking up Rust and almost no one is picking up C++, while experienced C++ devs either retire or switch to a higher level language due to landscape change. I would trust supply and demand to be in favour of C++ 10 years from now.

There are also attempts to make C++ more memory safe like Carbon[1] or Circle compiler [2]. If they succeed, why would anyone want to switch to Rust? Also Rust is not ideal for security from a different perspective - I think the lack of a package manager is one C++ strongest points. After working for 9 years with npm, you really appreciate that the dependency you install is usually just a single dependency (even an option for a single header file is common), when there's a package manager, people will abuse it (like install a package with 3 dependencies of its own for something that could be 50 LOC copy-paste) and managing the security of the supply chain is nearly impossible (it will be a legal requirement soon in EU though).

Anyway, I wanted to ask. How is the contracting market looking in C++ world? I'm guessing it depends on the domain heavily? I'm mainly asking about QT and anything that would be desktop / mobile apps / systems programming except video games, but I'm curious in general.

[1] https://github.com/carbon-language/carbon-lang

[2] https://github.com/seanbaxter/circle

It's worth noting that they re-introduced their jobs platform https://stackoverflow.com/jobs/

From my experience it must be ChatGPT. I am getting much less upvotes for past answers since 2023. Even the reputation (t) curve visible on the profile reflects that, up to 2023 it was a straight line at around 30 degrees, start of 2023 and it's at about 15 degrees.

I guess it also does not default to cloud saving over local.

When you look at the image you can't help but think how it would look like if a giant ball of water was dropped like this on the surface. Apart from the flood / water destroying / reshaping the surface of the entire continent, anyone has an idea how it would the impact look like?

I am probably way off, but I imagine solid ice sinking deep into the ground with water starting to turn into vapor in the upper layers and the vapor generated inside exploding out from the ball as it gradually shrinks and deforms.

156 x Mt. Everest

Some people say that it has greatly enhanced their abilities, other people say that it's mostly useless. I am myself in the latter camp. I never build the habit of using it because it failed miserably on relatively simple things. However, even if it was smarter, I can hardly see how it could be faster to design the prompt, correct it multiple times vs. just typing code in flow state.

It's a wrong comparison. A high-level language is usually good enough for a desktop app because there's not much ongoing computation happening. It's only input processing and small, infrequent updates to the view in response to the input (not to mention rendering of the DOM and low level input processing is done by the browser's C++ compiled code). A video game on the other hand has to do computations all the time at a very high frequency.

> We now have the ability to have an Einstein-level of genius in our pockets

It's pretty cool but what you really mean is that it's a better UI to an encyclopedia and a story / art generator. It has no ability to reason at all and often struggles with simple things.