My experience is that it is much more a matter of architecture.
This is a lock free key value store in a single file - it doesn't have the network protocol, but any threads dealing with the network IO could use it without doing anything differently.
Those were influential and have a had a very positive effect on modern C++ without a doubt. Now that they are part of the standard though there are fewer reasons to use anything from boost, largely because it is a double edged sword of compile times and dependencies.
Prefetching is another technique. If memory is accessed linearly, the CPU can prefetch ahead of what is currently being accessed, and that will include the TLB lookups.
It depends on exactly what you mean. In some sense, yes. It's still all assembly at the end. But, there's some claims about what's realistically possible, rather than theoretically possible. For example, Stylo was attempted in C++ twice, and both times, it failed. The complexity was too much, and there were too many bugs. The Rust attempt succeeded on the first try. shared_ptr's implementation in gcc's libstdc++ uses a heuristic to try and determine if it should use atomics or not. In my understanding, this was done because they were really worried about bugs when people chose the wrong one. Rust has a clean, compile-time checked separation between Arc<T> and Rc<T>.
These kinds of claims are much more interesting to me personally.
I'm not sure an anecdote about about a software project failing twice and succeeding on a third try can be used as evidence the the language of the third try enabled something to be pragmatically possible. I'm sure rust helped, but I'm also very confident that I could architect even a large scale project in C++ well enough that it would remain modular and progress could remain steady.
The team said it, not me. (I realize I didn’t make that clear before) There was a talk at a Rust conference about it in detail.
Modularity was not the issue. Complexity combined with concurrency was. Rust’s compile time checks was what made it feasible to be so aggressive without the bugs.
I was already assuming that concurrency was a big part of that statement. I respect Rust's attempt to solve these issues at the language level, but my experience has led me to think that they need to be solved at the architectural level of a program.
As far as I can tell, concurrency is fundamentally about grouping data by dependencies to find chunks that can be isolated. I think that resources are more about lifetimes and ownership and that resources and data aren't the same thing. This doesn't contradict what Rust is doing, it is more about relying on the language less.
You can see what I'm talking about in this link, though I don't think it has been digestible enough yet without video or examples.
The same extrapolations happen with population density. People in LA and New York think the world is overpopulated and everyone is on top of each other. They don't realize that 45 minutes north east of San Francisco there are no houses, no street lights and no cell phone reception.
No it isn't, flash was the best way to do many things for the years it was popular. Video, vector animation, simple interactivity.
Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language. Maybe a case could be made for severe misconceptions also helping electron like 'a custom native app has to be made for each platform', even though C++ and Qt and many other combinations can be written once with 99% of the source being the same for every platform.
>Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language.
Why is there always someone ready to jump in with this elitist nonsense? There's plenty of reasons to use a web stack even if you know other languages. It's inherently crossplatform, has an extensive library, and is extremely quick to iterate on.
Slack and Discord building in Electron means they only need to maintain one codebase across web, desktop, and mobile. They don't need separate teams for building in Java, Swift, and C#. They only need to write a new feature once.
Crazy, right?
This "web programmers are dumb" attitude is nothing but elitist rhetoric. Cut it out.
I keep seeing this "extremely quick to iterate on" point being brought up in defense of Electron. Slack released threads 2 years ago and we still can't post snippets, images, or use many slash commands inside them. Their last genuinely new features in the last year were synced DM drafts and the little lock badge on workspaces you're signed out of. Where's the iteration?
Meanwhile, almost daily I hit so many issues with the macOS application that I have to walk away from my computer in frustration. It makes my working life miserable due to its poor performance and bugs, and it encourages awful organizational and communication habits.
It's a bit anecdotal, but I imagine Slack is being careful because they are targeting businesses. Discord is a similar platform which iterates new features extremely quickly.
If that is the case, Slack should want to maximize features, even to the point of excess redundancy, so users can tailor their business product to the specific needs of their business. People don't work productively being boxed into one way of doing something, people work best if they are free to find their own ideal way of doing that thing or are able to tailor the product to the unique tasks they work on.
Think of all the different code editors developers use. Some are straightforward, some have a steep learning curve, yet the good ones are good because users can customize them toward their own personal preferences.
> There's plenty of reasons to use a web stack even if you know other languages. It's inherently crossplatform, has an extensive library, and is extremely quick to iterate on.
The GP's point was that, in the year 2019, none of these features are unique to the web.
• For "frameworks", there's Silverlight, Adobe Air, Haxe, and—strangely enough—Flash itself, which still works just fine if your goal is to ship a standalone "projector" app rather than something that runs in a browser.
• Or you can use a cross-platform scripting language (e.g. Python) with a cross-platform GUI toolkit (e.g. QT, WxWidgets.)
• Or you can use a not-cross-platform language (e.g. C#) but just use the (pretty large) subset of that language that is compatible with a third-party cross-platform runtime (e.g. Mono). Before you laugh, this is exactly how many companies code games to be cross-platform: they just write them for Win32 but constantly test them under Wine to ensure they aren't breaking Wine compatibility. Then they ship one native version and two virtualization-layer-wrapped versions.
• Or—horror of horrors—you can just use Java, and use the various Java-to-native-X compilers to target mobile platforms like iOS. (It worked well enough for Minecraft!)
The web has all of them, I have yet to find another platform/language that meets all the same criteria.
Combine all of the above with a rich toolchain and extreme dev tools portability -- I can be up and running on basically any machine in minutes. As well as ease of deployment (at least for hobby projects).
All of those other platforms are, for me, less in one of the axes I care about. I've developed extensively in Python, C#, and Java for both personal and professional projects and while I like developing in them for many, many reasons, when I need to start a new project I nearly always find myself reaching for Javascript as the starting point.
Minecraft (Bedrock, the engine used by Android, iOS and modern console versions) is written in C++ with custom renderers for different platforms it target. They don't compile their Java code to native code.
> Slack and Discord building in Electron means they only need to maintain one codebase across web, desktop, and mobile. They don't need separate teams for building in Java, Swift, and C#.
Did you know that Slack has native iOS and Android apps, as well as a cross-platform C++ "LibSlack" run by another separate team?
Qt is also cross-platform, easy to use, and has a giant library to work with. You can use it with virtually any language you want. Plus it runs on mobile.
You didn´t really counter the parent´s post with an argument. You just pretended to do so by suggesting an alternative that is incompatible with the requirements he had in mind because you think you know better...
> This "web programmers are dumb" attitude is nothing but elitist rhetoric.
I don't think that's the attitude. The attitude is that they are lazy/stubborn, not dumb. I personally believe most developers are smart enough to keep learning. Whether or not they are willing to put in the work is the question.
People working outside of their comfort zones generally don't know all the answers. That goes both ways. I recently watched a desktop developer reach for a Java servlet because they didn't know Javascript.
I think thee is also definitely a problem where if you don't use the right/current fad/popular stack you'll have a lot of trouble hiring people to work on your stuff.
Especially true since front and back end web stuff is so huge and high paying. problem comes when those stacks are a very poor fit for the problem at hand. But sure you could get an old neck beard to write that in C++ instead of java/Ruby or Node.js. Great you only need a single core embedded processor and it doen't even get hot! And yeah then who's going to maintain it?
"They only need to write a new feature once. Crazy, right?"
Yeah!, why you old farts want me to learn about the stack, the heap and all of that OS architecture crap?, I don't need or want that #$@&*, I barely can keep up with all the JavaScript frameworks/libraries/toolkits that came out last week!
Wait a minute. I have seen the argument for Electron because devs "get" to use one language they already know. So, let's just take a step back and reset...
GTK hasn't been well maintained or developed for ages and has always had poor docs. I wouldn't feel confident trying it on any platform which isn't its home (i.e. Linux).
> Qt
Qt is probably the best option in the list but it's language support is poor, only C++ and Python are practical. It is a big fully featured and mature library, but developing with QML is a poor experience compared to the tooling available on Chrome/Electron. Packaging and distributing Python and/or C++ Qt apps is a huge PITA too.
> WPF for Windows
not cross platform
> JavaFX
JavaFX looked interesting but just didn't seem to take off and develop a reasonable ecosystem around it. Certainly nothing that could rival the web ecosystem. I do love the language support that the JVM delivers. Regarding deployment size it isn't likely to be much better than Electron as most apps have to ship the whole JVM anyway. The stench of Oracle does taint it these days too.
> Tk
be serious
> LibUI
This isn't mature yet and it looks like another optimistic adventure in "write once, debug everywhere" like WxWidgets.
None of the options here can compete with Electron in terms of ecosystem or developer experience (often Chrome's dev tools). Nor are they built on open standards. Also JS is up there with the JVM and .Net platform in terms of languages which target and can run on it.
As someone who used to develop with some of those options, I'm frankly glad that I can use HTML/CSS and Electron + React. It's much easier on the developer, even if it's less performant for the end user.
It's not like I don't get the pain of slow tooling. I cut my teeth on C++. However, it's not a laziness issue, it's trading performance in one place for functionality in another. Case in point, at the time I chose C++ because I was trying to do game development in the pre-unity days. These days I'd choose Unity in a heartbeat because it's fast enough and saves me a lot of busywork. I could write more performant code from scratch, but it's really not worth the extra months spent wrangling polygons because the game never gets made.
How many of those run on the web as a platform? (A cursory search suggests 'not many' or 'not without some effort'?)
There are some components I'd ideally like to avoid rewriting for my web and desktop applications. (E.g. why should I have to write render code for my friends list component more than once?)
1% difference is a lot in software development. Electron is like Flash, it allows cross platform apps with one codebase. By the way Flash used ActionScript which have a lot in common with JS so that’s another similarity.
Electron is the best way for a third-party to wrap someone else's web-app into a more-fully-featured desktop app when that someone else doesn't want to ship a native app.
For example, there are a number of desktop Facebook Messenger "clients", that can pop OS notifications and so forth. They're all based on Electron. None of them are built by Facebook.
Similarly, there are a number of desktop Gmail "clients", not built by Google. They're all Electron, too.
The only alternative to this approach, would involve reverse-engineering the company's web-app's (proprietary, undocumented) API to write a native client library for it, and then constantly fighting the company as they try to block your native client library from being able to access their backend service. Some projects do that (there are at least two "native Gmail clients" that are actually native and are built on a reverse-engineering of the Gmail web-app backend API) but it's really not worth it if you're just a dev trying to scratch your own itch of wanting better desktop integration from these web-apps.
I was under the impression that it was available under the lgpl and only had to open source changes to the actual library that you aren't likely to need to make not your application.
You have to ensure you keep your business code separate from the Qt code. It's extra work that people might not want to deal with when they are more comfortable with other options that don't require special care.
You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
There's certainly a reason people worry about Qt licensing.
I don't mean to be harsh, but everything you wrote here is either wrong or misleading.
> You also must provide the Qt source code yourself, giving instructions on how to get Qt from the official website is not sufficient.
This isn't true [1].
> You also must allow relinking of your proprietary binary with different versions of Qt. This is easy on desktops but not on embedded or mobile devices.
If I'm distributing a game written with SDLv1 on mobile, I don't have to do anything at all differently than if I distribute the exact same game on desktop. Many, many games did this.
> You also may not begin using a commercial license for your proprietary code which you developed using the LGPL licensed Qt, unless you have written permission. Part of this also means you cannot use, let's say, a MIT licensed wrapper or utility for Qt, because that was probably developed against the LGPL licensed Qt, and thus cannot be used with a commercially licensed Qt.
This is also not at all true [2], in fact they couldn't release Qt under the LGPL if it were. That would be LGPL with a non-commercial-use clause, which would be incompatible.
> There's certainly a reason people worry about Qt licensing.
Yeah and honestly, it's because there's a lot of bad information out there. GPL and LGPL are subject to so much FUD. We as developers have a responsibility to know the facts.
No, you don't. You just need to provide a way to replace or relink Qt libraries. Unless of course you modify Qt itself, but then you only have to publish those modifications. Absolutely nothing requires you to "keep you business code separate from the Qt code".
I am wondering what is the issue with dynamically linking Qt, are developers statically linking with MS c/c++ runtime or GUI libs ? From my experience you must install c++ runtimes on windows or if you use C# you need to ask your user to make sure to have it installed, where with Qt you ship the dlls.
My understanding is that Windows has an odd memory allocation system where each DLL has its own allocator. Qt historically wasn't designed for that; it will allocate and return objects on the heap with the understanding that user code will free them.
They may have solved this since by using a custom allocator on windows for Qt types.
Is this related to statically linking? HOW are alternatives like Electron? can you bundle your Electron app into a big binary file ? From my experience in year back when doing desktop apps there was never a pressure to combine your dependencies into 1 big binary
>Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language.
More like Electron is only the best way to do something when you're a business that's in dire need of developers and needs a cross-platform solution.
It really isn't. Even the multiplatform aspect of Electron is PITA - abstraction layers are so poor you usually have to support every platform separately by yourself if you want to reliably use stuff like systray icons or notifications.
Well, there's one exception - it sure is more productive if you already have a webapp to reuse.
Add up all the time and resources wasted by an Electron application for all users over the lifetime of the application, then compare that to the amount of developer time supposedly saved.
So it is ok because money? I don't accept that reasoning. Computers today are orders of magnitude faster than they were in the past yet this concept of developer time being so much more important than everyone else's has them still feeling slow and unresponsive on essentially the same tasks we were performing 30 years ago.
It might feel like this, but if you boot up an old Windows XP machine and edit some text, it's still going to feel slow as hell in comparison to Atom on a modern machine. We get used to what's "fast" to do on our computers, and anything significantly slower than that feels "slow". And sure, the software is much less efficient. But compare it on hardware from the time it was developed, and it's not as bad as it seems.
And it's not just about money. With Discord as an example, they are able to quickly develop and deliver a great product, iterate on new features and integrations, and support all major platforms including web browsers. Their choice to use a web based stack helps A LOT with this.
I think it’s an economic reality for for-profit companies that make apps. If company A doesn’t go the html app route, and company B does for the same effective product, company B will have an advantage. It’s almost to the point where if your company app can be developed this way, you must do it this way to stay competitive.
> Electron is only the best way to do something when someone knows only javascript and web dev but doesn't want to learn a new language
and when you want to fire all the obsolete specialists while making a product with one person that works for everyone. I mean, you can keep one specialist, since they know javascript too
> No. In this case it allows cheap, (mostly) unsynchronized deallocation.
There isn't anything about garbage collection that enables something that couldn't be done before. If a lock free data structure is holding other non-trivial data structures that have no notion of concurrency, you are already in a position where you have to take what you can get.
> synchronization consumes a lot of CPU cycles. Ask any C++ programmer.
I've done a large amount of lock free programming in C++ and the best scenario is lock free data structure that takes responsibility for all the data stored in it and isn't just a container of pointers is the best approach to control the amount and types of synchronization. Atomic reference counting with the last reading thread responsible for deletion is just fine as an approach.
Ultimately, having granular but heap allocated data structures in a 'lock free' container needs to come with proper expectations, since it is a poor way to scale concurrency. Granular synchronization can be fine if typical usage isn't going to see much overlap or if the whole thing won't see much use in the first place, but for concurrency to scale, larger chunks of data separated out by their dependencies needs to be used.
> There isn't anything about garbage collection that enables something that couldn't be done before. ...
True, there's always another way. But you can say same about almost any subject. In my experience about lock-free (and wait-free) programming, safe and high performance deallocation of the objects is often a problem. (Especially in kernel mode when context switching is not an option.)
Whenever high performance is required and it's possible to avoid atomics (CAS, FAA, LL/SC, etc.), (false) cache line sharing or even memory operations altogether, I'll take it. Not to mention CAS (or equivalent) loops and mutexes...
> True, there's always another way. But you can say same about almost any subject.
This thread was started because the article focuses on lock free programming with garbage collection when garbage collection is not any sort of fundamental factor in lock free programming.
> In my experience about lock-free (and wait-free) programming, safe and high performance deallocation of the objects is often a problem.
Concurrency bottlenecks are fundamentally about synchronization. The solution is frequently to synchronize less and that means doing more in between synchronizing. This implies allocating and deallocating more at one time.
This is a lock free key value store in a single file - it doesn't have the network protocol, but any threads dealing with the network IO could use it without doing anything differently.
https://github.com/LiveAsynchronousVisualizedArchitecture/si...