What is Kotlin and what are its top alternatives?
Top Alternatives to Kotlin
- Scala
Scala is an acronym for “Scalable Language”. This means that Scala grows with you. You can play with it by typing one-line expressions and observing the results. But you can also rely on it for large mission critical systems, as many companies, including Twitter, LinkedIn, or Intel do. To some, Scala feels like a scripting language. Its syntax is concise and low ceremony; its types get out of the way because the compiler can infer them. ...
- 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. ...
- 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! ...
- Groovy
It is a powerful multi-faceted programming language for the JVM platform. It supports a spectrum of programming styles incorporating features from dynamic languages such as optional and duck typing, but also static compilation and static type checking at levels similar to or greater than Java through its extensible static type checker. It aims to greatly increase developer productivity with many powerful features but also a concise, familiar and easy to learn syntax. ...
- 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. ...
- React Native
React Native enables you to build world-class application experiences on native platforms using a consistent developer experience based on JavaScript and React. The focus of React Native is on developer efficiency across all the platforms you care about - learn once, write anywhere. Facebook uses React Native in multiple production apps and will continue investing in React Native. ...
- Flutter
Flutter is a mobile app SDK to help developers and designers build modern mobile apps for iOS and Android. ...
Kotlin alternatives & related posts
- Static typing188
- Pattern-matching179
- Jvm177
- Scala is fun172
- Types138
- Concurrency95
- Actor library88
- Solve functional problems86
- Open source83
- Solve concurrency in a safer way80
- Functional44
- Generics23
- Fast23
- It makes me a better engineer18
- Syntactic sugar17
- Scalable13
- First-class functions10
- Type safety10
- Interactive REPL9
- Expressive8
- SBT7
- Implicit parameters6
- Case classes6
- Used by Twitter4
- JVM, OOP and Functional programming, and static typing4
- Rapid and Safe Development using Functional Programming4
- Object-oriented4
- Functional Proframming3
- Spark2
- Beautiful Code2
- Safety2
- Growing Community2
- DSL1
- Rich Static Types System and great Concurrency support1
- Naturally enforce high code quality1
- Akka Streams1
- Akka1
- Reactive Streams1
- Easy embedded DSLs1
- Mill build tool1
- Freedom to choose the right tools for a job0
- Slow compilation time11
- Multiple ropes and styles to hang your self7
- Too few developers available6
- Complicated subtyping4
- My coworkers using scala are racist against other stuff2
related Scala posts
I am new to Apache Spark and Scala both. I am basically a Java developer and have around 10 years of experience in Java.
I wish to work on some Machine learning or AI tech stacks. Please assist me in the tech stack and help make a clear Road Map. Any feedback is welcome.
Technologies apart from Scala and Spark are also welcome. Please note that the tools should be relevant to Machine Learning or Artificial Intelligence.
Lumosity is home to the world's largest cognitive training database, a responsibility we take seriously. For most of the company's history, our analysis of user behavior and training data has been powered by an event stream--first a simple Node.js pub/sub app, then a heavyweight Ruby app with stronger durability. Both supported decent throughput and latency, but they lacked some major features supported by existing open-source alternatives: replaying existing messages (also lacking in most message queue-based solutions), scaling out many different readers for the same stream, the ability to leverage existing solutions for reading and writing, and possibly most importantly: the ability to hire someone externally who already had expertise.
We ultimately migrated to Kafka in early- to mid-2016, citing both industry trends in companies we'd talked to with similar durability and throughput needs, the extremely strong documentation and community. We pored over Kyle Kingsbury's Jepsen post (https://aphyr.com/posts/293-jepsen-Kafka), as well as Jay Kreps' follow-up (http://blog.empathybox.com/post/62279088548/a-few-notes-on-kafka-and-jepsen), talked at length with Confluent folks and community members, and still wound up running parallel systems for quite a long time, but ultimately, we've been very, very happy. Understanding the internals and proper levers takes some commitment, but it's taken very little maintenance once configured. Since then, the Confluent Platform community has grown and grown; we've gone from doing most development using custom Scala consumers and producers to being 60/40 Kafka Streams/Connects.
We originally looked into Storm / Heron , and we'd moved on from Redis pub/sub. Heron looks great, but we already had a programming model across services that was more akin to consuming a message consumers than required a topology of bolts, etc. Heron also had just come out while we were starting to migrate things, and the community momentum and direction of Kafka felt more substantial than the older Storm. If we were to start the process over again today, we might check out Pulsar , although the ecosystem is much younger.
To find out more, read our 2017 engineering blog post about the migration!
Swift
- Ios254
- Elegant178
- Not Objective-C125
- Backed by apple106
- Type inference92
- Generics60
- Playgrounds54
- Semicolon free49
- OSX39
- Tuples offer compound variables35
- Easy to learn24
- Clean Syntax23
- Open Source21
- Functional20
- Beautiful Code19
- Dynamic11
- Linux11
- Protocol-oriented programming10
- Promotes safe, readable code10
- No S-l-o-w JVM8
- Explicit optionals8
- Storyboard designer7
- Type safety5
- Optionals5
- Best UI concept5
- Super addicting language, great people, open, elegant5
- Its friendly4
- Swift is faster than Objective-C4
- Feels like a better C++4
- Highly Readable codes4
- Fail-safe4
- Powerful4
- Faster and looks better4
- Much more fun3
- Easy to learn and work3
- Protocol extensions3
- Native3
- Its fun and damn fast3
- Strong Type safety3
- Easy to Maintain3
- 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
- Its classes compile to roughly 300 lines of assembly1
- Complicated process for exporting modules1
- Very irritatingly picky about things that’s1
- 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 )
Java
- Great libraries587
- Widely used441
- Excellent tooling400
- Huge amount of documentation available387
- Large pool of developers available331
- Open source203
- Excellent performance200
- Great development155
- Vast array of 3rd party libraries149
- Used for android147
- Compiled Language60
- Used for Web49
- Managed memory46
- High Performance45
- Native threads44
- Statically typed42
- Easy to read35
- Great Community33
- Reliable platform29
- JVM compatibility24
- Sturdy garbage collection24
- Cross Platform Enterprise Integration21
- Good amount of APIs20
- Universal platform20
- Great Support18
- Great ecosystem13
- Lots of boilerplate11
- Backward compatible11
- Everywhere10
- Excellent SDK - JDK9
- Static typing7
- Mature language thus stable systems6
- Better than Ruby6
- Long term language6
- Cross-platform6
- Portability6
- It's Java6
- Vast Collections Library5
- Clojure5
- Used for Android development5
- Most developers favorite4
- Old tech4
- Javadoc3
- Stable platform, which many new languages depend on3
- Best martial for design3
- Great Structure3
- History3
- Testable3
- Faster than python2
- Type Safe1
- Verbosity32
- NullpointerException27
- Overcomplexity is praised in community culture16
- Nightmare to Write14
- Boiler plate code11
- Classpath hell prior to Java 98
- No REPL6
- No property4
- Non-intuitive generic implementation2
- There is not optional parameter2
- Code are too long2
- Floating-point errors2
- Returning Wildcard Types1
- Java's too statically, stronglly, and strictly typed1
- 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.
- Java platform42
- Much more productive than java32
- Concise and readable28
- Very little code needed for complex tasks27
- Dynamic language21
- Nice dynamic syntax for the jvm12
- Very fast9
- Easy to setup6
- Can work with JSON as an object6
- Literal Collections5
- Supports closures (lambdas)5
- Syntactic sugar2
- Interoperable with Java2
- Optional static typing2
- Developer Friendly2
- Groovy Code can be slower than Java Code3
- Objects cause stateful/heap mess1
related Groovy posts
Some may wonder why did we choose Grails ? Really good question :) We spent quite some time to evaluate what framework to go with and the battle was between Play Scala and Grails ( Groovy ). We have enough experience with both and, to be honest, I absolutely in love with Scala; however, the tipping point for us was the potential speed of development. Grails allows much faster development pace than Play , and as of right now this is the most important parameter. We might convert later though. Also, worth mentioning, by default Grails comes with Gradle as a build tool, so why change?
Presently, a web-based ERP is developed in Groovy on Grails. Now the ERP is getting revamped with more functionalities. Is it advisable to continue with the same software and framework or try something new especially Node.js over ExpressJS?
Python
- Great libraries1.1K
- Readable code937
- Beautiful code830
- Rapid development774
- Large community677
- Open source422
- Elegant381
- Great community273
- Object oriented266
- Dynamic typing211
- Great standard library73
- Very fast54
- Functional programming51
- Scientific computing40
- Easy to learn39
- Great documentation32
- Productivity25
- Matlab alternative25
- Easy to read24
- Simple is better than complex20
- It's the way I think18
- Imperative17
- Free15
- Very programmer and non-programmer friendly15
- Powerfull language14
- Powerful14
- Fast and simple13
- Machine learning support12
- Scripting12
- Explicit is better than implicit9
- Ease of development8
- Unlimited power8
- Clear and easy and powerfull8
- Import antigravity7
- It's lean and fun to code6
- Print "life is short, use python"6
- Great for tooling5
- There should be one-- and preferably only one --obvious5
- Python has great libraries for data processing5
- High Documented language5
- I love snakes5
- Although practicality beats purity5
- Flat is better than nested5
- Fast coding and good for competitions5
- Readability counts4
- Lists, tuples, dictionaries3
- CG industry needs3
- Now is better than never3
- Multiple Inheritence3
- Great for analytics3
- Complex is better than complicated3
- Plotting3
- Beautiful is better than ugly3
- Rapid Prototyping3
- Socially engaged community3
- List comprehensions2
- Web scraping2
- Many types of collections2
- Ys2
- Easy to setup and run smooth2
- Generators2
- Special cases aren't special enough to break the rules2
- If the implementation is hard to explain, it's a bad id2
- If the implementation is easy to explain, it may be a g2
- Simple and easy to learn2
- Import this2
- No cruft2
- Easy to learn and use2
- Flexible and easy1
- Batteries included1
- Powerful language for AI1
- Should START with this but not STICK with This1
- Good1
- It is Very easy , simple and will you be love programmi1
- Better outcome1
- إسلام هشام1
- Because of Netflix1
- A-to-Z1
- Only one way to do it1
- Pip install everything1
- Powerful0
- Pro0
- Still divided between python 2 and python 351
- Performance impact29
- Poor syntax for anonymous functions26
- GIL21
- Package management is a mess19
- Too imperative-oriented14
- Dynamic typing12
- Hard to understand12
- Very slow10
- Not everything is expression8
- Indentations matter a lot7
- Explicit self parameter in methods7
- No anonymous functions6
- Poor DSL capabilities6
- Incredibly slow6
- Requires C functions for dynamic modules6
- The "lisp style" whitespaces5
- Fake object-oriented programming5
- Hard to obfuscate5
- Threading5
- Circular import4
- The benevolent-dictator-for-life quit4
- Official documentation is unclear.4
- Lack of Syntax Sugar leads to "the pyramid of doom"4
- Not suitable for autocomplete4
- 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-performance530
- Simple, minimal syntax387
- Fun to write354
- Easy concurrency support via goroutines295
- Fast compilation times267
- Goroutines189
- Statically linked binaries that are simple to deploy177
- Simple compile build/run procedures148
- Backed by google134
- Great community131
- Garbage collection built-in50
- Built-in Testing42
- Excellent tools - gofmt, godoc etc41
- Elegant and concise like Python, fast like C38
- Awesome to Develop34
- Used for Docker25
- Flexible interface system24
- Great concurrency pattern22
- Deploy as executable22
- Open-source Integration19
- Fun to write and so many feature out of the box16
- Easy to read15
- Its Simple and Heavy duty14
- Go is God14
- Powerful and simple13
- Easy to deploy13
- Concurrency11
- Best language for concurrency11
- Safe GOTOs10
- Rich standard library10
- Clean code, high performance9
- Easy setup9
- Simplicity, Concurrency, Performance8
- High performance8
- Hassle free deployment8
- Used by Giants of the industry7
- Single binary avoids library dependency issues7
- Cross compiling6
- Simple, powerful, and great performance6
- Excellent tooling5
- Very sophisticated syntax5
- Gofmt5
- WYSIWYG5
- Garbage Collection5
- Widely used4
- Kubernetes written on Go4
- Keep it simple and stupid3
- No generics1
- Operator goto1
- You waste time in plumbing code catching errors41
- Verbose25
- Packages and their path dependencies are braindead22
- Google's documentations aren't beginer friendly15
- Dependency management when working on multiple projects15
- Automatic garbage collection overheads10
- Uncommon syntax8
- Type system is lacking (no generics, etc)6
- Collection framework is lacking (list, set, map)2
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
- Learn once write everywhere204
- Cross platform166
- Javascript162
- Native ios components118
- Built by facebook67
- Easy to learn62
- Bridges me into ios development43
- It's just react40
- No compile39
- Declarative36
- Fast21
- Virtual Dom12
- Livereload12
- Insanely fast develop / test cycle11
- Great community10
- Easy setup9
- Backed by Facebook9
- It is free and open source9
- Native android components8
- Highly customizable7
- Scalable6
- Everything component6
- Awesome6
- Win win solution of hybrid app6
- Great errors6
- Not dependent on anything such as Angular5
- Simple5
- OTA update4
- Awesome, easy starting from scratch4
- Easy to use3
- As good as Native without any performance concerns3
- Web development meets Mobile development2
- Hot reload2
- Over the air update (Flutter lacks)2
- 'It's just react'2
- Many salary2
- Can be incrementally added to existing native apps2
- Nigger1
- Cons1
- Ngon1
- Ful0
- Javascript23
- Built by facebook18
- Cant use CSS12
- 30 FPS Limit4
- Slow2
- Some compenents not truly native2
- Generate large apk even for a simple app2
related React Native posts









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.
















I'm working as one of the engineering leads in RunaHR. As our platform is a Saas, we thought It'd be good to have an API (We chose Ruby and Rails for this) and a SPA (built with React and Redux ) connected. We started the SPA with Create React App since It's pretty easy to start.
We use Jest as the testing framework and react-testing-library to test React components. In Rails we make tests using RSpec.
Our main database is PostgreSQL, but we also use MongoDB to store some type of data. We started to use Redis for cache and other time sensitive operations.
We have a couple of extra projects: One is an Employee app built with React Native and the other is an internal back office dashboard built with Next.js for the client and Python in the backend side.
Since we have different frontend apps we have found useful to have Bit to document visual components and utils in JavaScript.
- Hot Reload124
- Cross platform104
- Performance97
- Backed by Google80
- Compiled into Native Code66
- Fast Development52
- Open Source51
- Fast Prototyping46
- Expressive and Flexible UI43
- Single Codebase40
- Reactive Programming35
- Material Design30
- Widget-based24
- Target to Fuchsia23
- Dart23
- IOS + Android17
- Easy to learn14
- Tooling13
- You can use it as mobile, web, Server development13
- Great CLI Support13
- Good docs & sample code11
- Debugging quickly11
- Have built-in Material theme11
- Target to Android10
- Support by multiple IDE: Android Studio, VS Code, XCode10
- Community10
- Easy Testing Support9
- Written by Dart, which is easy to read code9
- Have built-in Cupertino theme8
- Target to iOS8
- Easy to Widget Test7
- Easy to Unit Test7
- Real platform free framework of the future7
- Flutter is awesome7
- F1
- Need to learn Dart28
- No 3D Graphics Engine Support10
- Lack of community support9
- Graphics programming7
- Lack of friendly documentation6
- Lack of promotion2
- Https://iphtechnologies.com/difference-between-flutter1
related Flutter posts









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.
Hi, I'm considering building a social marketplace app on android, ios and web, Flutter seems to be a good UI framework for cross-platform apps, it's safe type, hot reload, and native compiling on native machine code (thanks to Dart). My question is, for an MVP product is it a good choice? if yes, will it be on the mid-term, long term? Or will I have to change as the users grow?
thank you