If you’ve ever done Web development, you might think we’re at the beginning of a new era. For years we’ve been using frameworks like Django Rails that are based on Python, Ruby, and PHP, all of which are based on the old request-response cycle. This phrase is used for lack of a better technical term.
The pattern looks like this: a request is sent from the client to the server, which then renders an HTML page and returns the page to the client. While AJAX, JSON, and a host of frameworks with built-in client-side rendering capabilities (such as Ember, Angular, Knockout, Backone, and most recently React) have made this pattern less dominant in Web development than it was a decade ago, But in many cases we still use development languages and frameworks that don’t fit this pattern.
Years ago, Python and Ruby were slow, but we were happy to use them. But as we increasingly design servers to be REST apis that can send JSON to different clients, it’s time for most people to find a replacement for them.
You see a lot of competitors trying to fill that gap. Some fanciful developers use Rust, Nim, or Haskell to do this, while others use JVM-based languages such as Scala or Clojure (because the JVM handles multithreading well), but by far the most discussed, The blackest ones are NodeJS and Go. Neither of them is elegant.
Prior to ES6, much of JavaScript was crap, but much of the current bias against JavaScirpt is based on prior knowledge rather than current knowledge. As I said earlier, I personally think JavaScript is perfectly acceptable, especially if you use supersets based on it, such as Typescript. The advantage of JavaScript is that it is relatively fast, already used in browsers (this may change in the future with WebAssembly), and is inherently asynchronous, which makes it ideal for modern Web development (web app development is not limited to HTML pages).
Although JavaScript has some drawbacks, in particular the syntax is ugly and cumbersome. But it continues to standardize, which makes it better and better, and that’s what I like most about it. Some improvements to JavaScript are needed to make it usable. With many agencies involved in the ES standardization process, some worry that JavaScript will become particularly bloated. That’s what I’m worried about. It would be nice if there were a single force behind JavaScript, but I’m not sure that’s going to happen. Or, if so, whether the force is capable of maintaining JavaScript. The fact that Microsoft, Google, Mozilla and others are all involved is a double-edged sword.
In the end, JavaScript handles modern Web development pretty well, but it’s not perfect. If a request is CPU intensive, then every user in the system needs to wait. While the Promise object reduces callback hell, we’re still basically masking the flaws in JavaScript’s core syntax and trying to fix it. Will JavaScript handle multithreading well enough to solve the above problems? Web Workers is a form of IPC, and if you use this model to handle concurrency, JavaScript doesn’t go much further than Python (I know Aysncio, but I’m talking GIL here).
There are only a few languages that are really suitable for handling concurrency, and one of them is Go, which uses Goroutines and channels, which is its main attraction. Other advantages of Go include speed, simplicity, dynamic typing, and the simplicity and finality of compiled files.
In the discussion of Go, these advantages seem to be a dividing line that is often overlooked. Many developers who have used, or still use, more modern languages such as Haskll find Go scary because of its lack of features. And I can’t understand why you tied your hands with Go. On the other hand, if you actually listen to some of the Go users, you’ll see that this is the Go selling point: the language has to be streamlined so that it can be understood in a short time. And whatever it’s missing, you can write tons of code to fix it. It’s annoying but it works. I’ve worked in more esoteric languages, so I’m not a mindless fan of Go, and many Go users are mindless fans of boring language arguments. But after more than a decade of programming in many languages, I just wanted a language that was simple and worked for me. It’s a concession I’m willing to make, and I’m sure many Go users feel the same way.
As said, have you tried developing web applications with Go? You can do that, but it’s not a pleasant process. What are the great form-handling libraries in Python and Ruby? Yeah, they’re not very good. You can try to write functions to validate different form inputs, but you may be limited by the type system and find that some things are not as easy to do as in your previous language. Database processing is more tedious, and labeled models are ugly for JSON, databases, and so on. Go is not an ideal solution. I love simplicity, but Web development is tedious, and Go just makes things worse.
Go is often blacklisted in language discussions because it was originally billed as a “system language,” but it is absurd to say that Go will replace C or C++. Go developers have been surprised that many of Go’s improvements come from dynamic languages such as Python rather than C or C++. The term “system language” doesn’t mean much when it comes to distinguishing between development languages. But inside Google, where there are a lot of servers and systems, the term “system language” makes sense. To be honest, Go is really good for developing some applications, basic programs (like Docker), and small command-line tools. But in other places, such as developing Web applications, I don’t think Go is appropriate. Because this is outside the scope of what it calls a “system language.”
Review images
(Picture: Logo in Elixir)
Yet there is a language that fits the bill, and even the picky and the simple will be thrilled with it. Assuming you read the title of this article, you know I’m talking about Elixir. Elixir is a very lightweight Ruby-like language that will eventually be compiled to run on the BEAM platform, the Erlang virtual machine. Erlang was created by Ericsson, and the systems that run on Erlang have lasted an incredible number of decades. One of the reasons why it’s so awesome is that Erlang processes are very lightweight, hundreds of processes can be created in a flash. This is the essence of concurrency, and it’s quite elegant. It allows apps like WhatsApp to run with very few servers and engineers.
I don’t want to say too much about concurrency, mainly because other people would do it better. What you really need to know is that When it comes to concurrency, Erlang/Elixir does it better than any other language. The main thing I want to talk about is Elixir’s own quality.
Do you want a modern programming language? Elixir is functional, immutable, and supports pattern matching, which is like putting hormones on your code. These explanations alone won’t make any difference to your view of programming. Elixir also supports macros, which means that the core of the language can remain small, but users can extend it to support patterns that even the language designers didn’t think of. As I said earlier, Elixir implements these things using a Ruby-like syntax. Grammar shouldn’t be the problem, but it is. I had tried to design a list language (or a syntax that I could accept) with some poetry in the syntax (which I thought was pretty cool), but Elixir shocked me with its concise core syntax and natural functional programming, and it was the heir to Scheme.
That’s what attracted me most about Elixir, which is very small, even though it’s a very modern language. You can read through the language guide in just a few hours and get a good understanding of the core concepts. I like that. I prefer to spend my time solving problems rather than figuring out what concepts to use in the language. It also takes less time to master the language. Take 10 concepts 100 times each, and 100 concepts 10 times each, and you’ll see intuitively that the former is significantly faster than the latter.
So WHAT I mean is? I think we’re going to be in an era of multilingual programming. If you’re planning on learning more development languages, it becomes increasingly unrealistic. Using Elixir to implement a REST API server, you will most likely still need to call Python (or some other language) scripts for other tasks. But the point is that Elixir’s frameworks (such as Phoneix) and class libraries (such as Rcto) seem better suited to Web development than the alternative languages. If the only thing Elixir can do well (and it does) is connect to the Postgres database and convert the data to JSON, then this pattern is consistent with the Unix philosophy (programs do one thing, and do it well).
If we find ourselves in a situation where users are willing to give up a large number of class libraries in their programming language in order to find a more suitable tool. Elixir seems like a better choice than Go. Both are compact languages, but Elixir has a ton of features that not only allow you to grow as a programmer, but also make your programs elegant over time.