4D1

As someone who works for the company mentioned, we already have offers for emerging markets such as this in an innovations team. The unfortunate reality is that manufacturers don't want to go through the time and cost of regulatory certification unless demanded by some agency in power. The innovations team consistently underperforms compared to our EMC and Wireless/RF teams, which performs certification required by government agencies such as the FCC.

How do you think these luxuries you were provided were given to you?

If you are operating within a managed usermode level of an operating system then what you say is perfectly valid, especially for programs that do not require high availability such as web servers. You can program in a managed environment and trust in your languages JIT/GC to handle low level optimization.

On embedded systems, software that requires high availability (video games for example), or kernel mode drivers and firmware, you are not always allowed that luxury. Understanding of and strong micromanagement of how memory is allocated and moved around the system becomes more and more crucial. It could be hardware limitations of the device that cause this, or in the case of firmware or drivers, any overhead that would be acceptable in a usermode application will be felt throughout the environment when you work on low-level.

TLDR you and the parent post are talking about apples and oranges.

Its a tin foil hat thing. The mmWave frequencies are only going to be used in high population dense areas and will run at a lower power. Other than this, 5G will operate much like LTE with a few additions like beamforming antenna arrays. Frequency has very little to do with health risk until you get into MUCH higher frequencies than what we operate in. Its about output power, and this is federally regulated by most countries.

This conversation is no longer of any benefit, but for the sake of you and your co-workers... Saying that C is predictably inferior, more expensive, and less maintainable shows a blatant amount of incompetence on how either languages operate. C++ only offers abstractions to (debatably) more easily allow for an object oriented design for codebases. Semantically everything that you can do in C++, you can do in C.

There are plenty of features in C++ that are beneficial, particularly the handful of mechanisms that allow you to move away from #defines, but to compare performance between C and C++ simply shows ignorance.

> Your solution to memory leaks is using a lower-level language? I should probably stop reading there..

Lower level than sandboxing into a js VM? yes. Writing everything in assembly, or in an unmanaged language? no. Adding unnecessary complexity to a program increases possibilities of bugs, which in this case, will be outside of your control. And this is a perfect example of unnecessary complexity.

> How do you make SSL connections? How do you parse JSON api's? How do you play audio, integrate with platform features (menu bars, dock dropping etc)? How do you create P2P WebRTC connections that capture camera and mic inputs? Let me guess, you have libraries for that.

Simple libraries that intend on doing the job and getting out of your way, yes. I wasn't aware you needed to embed a web browser to parse a json string, or to establish an SSL connection? There is a large difference between what a library is, and what electron aims to be... There will always be system apis that you will have to interface with, these are apples and oranges.

> People keep bringing this up because they're insecure about their role as programmers in a world where creating useful functionality is becoming easier and more accessable. People keep bringing this up because they don't comprehend what business requirements actually are and the cost of rolling your own technology and battle testing it.

Thank you for reminding me what the phrase "argumentum ad-hominem" means.

> I promise you. We're not all stupid. That's all I'm asking of people to consider before they start solving all the world's problems.

I can't speak for anyone else but I don't believe anyone who finds electron appealing is stupid. I am sure these people are more than capable programmers, and electron is a very appealing way for a web-based product to be able to quickly produce and distribute a desktop client. Most just desire for people to understand that most large-scale projects will dig their own graves in the promises of cross platform support and a fast production cycle, which has been a growing trend in software development for quite a few years now.

One problem, you cant optimize at all with electron, you are stuck with shoving a complete web browser solution into your program to make a GUI.

You are stuck with a massive amount of dependencies (html/css parser, javascript VM...) to various massive projects for what, easy cross platform support? Sure cross platform GUI's have been a problem, but any developer can agree that dependency to this level within professional code is a great way to cause a massive amount of headache from required library changes, bugs and memory leaks that you have NO control over due to it not being your code, required security updates that require code refactoring for no fault of your own, etc.

People keep bringing this up because it is a bad solution to a large problem. Maybe the reason its being rehashed so much is because there is truth to what is being said.

I would try finding a graphics library such as opengl, and build a UI in the spirit of something like:

https://github.com/ocornut/imgui https://github.com/vurtun/nuklear