What is Rust and what are its top alternatives?
Top Alternatives to Rust
- Swift
Writing code is interactive and fun, the syntax is concise yet expressive, and apps run lightning-fast. Swift is ready for your next iOS and OS X project — or for addition into your current app — because Swift code works side-by-side with Objective-C. ...
- Python
Python is a general purpose programming language created by Guido Van Rossum. Python is most praised for its elegant syntax and readable code, if you are just beginning your programming career python suits you best. ...
- Golang
Go is expressive, concise, clean, and efficient. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel type system enables flexible and modular program construction. Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language. ...
- Haskell
It is a general purpose language that can be used in any domain and use case, it is ideally suited for proprietary business logic and data analysis, fast prototyping and enhancing existing software environments with correct code, performance and scalability. ...
- Java
Java is a programming language and computing platform first released by Sun Microsystems in 1995. There are lots of applications and websites that will not work unless you have Java installed, and more are created every day. Java is fast, secure, and reliable. From laptops to datacenters, game consoles to scientific supercomputers, cell phones to the Internet, Java is everywhere! ...
- JavaScript
JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...
- PHP
Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world. ...
Rust alternatives & related posts
- Performance67
- Low-level48
- Portability35
- Hardware level28
- Embedded apps19
- Pure13
- Performance of assembler9
- Ubiquity8
- Great for embedded5
- Old4
- Compiles quickly3
- No garbage collection to slow it down2
- OpenMP2
- Gnu/linux interoperable1
- Low-level5
- No built in support for concurrency3
- Lack of type safety2
- No built in support for parallelism (e.g. map-reduce)2
related C lang posts
Why Uber developed H3, our open source grid system to make geospatial data visualization and exploration easier and more efficient:
We decided to create H3 to combine the benefits of a hexagonal global grid system with a hierarchical indexing system. A global grid system usually requires at least two things: a map projection and a grid laid on top of the map. For map projection, we chose to use gnomonic projections centered on icosahedron faces. This projects from Earth as a sphere to an icosahedron, a twenty-sided platonic solid. The H3 grid is constructed by laying out 122 base cells over the Earth, with ten cells per face. H3 supports sixteen resolutions: https://eng.uber.com/h3/
(GitHub Pages : https://uber.github.io/h3/#/ Written in C w/ bindings in Java & JavaScript )
One important decision for delivering a platform independent solution with low memory footprint and minimal dependencies was the choice of the programming language. We considered a few from Python (there was already a reasonably large Python code base at Thumbtack), to Go (we were taking our first steps with it), and even Rust (too immature at the time).
We ended up writing it in C. It was easy to meet all requirements with only one external dependency for implementing the web server, clearly no challenges running it on any of the Linux distributions we were maintaining, and arguably the implementation with the smallest memory footprint given the choices above.
- Ios257
- Elegant179
- Not Objective-C125
- Backed by apple107
- Type inference92
- Generics60
- Playgrounds54
- Semicolon free49
- OSX38
- Tuples offer compound variables35
- Easy to learn24
- Clean Syntax23
- Open Source22
- Beautiful Code20
- Functional20
- Linux11
- Dynamic11
- Promotes safe, readable code10
- Protocol-oriented programming10
- No S-l-o-w JVM8
- Explicit optionals8
- Storyboard designer7
- Best UI concept5
- Super addicting language, great people, open, elegant5
- Type safety5
- Optionals5
- Feels like a better C++4
- Swift is faster than Objective-C4
- Its friendly4
- Faster and looks better4
- Powerful4
- Fail-safe4
- Highly Readable codes4
- Easy to Maintain3
- Easy to learn and work3
- Much more fun3
- Protocol extensions3
- Native3
- Its fun and damn fast3
- Strong Type safety3
- Protocol oriented programming2
- Esay2
- MacOS2
- Type Safe2
- All Cons C# and Java Swift Already has2
- Protocol as type2
- Objec1
- Can interface with C easily1
- Numbers with underbar1
- Optional chain1
- Runs Python 8 times faster1
- Actually don't have to own a mac1
- Free from Memory Leak1
- Swift is easier to understand for non-iOS developers.1
- Great for Multi-Threaded Programming1
- Must own a mac5
- Memory leaks are not uncommon2
- Very irritatingly picky about things that’s1
- Complicated process for exporting modules1
- Its classes compile to roughly 300 lines of assembly1
- Is a lot more effort than lua to make simple functions1
- Overly complex options makes it easy to create bad code0
related Swift posts
Hi Community! Trust everyone is keeping safe. I am exploring the idea of building a #Neobank (App) with end-to-end banking capabilities. In the process of exploring this space, I have come across multiple Apps (N26, Revolut, Monese, etc) and explored their stacks in detail. The confusion remains to be the Backend Tech to be used?
What would you go with considering all of the languages such as Node.js Java Rails Python are suggested by some person or the other. As a general trend, I have noticed the usage of Node with React on the front or Node with a combination of Kotlin and Swift. Please suggest what would be the right approach!
Excerpts from how we developed (and subsequently open sourced) Uber's cross-platform mobile architecture framework, RIBs , going from Objective-C to Swift in the process for iOS: https://github.com/uber/RIBs
Uber’s new application architecture (RIBs) extensively uses protocols to keep its various components decoupled and testable. We used this architecture for the first time in our new rider application and moved our primary language from Objective-C to Swift. Since Swift is a very static language, unit testing became problematic. Dynamic languages have good frameworks to build test mocks, stubs, or stand-ins by dynamically creating or modifying existing concrete classes.
Needless to say, we were not very excited about the additional complexity of manually writing and maintaining mock implementations for each of our thousands of protocols.
The information required to generate mock classes already exists in the Swift protocol. For Uber’s use case, we set out to create tooling that would let engineers automatically generate test mocks for any protocol they wanted by simply annotating them.
The iOS codebase for our rider application alone incorporates around 1,500 of these generated mocks. Without our code generation tool, all of these would have to be written and maintained by hand, which would have made testing much more time-intensive. Auto-generated mocks have contributed a lot to the unit test coverage that we have today.
We built these code generation tools ourselves for a number of reasons, including that there weren’t many open source tools available at the time we started our effort. Today, there are some great open source tools to generate resource accessors, like SwiftGen. And Sourcery can help you with generic code generation needs:
https://eng.uber.com/code-generation/ https://eng.uber.com/driver-app-ribs-architecture/
(GitHub : https://github.com/uber/RIBs )
Python
- Great libraries1.1K
- Readable code947
- Beautiful code835
- Rapid development780
- Large community682
- Open source426
- Elegant385
- Great community278
- Object oriented268
- Dynamic typing214
- Great standard library75
- Very fast56
- Functional programming51
- Scientific computing43
- Easy to learn43
- Great documentation33
- Matlab alternative26
- Productivity25
- Easy to read25
- Simple is better than complex21
- It's the way I think18
- Imperative17
- Very programmer and non-programmer friendly15
- Free15
- Machine learning support14
- Powerful14
- Powerfull language14
- Fast and simple13
- Scripting12
- Explicit is better than implicit9
- Unlimited power8
- Clear and easy and powerfull8
- Ease of development8
- Import antigravity7
- It's lean and fun to code6
- Print "life is short, use python"6
- I love snakes5
- Fast coding and good for competitions5
- There should be one-- and preferably only one --obvious5
- Python has great libraries for data processing5
- High Documented language5
- Although practicality beats purity5
- Flat is better than nested5
- Great for tooling5
- Readability counts4
- Rapid Prototyping4
- Lists, tuples, dictionaries3
- Socially engaged community3
- Now is better than never3
- Web scraping3
- Complex is better than complicated3
- Multiple Inheritence3
- Plotting3
- Beautiful is better than ugly3
- CG industry needs3
- Great for analytics3
- Easy to setup and run smooth2
- Generators2
- If the implementation is easy to explain, it may be a g2
- Special cases aren't special enough to break the rules2
- If the implementation is hard to explain, it's a bad id2
- Simple and easy to learn2
- Import this2
- Many types of collections2
- No cruft2
- Easy to learn and use2
- List comprehensions2
- Can understand easily who are new to programming1
- Because of Netflix1
- A-to-Z1
- Only one way to do it1
- It is Very easy , simple and will you be love programmi1
- Powerful language for AI1
- Flexible and easy1
- Better outcome1
- Batteries included1
- Pip install everything1
- Should START with this but not STICK with This1
- Good for hacking1
- Powerful0
- Still divided between python 2 and python 351
- Performance impact28
- Poor syntax for anonymous functions26
- GIL21
- Package management is a mess19
- Too imperative-oriented14
- Hard to understand12
- Dynamic typing12
- Very slow10
- Not everything is expression8
- Explicit self parameter in methods7
- Indentations matter a lot7
- Poor DSL capabilities6
- Incredibly slow6
- No anonymous functions6
- Requires C functions for dynamic modules6
- Hard to obfuscate5
- Threading5
- Fake object-oriented programming5
- The "lisp style" whitespaces5
- Official documentation is unclear.4
- Circular import4
- Lack of Syntax Sugar leads to "the pyramid of doom"4
- Not suitable for autocomplete4
- The benevolent-dictator-for-life quit4
- Meta classes2
- Training wheels (forced indentation)1
related Python posts











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:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.
We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)
We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.
Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.
#FrameworksFullStack #Languages
Golang
- High-performance534
- Simple, minimal syntax389
- Fun to write356
- Easy concurrency support via goroutines297
- Fast compilation times269
- Goroutines191
- Statically linked binaries that are simple to deploy178
- Simple compile build/run procedures149
- Backed by google135
- Great community132
- Garbage collection built-in51
- Built-in Testing43
- Excellent tools - gofmt, godoc etc42
- Elegant and concise like Python, fast like C38
- Awesome to Develop35
- Used for Docker25
- Flexible interface system24
- Deploy as executable22
- Great concurrency pattern22
- Open-source Integration19
- Go is God16
- Fun to write and so many feature out of the box16
- Easy to read15
- Its Simple and Heavy duty14
- Powerful and simple13
- Easy to deploy13
- Best language for concurrency12
- Concurrency11
- Safe GOTOs10
- Rich standard library10
- Clean code, high performance9
- Easy setup9
- High performance8
- Hassle free deployment8
- Simplicity, Concurrency, Performance8
- Used by Giants of the industry7
- Single binary avoids library dependency issues7
- Cross compiling6
- Simple, powerful, and great performance6
- Gofmt5
- Garbage Collection5
- Very sophisticated syntax5
- Excellent tooling5
- WYSIWYG5
- Keep it simple and stupid4
- Widely used4
- Kubernetes written on Go4
- No generics2
- Operator goto1
- You waste time in plumbing code catching errors41
- Verbose25
- Packages and their path dependencies are braindead23
- Dependency management when working on multiple projects15
- Google's documentations aren't beginer friendly15
- Automatic garbage collection overheads10
- Uncommon syntax8
- Type system is lacking (no generics, etc)6
- Collection framework is lacking (list, set, map)3
- Best programming language2
related Golang posts











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:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.
We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)
We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.
Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.
#FrameworksFullStack #Languages
- Purely-functional programming89
- Statically typed66
- Type-safe59
- Open source39
- Great community38
- Built-in concurrency30
- Composable29
- Built-in parallelism29
- Referentially transparent23
- Generics19
- Intellectual satisfaction14
- Type inference14
- If it compiles, it's correct11
- Flexible7
- Monads7
- Proposition testing with QuickCheck4
- Great type system4
- Purely-functional Programming3
- One of the most powerful languages *(see blub paradox)*3
- Highly expressive, type-safe, fast development time2
- Reliable2
- Kind system2
- Pattern matching and completeness checking2
- Better type-safe than sorry2
- Type classes2
- Great maintainability of the code2
- Fun2
- Best in class thinking tool2
- Orthogonality0
- Predictable0
- Error messages can be very confusing8
- Too much distraction in language extensions8
- Libraries have poor documentation4
- No best practices3
- No good ABI3
- Sometimes performance is unpredictable2
- Poor packaging for apps written in it for Linux distros2
- Slow compilation1
related Haskell posts
Why I am using Haskell in my free time?
I have 3 reasons for it. I am looking for:
Fun.
Improve functional programming skill.
Improve problem-solving skill.
Laziness and mathematical abstractions behind Haskell makes it a wonderful language.
It is Pure functional, it helps me to write better Scala code.
Highly expressive language gives elegant ways to solve coding puzzle.
Java
- Great libraries593
- Widely used444
- Excellent tooling400
- Huge amount of documentation available390
- Large pool of developers available333
- Open source205
- Excellent performance201
- Great development155
- Vast array of 3rd party libraries149
- Used for android148
- Compiled Language60
- Used for Web51
- Managed memory46
- High Performance45
- Native threads44
- Statically typed43
- Easy to read35
- Great Community33
- Reliable platform29
- Sturdy garbage collection24
- JVM compatibility24
- Cross Platform Enterprise Integration22
- Universal platform20
- Good amount of APIs20
- Great Support18
- Great ecosystem14
- Backward compatible11
- Lots of boilerplate11
- Everywhere10
- Excellent SDK - JDK9
- It's Java7
- Static typing7
- Mature language thus stable systems6
- Better than Ruby6
- Long term language6
- Cross-platform6
- Portability6
- Clojure5
- Vast Collections Library5
- Used for Android development5
- Most developers favorite4
- Old tech4
- Javadoc3
- Stable platform, which many new languages depend on3
- History3
- Testable3
- Best martial for design3
- Great Structure3
- Faster than python2
- Type Safe2
- Verbosity33
- NullpointerException27
- Nightmare to Write16
- Overcomplexity is praised in community culture16
- Boiler plate code12
- Classpath hell prior to Java 98
- No REPL6
- No property4
- Code are too long3
- Non-intuitive generic implementation2
- There is not optional parameter2
- Floating-point errors2
- Java's too statically, stronglly, and strictly typed1
- Returning Wildcard Types1
- Terrbible compared to Python/Batch Perormence1
related Java posts











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:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
When you think about test automation, it’s crucial to make it everyone’s responsibility (not just QA Engineers'). We started with Selenium and Java, but with our platform revolving around Ruby, Elixir and JavaScript, QA Engineers were left alone to automate tests. Cypress was the answer, as we could switch to JS and simply involve more people from day one. There's a downside too, as it meant testing on Chrome only, but that was "good enough" for us + if really needed we can always cover some specific cases in a different way.
JavaScript
- Can be used on frontend/backend1.6K
- It's everywhere1.5K
- Lots of great frameworks1.2K
- Fast894
- Light weight741
- Flexible424
- You can't get a device today that doesn't run js391
- Non-blocking i/o286
- Ubiquitousness235
- Expressive190
- Extended functionality to web pages54
- Relatively easy language48
- Executed on the client side45
- Relatively fast to the end user29
- Pure Javascript24
- Functional programming20
- Async14
- Setup is easy11
- Its everywhere11
- Full-stack11
- Because I love functions10
- JavaScript is the New PHP9
- Like it or not, JS is part of the web standard9
- Can be used in backend, frontend and DB8
- Expansive community8
- Easy8
- Can be used both as frontend and backend as well7
- Most Popular Language in the World7
- For the good parts7
- Everyone use it7
- Easy to hire developers7
- No need to use PHP7
- Future Language of The Web7
- Powerful6
- Photoshop has 3 JS runtimes built in6
- Love-hate relationship6
- Evolution of C6
- Supports lambdas and closures6
- Agile, packages simple to use6
- Popularized Class-Less Architecture & Lambdas6
- Client side JS uses the visitors CPU to save Server Res5
- 1.6K Can be used on frontend/backend5
- Versitile5
- Hard not to use5
- Its fun and fast5
- It's fun5
- Nice5
- Easy to make something5
- Can be used on frontend/backend/Mobile/create PRO Ui5
- It let's me use Babel & Typescript5
- Everywhere4
- Client processing4
- Function expressions are useful for callbacks4
- Stockholm Syndrome4
- What to add4
- Clojurescript4
- Promise relationship4
- Scope manipulation4
- Only Programming language on browser3
- Because it is so simple and lightweight3
- Easy to understand0
- A constant moving target, too much churn22
- Horribly inconsistent20
- Javascript is the New PHP15
- No ability to monitor memory utilitization8
- Shows Zero output in case of ANY error7
- Can be ugly6
- Thinks strange results are better than errors6
- No GitHub3
- Slow2
related JavaScript posts
Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.
But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.
But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.
Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.











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:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
PHP
- Large community948
- Open source814
- Easy deployment763
- Great frameworks484
- The best glue on the web384
- Continual improvements234
- Good old web183
- Web foundation145
- Community packages134
- Tool support124
- Used by wordpress35
- Excellent documentation33
- Used by Facebook28
- Because of Symfony23
- Dynamic Language21
- Cheap hosting16
- Easy to learn15
- Awesome Language and easy to implement14
- Fast development14
- Very powerful web language14
- Composer12
- Flexibility, syntax, extensibility11
- Because of Laravel10
- Easiest deployment8
- Worst popularity quality ratio7
- Fastestest Time to Version 1.0 Deployments7
- Fast7
- Readable Code7
- Short development lead times7
- Faster then ever6
- Most of the web uses it6
- Open source and large community5
- Simple, flexible yet Scalable5
- Easy to learn, a big community, lot of frameworks4
- Has the best ecommerce(Magento,Prestashop,Opencart,etc)4
- Is like one zip of air4
- Open source and great framework4
- Large community, easy setup, easy deployment, framework4
- Easy to use and learn4
- Cheap to own4
- I have no choice :(4
- Great developer experience3
- Great flexibility. From fast prototyping to large apps2
- Interpreted at the run time2
- FFI2
- Safe the planet2
- Hard not to use2
- Used by STOMT2
- Fault tolerance2
- Walk away2
- Simplesaml1
- Secure1
- Secure0
- So easy to learn, good practices are hard to find20
- Inconsistent API16
- Fragmented community8
- Not secure5
- No routing system2
- Hard to debug1
- Old1
related PHP posts
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
















Our whole Node.js backend stack consists of the following tools:
- Lerna as a tool for multi package and multi repository management
- npm as package manager
- NestJS as Node.js framework
- TypeScript as programming language
- ExpressJS as web server
- Swagger UI for visualizing and interacting with the API’s resources
- Postman as a tool for API development
- TypeORM as object relational mapping layer
- JSON Web Token for access token management
The main reason we have chosen Node.js over PHP is related to the following artifacts:
- Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
- Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
- A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
- Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.