C++ vs React Native: What are the differences?
C++ can be classified as a tool in the "Languages" category, while React Native is grouped under "Cross-Platform Mobile Development".
React Native is an open source tool with 78.8K GitHub stars and 17.6K GitHub forks. Here's a link to React Native's open source repository on GitHub.
According to the StackShare community, React Native has a broader approval, being mentioned in 719 company stacks & 809 developers stacks; compared to C++, which is listed in 199 company stacks and 371 developer stacks.
What is C++?
What is React Native?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
Sign up to add, upvote and see more consMake informed product decisions
Sign up to get full access to all the companiesMake informed product decisions
Sign up to get full access to all the tool integrationsMake informed product decisions
For a front end dev like me, using a mobile framework for side projects makes more sense than writing a native app. I had used Apache Cordova (formerly PhoneGap) before (because React Native didn't exist yet), and was happy with it. But once React Native came out, it made more sense to go that way instead. It's more efficient and smooth, since it doesn't have the simulation overhead, and has more access to hardware features. It feels cleaner since you don't need to deal with #WebView, using native UI widgets directly. I also considered Flutter . It looks promising, but is relatively new to the game, and React Native seems more stable for now.
Ruby NLP C++ Grammar #BNF
At FriendlyData we had a Ruby-based pipeline for natural language processing. Our technology is centered around grammar-based natural language parsing, as well as various product features, and, as the core stack of the company historically is Ruby, the initial version of the pipeline was implemented in Ruby as well.
As we were entering the exponential growth phase, both technology- and product-wise, we looked into how could we speed up and extend the performance and flexibility of our [meta-]BNF-based parsing engine. Gradually, we built the pieces of the engine in C++.
Ultimately, the natural language parsing stack spans three universes and three software engineering paradigms: the declarative one, the functional one, and the imperative one. The imperative one was and remains implemented in Ruby, the functional one is implemented in a functional language (this part is under the NDA, while everything I am talking about here is part of the public talks we gave throughout 2017 and 2018), and the declarative part, which can loosely be thought of as being BNF-based, is now served by the C++ engine.
The C++ engine for the BNF part removed the immediate blockers, gave us 500x+ performance speedup, and enabled us to launch new product features, most notably query completions, suggestions, and spelling corrections.
I've recently switched to using Expo for initializing and developing my React Native apps. Compared to React Native CLI, it's so much easier to get set up and going. Setting up and maintaining Android Studio, Android SDK, and virtual devices used to be such a headache. Thanks to Expo, I can now test my apps directly on my Android phone, just by installing the Expo app. I still use Xcode Simulator for iOS testing, since I don't have an iPhone, but that's easy anyway. The big win for me with Expo is ease of Android testing.
The Expo SDK also provides convenient features like Facebook login,
MapView, push notifications, and many others. https://docs.expo.io/versions/v31.0.0/sdk/
How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
Maybe not in everybody focus but I do like programming for @z/OS, @z/Linux and @z/VM with C++ , Java and Assembler . Who else love to dig into control blocks and get a deep dive into system resources to run things in a high valuable way ? And also go all the way up to the application to enlight all the infrastructure features to it ?
Initially, I wrote my text adventure game in C++, but I later rewrote my project in Rust. It was an incredibly easier process to use Rust to create a faster, more robust, and bug-free project.
One difficulty with the C++ language is the lack of safety, helpful error messages, and useful abstractions when compared to languages like Rust. Rust would display a helpful error message at compile time, while C++ would often display "Segmentation fault (core dumped)" or wall of STL errors in the middle. While I would frequently push buggy code to my C++ repository, Rust enabled me to only even submit fully functional code.
Along with the actual language, Rust also included useful tools such as rustup and cargo to aid in building projects, IDE tooling, managing dependencies, and cross-compiling. This was a refreshing alternative to the difficult CMake and tools of the same nature.
The capability of style customization is one a large deal breaker for frontend SDKs. To solve this, we decided to use styled-components in our SDK, which makes it easy to add support for themes on top of our existing components. This practice reduces the maintenance effort for stylings of custom components and keeps the overall codebase clean.
At FlowStack we write most of our backend in Go. Go is a well thought out language, with all the right compromises for speedy development of speedy and robust software. It's tooling is part of what makes Go such a great language. Testing and benchmarking is built into the language, in a way that makes it easy to ensure correctness and high performance. In most cases you can get more performance out of Rust and C or C++, but getting everything right is more cumbersome.
I am starting to become a full-stack developer, by choosing and learning .NET Core for API Development, Angular CLI / React for UI Development, MongoDB for database, as it a NoSQL DB and Flutter / React Native for Mobile App Development. Using Postman, Markdown and Visual Studio Code for development.
React Native is great in that it reduces the overhead of writing native code based on a web app. If written in a good style, Redux part of the app can often just be copied or shared in the Native app - and it just works! What a timesaver.
C++ is used in Shiro (https://github.com/Marc3842h/shiro).
C++ is a high performance, low level programming language. Game servers need to run with fast performance to be able to reliably serve players across the globe.
The most latency sensitive parts are written in C++. Due to our interconnected services architecture, we use either Python or C++ for each service, with the performance critical parts being C++14.
The framework used to write the mobile apps in this project. I've chosen this because of the "write once run all" (ios and android) mentality.
Used to write PHP extensions - AZTEC Decoder - License Driver scan - Axis2/C to PHP wrapper and Job-scheduler - Barbershop
Performance, zero-overhead abstractions and memory safety of the modern C++ language make this the perfect language for the project.
The main programming language of ApertusVR. C++11 & CMake provides multi-platform targeting. The architecture is modular.
We are not currently using this product but we have very high interest in learning and using this for mobile apps.
New features of our app are developed on React Native, so we could maintain a small dev team.