ES6 vs Scala: What are the differences?
What is Scala? A pure-bred object-oriented language that runs on the JVM. 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.
ES6 and Scala can be primarily classified as "Languages" tools.
"ES6 code is shorter than traditional JS" is the primary reason why developers consider ES6 over the competitors, whereas "Static typing" was stated as the key factor in picking Scala.
Scala is an open source tool with 11.8K GitHub stars and 2.75K GitHub forks. Here's a link to Scala's open source repository on GitHub.
Slack, StackShare, and ebay are some of the popular companies that use ES6, whereas Scala is used by Twitter, Coursera, and 9GAG. ES6 has a broader approval, being mentioned in 1461 company stacks & 1725 developers stacks; compared to Scala, which is listed in 437 company stacks and 324 developer stacks.
What is ES6?
What is Scala?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to add, upvote and see more prosMake informed product decisions
What are the cons of using ES6?
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
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.
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!
I think next step could be to use Koa but I am not sure.
We are always building new features and replacing old code at StackShare. Lately we have been building out new features for the frontend, and removing a lot of old jQuery code (sorry jQuery but it's time to go).
As we've moved towards the above tech, its really made smashing out new features and updating legacy code super fast, and really fun!
Obviously, using ES6 and TypeScript is what makes it decent in browser contexts. Throw in a bit of React and now we're cooking with gas!
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?
Why I am using Haskell in my free time?
I have 3 reasons for it. I am looking for:
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.
The power of SSR React and then hydrating it client-side to add interactivity and App-like feel is what makes Gatsby powerful.
It comes with a ton of plugins, that are mind-boggling: Image Processing, GraphQL, Node.js, and so much more. This is thanks to a great ecosystem, a great user-base and the revolutionary Community work, which led to the Gatsby repo to be one of the most committed to, out there.
We are phasing out jQuery and jQuery UI in favour or Vue.js and @Vue-cli so we can support building a modern, well-architectured frontend.
For markup and style, I used Pug and Sass, since they’re the perfect match to me. I love the clean and strict syntax of both of them and even more that their structure is almost similar. Also, both of them come with an expanded functionality such as mixins, loops and so on related to their “siblings” (HTML and CSS). Both of them require nesting and prevent untidy code, which can be a huge advantage when working in teams. I used JSON to store data (since the data quantity on my website is moderate) – JSON works also good in combo with Pug, using for loops, based on the JSON Objects for example.
To send my contact form I used PHP, since sending emails using PHP is still relatively convenient, simple and easy done.
DevOps: Of course, I used Git to do my version management (which I even do in smaller projects like my website just have an additional backup of my code). On top of that I used GitHub since it now supports private repository for free accounts (which I am using for my own). I use Babel to use ES6 functionality such as arrow functions and so on, and still don’t losing cross browser compatibility.
Side note: I used npm for package management. 🎉
Scala is the God of languages. A legend. The Mount Rushmore of hybrid OO/functional languages is Scala's face four times over.
Ok, honestly, we love Scala. We love(d) Java (and it's parents C and C++), and we love(d) all the languages that borrowed cough stole cough from Java over the years such as Groovy, Clojure, and C#.
It may not be perfect (it totally is, but since programming languages don't have egos of their own, we don't want to paint it too bright), but it is awesome. It runs on the JVM, you can utilize Spring, it works great for data processing (which is sorta kinda the thing we do here, folks), and it just makes sense at all levels.
Nearly our entire server codebase is written in Scala (if you haven't heard of it, it's a programming language that is basically what you would get if Java + ML had a baby). This has worked out super well. It enables us to write concise easy to deal with code that is typechecked at compile time. It's also been a big help with recruiting.
We started using CoffeeScript years ago, so the switch to ES6 is quite natural in our team. ES6 of course advances the JS standard to a level of an advanced language. We are using it today simply because it: 1. helps to keep the code shorter, 2. integrates easily with JSX, 3. helps to deal with immutable using const.
worked with scala for around 2 years. really enjoyed the language and getting back into the world of functional. unfortunately the community is heavily fragmented and the language itself broken and inconsistent. that with the various factions involved made it a put of for long term investment.
Scala, Akka and Spray (which became Akka-Http) provided the building blocks for the menu service.
Akka's actors and finite-state machine were a natural way to model a USSD menu (a series of stateful interactions between a subscriber and the USSD gateway).
Replaces entirely the Java Language to build a much more expressive and powerful code on the backend, while leveraging at the same time the Java Platform Tools and Frameworks, is a mixture of old and mature with new and sexy.
ES6 brings some sweet features to the language. Our favourites are lambda-expressions, block-scoped consts and lets and Promises.