Hacker News Reader

Comment by bitcracker | Hacker News Reader

One serious thing Lua is still missing is native Unicode support (correct me if I am wrong).

When I discovered Lua the first time I was enthusiastic. The JIT is so fast, and everything seems to be fine. But missing Unicode is a big disadvantage for Lua. Unicode is a must to have for modern languages. It makes things so much easier when you know you don't have to convert any fonts because they are all presentable in Unicode.

View on HN

After having worked with Ruby 1.8 (no unicode support in String) and Ruby 1.9 (added unicode) rather extensively, as well as C/Obj-C and a variety of other languages with varying ideas on Unicode support, I am of the opinion that Lua has the right approach. If your built-in string type does not account for encodings, you can always build one on top of it that does. If, on the other hand, your built-in type has to carry the constant burden of encoding information, you'll never get away from that (indeed, I've been talking with ruby-core about adding back a string-like library with no encoding information in Ruby 2.0).

As long as you handle usual letters it is no problem to miss Unicode.

How nice Unicode is I always realize when I copy and paste some foreign text from somewhere into Emacs or Racket Scheme and everything works just fine.

What he's trying to say is that Lua's strings are capable of storing Unicode characters (they're "8-bit clean"), but that Lua's string manipulation functions aren't Unicode-aware. If you want to paste Unicode characters into a string and print it later, Lua can handle it. If you want to do a pattern match on a Unicode string, you need to bring your own pattern matcher.

The idea of adding at least some rudimentary UTF-8 support has been gaining traction on the Lua mailing list. So maybe for the next version of Lua you'll see some sweet Unicode.

Very good!

Reply on news.ycombinator.com