161–170 of 183 posts
With very little effort or development time we where able to put together a highly scalable solution that is robust and very low maintenance.
Earlier quoted context omitted.
Not sure about the BEAM, but Java isn't considered an interpreted language at all. First, discerning the compilation step to IR is relevant, which is why for example, Python can be compiled or interpreted. That distinction matters. Even though it is compiled to intermediate representation, it is still compiled. Now, with regards to the intermediate representation, Java Byte Code is also not interpreted. Java Byte Cod…
Java is an interpreted language because you always need a JVM to run it. I even if you distribute the runtime with your code as one package, that’s just an artificial distinction. Regardless, interpreted does not mean bad, or poor performance for your task. It’s a technical notion. Most people would say Python is interpreted, even if you are only running compile python bytecode on a JIT like PyPy. That’s exactly the…
This makes Java a compiled language, even though it is compiled to machine code for a machine that doesn't exist. Java Byte Code is an assembly language, and in fact, Sun had at one point machines that were natively using Java Byte Code instruction sets.
Now Java Byte Code is trickier. You could consider it to be interpreted or compiled or both. It is fair to say that in general it is interpreted, but it is just as fair to say it is in general compiled.
What matters most though is to understand that modern JVMs make use of a JIT compiler and optional AOT compilers.
In the latter mode, you can compile Java Byte Code to native machine executables ahead of time or pre-runtime and no JVM beyond that point is required. So you can distribute the app as a self-contained executable. In most cases though, this will be less performant in the average and peak performance, but it will speed up the worst case, such as start time.
In the former mode, the JVM will analyze runtime behavior and based on the frequency of use of various code paths, it will either compile the code to native machine code (cache the compiled code), and then run the freshly compiled code block, or it will choose to interpret the byte code directly. This allows aggressive optimization from information which is only available or easily available at runtime when performing compilation.
Earlier quoted context omitted.
Sure. Here's a gist with 3 versions (original, the 25ms version and the 3ms version): https://gist.github.com/nickjj/99ea84f460f41dae4139d0610ce80... The reason I didn't use the 3ms version was due to it having too many concepts that are unknown to me. At the end of the day I would still need to maintain the code and the 25ms version is a lot easier to change (for me at least). But, if I had very strict time requirem…
I suspect the 3ms version is still hamstrung by the system rng :) I might try to make it even faster if you don't mind!!
Earlier quoted context omitted.
I love hearing stories like yours. I wonder how Elixir would compare to Clojure, which I've used and liked for web development for many years. I hear nothing but good things about Elixir but I wonder if it would bring something new to the table for me in the "really liking it" category.
Relatively, JVM and Clojure ecosystem is much more mature and performant. I would any day prefer Clojure and framework Pedestal. https://github.com/pedestal/pedestal
Earlier quoted context omitted.
For CPU intensive tasks, performance _is_ close to Ruby, while both Ruby and Elixir are far behind Go. Soft realtime doesn't mean fast, it just means good std deviation on response time and not a lot of missed deadlines. Fortunately as the article points out, there's always Rustler if you need to optimize while still keeping BEAM crash proof. That being said, I agree that performance for certain IO intensive applicat…
>>For CPU intensive tasks, performance _is_ close to Ruby, while both Ruby and Elixir are far behind Go. Yeah, but how many companies do you know of that perform heavy computations in such large scale that their choice of programming language has a noticeable effect on the result? I mean, it might matter for tech giants like Google, who need to squeeze every bit of processing power out of their CPUs. For almost every…
I'm currently working on my side project the backend for which I've chosen elixir to go with. Looking at performance and long term maintainability, it doesn't seem to be a sucker like rails. No magic, no hacky patterns. No mess like the one you see with Node. For what it does the platform is hella stable. I drifted towards Go for a little bit but man, code in Go felt too verbose with weird patterns. Go is a solid pla…
The immutability and the lack of magic you mention are probably the two main reasons Elixir projects are easier to jump into. Even when macros are involved, you can still scroll to the top of the file, look at line with "use" or "using" in it and know exactly what is affecting your module.
With a lot of other languages, it's completely unknowable from inside one file to know where or if external metaprogramming is affecting your module.
I'm currently building a video course hosting platform with Elixir / Phoenix and all I can really say is this has been the nicest tech stack I've ever used in 20 years of web development. IMO it really does feel like you get the best of everything (developer productivity, developer happiness, great language for creating maintainable code, OTP and the BEAM bring a lot to the table, it's memory efficient, tracing code…
I think a big part of it has been a lack of learning resources. A major part of why I started my site and YT channel was the frustration I had learning Elixir in 2016. Phoenix was even tougher. At that time, even the paid resources were mostly out of date. I found about 70% of everything I came across (books, videos, blog posts) wouldn't compile on Elixir version > 1.0! The changes in Phoenix 1.2 and 1.3 were a similar story.
The one exception to this was Dave Thomas's Programming Elixir book. I bought version 1.2 and he religiously updated it (for free!) all the way through its current version. I never found anything in it that didn't work on the current version of the language. Well done, Dave!
I'm currently building a video course hosting platform with Elixir / Phoenix and all I can really say is this has been the nicest tech stack I've ever used in 20 years of web development. IMO it really does feel like you get the best of everything (developer productivity, developer happiness, great language for creating maintainable code, OTP and the BEAM bring a lot to the table, it's memory efficient, tracing code…
I love hearing stories like yours. I wonder how Elixir would compare to Clojure, which I've used and liked for web development for many years. I hear nothing but good things about Elixir but I wonder if it would bring something new to the table for me in the "really liking it" category.
Wanted to thank you again for making these videos, I learned a ton and I'm really into Elixir now. If only there was a way to use it at work!
One of my favorite things about Elixir is Erlang/OTP. It's as if you're in Disneyland and everything's nice and colorful. But sometimes you go into a basement and you discover the entire thing is built on top of ancient Jedi ruins and these immortal, powerful forces lurk just beneath the surface, at your disposal.
Clojure is the opposite. It's all nice and fine as long as you're in Clojureland, but then you look behind the curtain and it's a huge pile of cards and matchsticks that hold everything together, and the glue is made of mutable state and classes.
And man, the tooling. I can't say this enough. It took me about 3 seconds to create a new project with mix new to get the unit tests and everything set up for the flatten challenge. I don't even know how to set up unit tests in Clojure, and I've been playing with it for 5 years.
So basically OTP == "ancient Jedi ruins" :D
Earlier quoted context omitted.
- deployment is terrible like really bad - average performance ( like 10x slower than Java even worse for CPU intensive tasks ) - dynamic language ( this is the worst part ), working on large code base means problems ahead - lot of features from BEAM / OTP that are not that useful and done better on modern cloud platforms ( Kubernetes for instance does a lot of similar things but better and more flexible, apply to an…
Distillery is a pain to set up, but once done, deployment is as easy as: mix edeliver build release production && mix edeliver deploy release production I've set this up as an alias in mix.exs to I just have to type: mix deploy 1.9 makes configuration easier than Distillery, I think.
Earlier quoted context omitted.
> I don't think I've liked a technology this much ever and I'm honestly surprised it's not already more popular than it already is. To be honest, this can probably be almost 100% attributed to the fact that it is not backed and heavily promoted by a tech giant.
I love Elixir, but the learning curve was steep. Async everything, dialyzer, macros, Erlang errors, charlist vs string vs iolist... It was a lot to take in. Edit: 4 upvotes in 4 minutes. I guess people are reading this... for anyone who hasn't already discovered it, the saving grace for me was the Elixir Slack channel. I also learned while working with someone who really knows Erlang, which helped quite a bit, too. I…
You can be very productive with Elixir before learning the things that it's famous for!