innocentoldguy

What quality issues have you experienced? I've owned almost every Apple Watch since their debut and have never had an issue with any of them.

One of the things I love most about Elixir is that it makes asynchronous error handling easier than any other language I've used. Asynchronous code used to be the source of many difficult bugs in the teams I've worked with, but Elixir's (or, more accurately, Erlang's) "let it crash" architecture helps eliminate many of these issues.

I used Dvorak when I injured my dominant hand. It took me about two weeks to feel comfortable with it. My hand healed a long time ago, but I still use Dvorak (the two handed version mostly) because I think it is easier than Qwerty. I highly recommend this solution.

I found an old, unopened Apple box containing a Japanese Apple II Plus while cleaning out my in-laws house last month. I also found a fake-leather carrying case for it (also unopened). Both are from 1979.

It was interesting to discover that the Apple II Plus' ROM didn't support Kanji, but there were third-party add-on cards that added Kanji support. The Apple II Plus I found had a Multitech Kanji Card with it. Multitech later became Acer.

What do you mean by "develop environment"? Are you referring to IDE support or features like mix, IEx, pry, releases, etc.?

If the latter, Elixir has one of the best development environments, in my opinion. Mix is fantastic, releases are easy, and Elixir's error messages in IEx are the clearest I've seen in my 30+ year career.

I use Emacs to write code, and beyond syntax coloring, I don't want anything else, so you may have a point if you're talking about IDE support.

The inability to contact a human who can make meaningful decisions is one of the reasons why I quit using companies like Google and Amazon. They’re too big to care, but small companies aren’t.

EDIT: I have hooves for hands and accidentally submitted before finishing my thought.

This is probably because C NIFs run in the same process as the Erlang scheduler. If you have a long-running or blocking NIF, it can starve the scheduler and cause significant performance degradation across the system.

Why? The business logic part is where Elixir outshines Gleam the most, isn’t it? What do you gain by doing this?

(I am genuinely curious and not trying to be snarky.)

I can't remember which version of Erlang was the most current when I started learning Elixir, but I do know that it was years before OTP 20, which fixed its string issues. Prior to that, Erlang didn't have very good string support for internationalization (I do a lot of Japanese language programming). Elixir, on the other hand, did. Otherwise, I may have gone with Erlang back then.

I like Erlang a lot, too. Both are great languages.

Gleam lacks lisp-style macros, and its implementations of BEAM and OTP are not exhaustive. For example, Gleam does not support:

- Hot updates.

- Full distributed system support.

– Low-level process manipulation.

- Named processes.

- Advanced supervision strategies.

- Behaviours other than GenServer.

- Type-safe distributed messaging.

- And several other things that I value in BEAM and OTP.

I can't justify trading the full power of BEAM and OTP for static typing. To be fair, though, I've written a lot of code in both statically and dynamically typed languages, and static typing isn't something I value much (to the point that you might say I don't care about it at all :D).

I worked with Elixir for over five years without knowing anything about Erlang. I know Erlang now, but only because I was interested in learning it, not because I needed to do so to write Elixir code.

I think Clojure is the better option if you want to do FP using the JVM ecosystem. The problem (for me, anyway) I've run into with Scala is that it supports both functional programming and object-oriented programming. Every code base I've worked on in Scala has ended up being a hodgepodge of both, which I find annoying.

However, the best functional programming language is, of course, Elixir. :D

I think you’re right. I only picked up Elixir about 10 years ago after getting frustrated with Python’s GIL and Java’s cumbersomeness, and feeling that object oriented programming over complicates things and never lived up to its hype.

I have never looked back.

Elixir is an absolute joy to use. It simplifies multi-threaded programming, pattern-matching makes code easier to understand and maintain, and it is magnitudes faster to code in than Java. For me, Elixir’s version of functional programming provides the ease of development that OOP promised and failed to deliver.

In my opinion, Elixir is software engineering’s best kept secret.

I have implemented Elixir in critical financial applications, B2B growth intelligence applications, fraud detection applications, scan-and-go shopping applications, and several others.

In every case, like the engineering team in this article demonstrates, the developer experience and end results have exceeded expectations. If you haven’t used Elixir, you should give it a try.

Edit: Fixed an editing error.

Thanks, Deng! I'm one of those Emacs users who has been using Emacs for years, and I didn't know Emacs Calc existed.

Reading the manual now...

I'm sure Gleam fits a niche—maybe something similar to Elm?—but I can't justify using it over Elixir because I'm not willing to trade things like

1. Full access to the BEAM.

2. Full access to OTP behaviours and other features.

3. Lisp-style macros.

4. Late-bound function calls.

5. Dynamic message passing.

6. Native supervision trees.

7. Internationalization.

for static types. Doing so feels like trading my car's engine for a suction cup phone holder.

(EDIT: Fixed formatting.)

I spent a lot of time objectively evaluating languages for a new project I built several years ago. Elixir won out. It has now been 12 years and I still believe Elixir was the right choice for the following reasons (this list is not exhaustive):

BEAM handles concurrency better than the JVM.

Elixir threads are implemented using private memory where Clojure uses public memory.

Mix is superior to Clojure’s tooling.

Elixir is easier to learn and write.

OTP is fantastic.

Phoenix is an excellent web framework.

My Tesla drives itself virtually everywhere. All I have to do is look out the window, which I'd do anyway. The only times I control my Tesla are when pulling in and out of my garage and when I need to get it going so FSD can take over (and occasionally when parking).

I'm happy with it.

I disagree. I understand that Musk invested in OpenAI under the understanding that ChatGPT would remain open source. He has expressed dissatisfaction with the direction OpenAI has taken ChatGPT and wants to return it to its original charitable mission. He paid millions of dollars for something that OpenAI didn't deliver, so I can understand him wanting to bring the project back inline with the vision he paid for.

I view Musk's decision here as a good thing that will benefit the world.

I came to the opposite conclusion for the following reasons:

1. IEx provides a robust and interactive debugging environment that allows me to dig into whatever I want, even when running in production. I've never lost state in IEx, but that happens fairly often in CIDER and nREPL.

2. IEx uses Elixir's compilation model, which is a lot faster than CIDER and nREPL, leading to faster debugging cycles.

3. IEx is tightly integrated with Elixir whereas Clojure's tools are more fragmented.

4. IEx doesn't carry the overhead of additional middleware that CIDER and nREPL do.

I'm also not a fan of JVM deployments, so I've migrated all my code away from Clojure to Elixir during the past 10 years.

Yes, 自動 is a common prefix in Japanese that means automatic. So, in your example, the first two kanji mean automatic and the last kanji means car.

自動車 (jidousha): Automobile

Other examples include:

自動販売機 (jidouhanbaiki): Vending machine

自動ドア (jidoudoa): Automatic door

自動エリクサー (jidouerikusa-): Automatic Elixir (joking)

I like that you included instructions on disabling and enabling auto_reload manually from within IEx.

    IEx.configure(auto_reload: true)

Sometimes, it is helpful to override your .iex.exs settings for a moment, and it is nice that you showed readers how to do that with :auto_reload.

Here are some examples of other settings you can manually override from within IEx:

    Logger.configure(level: :debug)
    Logger.configure(level: :error)
    Logger.configure(level: :info)
    Logger.configure(level: :none)
    Logger.configure(level: :warn)

    Logger.add_backend(:console)
    Logger.remove_backend(:console)

The difference between Logger.configure(level: :none) and Logger.remove_backend(:console) is that all log messages are filtered out with the first option, but the logging system remains active, whereas the second option completely removes the console backend from the logging system. Both are helpful when debugging an issue on a busy system with lots of output flying by in IEx.

I've never used an IDE to write code, though I have tested a few out on the recommendation of others. For 30+ years, I've only used these plain-text editors in this order: Vi, Vim, NeoVim, Emacs, Kakoune, and now Helix (I used Vim for most of that time).

I guess I keep everything in my head and use reference materials when I forget something.

IDEs bother me. I enjoy working in the terminal and have always found using a mouse while writing code annoying. I also dislike having tabs, buttons, menus, drop-downs, pop-ups, etc., in my way while I think and write code.

True. Elixir doesn't get the respect it deserves on Hacker News.

One of the biggest things I dislike about Django is its lack of a standard project structure. I haven't used it in years, so things may be different now, but back in the day, even the core team recommended against using the default project layout, which always made me wonder why they generated new apps that way.

Switching between Django projects while doing contract work was always a "what the hell?" experience. Rails' opinionated nature makes it easy to dive into new projects you know virtually nothing about.

Nowadays, I focus exclusively on Elixir/Phoenix apps. Elixir eliminates the OOP requirement (I've never liked OOP because I don't feel it remotely lives up to the hype) while maintaining all the other great things I love about Rails, like consistent project layouts. It also makes writing multi-threaded, distributed apps easy.

I got sick of programming, so I switched to management and then technical writing, but soon realized that it is bureaucratic corporate America and its focus on process over achievement that I dislike.

I then discovered that I do like programming. I just don’t want to do it with anyone else.

Thanks for this write-up. I have worked with a lot of Java engineers who have learned Elixir and make this mistake all the time. In the future, I’ll point them to this article.

Here's some information on it. https://gekk.info/articles/towns-tour.html

EDIT: Here are some of the highlights:

• Towns OS had a custom GUI that was fairly advanced for the time.

• Towns OS included multimedia support.

• Towns OS had an API that provided advanced sound and graphics capabilities.

• Towns OS included support for overlaying videos in different modes, which boosted gaming and multimedia support.

• The FM Towns computers came standard with a mouse and gamepad in an era when PCs typically didn't have these things.

Did you read it? It clearly says the team was far too big, and that even members of Obama's team felt it was too large, so Trump shrunk and reorganized it.

My comment isn't about compiled vs. bytecode languages. It's about memory management. For example:

• In Elixir, each process runs in isolation, has its own heap, and prevents one process from directly accessing or corrupting the memory of another process. In contrast, Goroutines share the same address space, which means that a bug in one goroutine can potentially corrupt the shared memory and affect other code.

• Elixir uses immutable data structures by default, so nothing can be changed in place. Go, on the other hand, allows mutable state, which can lead to race conditions if not managed correctly. In other words, Elixir is inherently thread safe and Go is not.

• Elixir uses a generational garbage collector with per-process heaps, meaning that the garbage collection of one process can't impact another process. In contrast, Go uses a mark-sweep garbage collector across its entire memory space. This can cause global pauses that can open a window for denial-of-service attacks.

• Elixir uses supervisor processes to monitor operational processes and restart them if they crash. Go's error handling can lead to memory leaks and other undefined behavior if not carefully managed.

• Elixir inherently protects against race conditions, whereas Go relies on tools like the race detector and developer onus to avoid them.