
How is Ruby different in Japan? - galfarragem
https://appfolio-engineering.squarespace.com/appfolio-engineering/2017/5/24/how-is-ruby-different-in-japan
======
phamilton
I think "not Rails" should be expanded a bit, because it risks someone saying
"ok, so... sinatra?"

Web applications have some very distinct profiles. Most requests:

1\. Parse HTTP

2\. Parse the request body (likely JSON), build ruby objects from the data.

3\. Load data from a datastore, builds ruby objects from the data.

4\. Do some manipulation of data.

5\. Serialize Ruby objects into a response.

Basically, because of the stateless nature of a web request, most of the work
done (ignoring IO) is serializing and deserializing data. By not having Ruby
be responsible for the state of our application, we make Ruby responsible for
fetching and sending the state.

Now think about a stateful system (like we would have with embedded Ruby). The
state is kept within Ruby for the most part. We don't have to hit a data store
to restore state every time we want to do something. This significantly
changes the operating profile of the application, and therefore the
optimization strategy changes.

~~~
di4na
That. I have a full talk based on that coming for the Elixir community.

~~~
chao-
Are you able to share where or when I should be on the lookout for this talk?
This is my exact area of interest.

~~~
di4na
Not accepted yet, CFP decisions are at the end of the week.

If it is not accepted, i will do it at the London Elixir meetup.

~~~
reledi
Does CodeNode publicly release recordings that they make of meetup talks?

~~~
di4na
yes

------
btilly
It is worth noting that the original reason for Ruby is that 20 years ago
there was no scripting language which could handle Japanese text.

Hence a Lisp hacker decided to write a scripting language which could do so
using the Smalltalk object model with a library carefully designed to would
work a lot like Perl. The result was Ruby.

~~~
euske
Blatantly false. Perl4 could handle Japanese text perfectly okay in early 90s.
Neither Perl or Ruby supported character encoding initially and you had to
rely on NKF/KConv etc.

~~~
wodenokoto
Being able to handle Japanese and being able to handle character encodings are
two very different things.

Python 2.7 (byte) strings handle Japanese characters just fine for a lot of
cases.

I don't think you nor parent have made a clear point for either case

~~~
chongli
_Python 2.7 (byte) strings handle Japanese characters just fine for a lot of
cases._

Python 2.7 was released in 2010, 15 years after the release of Ruby. At the
time of Ruby's release, you were looking at Python 1.0.

~~~
masklinn
And Python 1.0 handled text (in general) in the exact same way Ruby did: by
ignoring it altogether and just manipulating bags of bytes.

------
doktrin
This is mostly orthogonal, but I'm yet another dev who loves using Ruby, but
absolutely hates Rails. Ruby is a joy to use, whereas Rails is soul sucking,
anti fun and overrated.

I haven't been paid to write a line of Ruby in over 4 years but I still use it
for the occasional hobby project. Not only do I not use Rails for fun, I'd
have to be close to starvation before I used it again for profit.

Now I feel the urge to dust off my copy of 'Eloquent Ruby' and write some fun
code.

~~~
copperx
Now I'm really curious. What framework would you prefer to use build a webapp?

I'm looking for Rails alternatives.

~~~
prh8
If you want something comparable (feature wise) to Rails, then check out
Hanami. It's much better designed for large apps. If you are looking for a
micro framework, I'd suggest Roda. I'd characterize those two as the modern
replacements for Rails/Sinatra.

~~~
cyberferret
Took a brief look at Hanami. Is it optimised for deployment to Heroku only? Or
does it support AWS Elastic Beanstalk also?

~~~
prh8
It is just like any other Rack based app, can be deployed anywhere.

------
Lordarminius
So thankfully, it would appear that Ruby is kept alive by the Japanese.

I have never really understood the craze for Python . I am by no means a guru,
but I consider Ruby a far superior language; ( yes, I recognize that the
numerous scientific and ML libraries of python make it a logical choice for
many projects, but this is sort of like a self fulfilling prophesy)

My love for Ruby declared, I have on occasion wished that we had a "strict"
feature in the language similar to ES5 that would permit only the use of
Ruby's more straightforward features and also exclude deprecated methods and
techniques. This might give the language a deserved boost.

Does anyone know what the most utilized language in Japan is ? And what
framework they use there for web projects, if not Rails ?

~~~
hetman
I used to have a preference for Ruby but Python has a single killer feature
missing for me from Ruby and that is explicitly imported module symbols.

When looking at new unfamiliar code in Ruby there's just no way of instantly
knowing which symbols come from which files/gems. There are conventions,
sometimes these are followed well, sometimes not. Either way it adds a lot to
the mental load of parsing new code or even old code you've written your self.
Ruby's module import system is just too much like C's #include.

~~~
antod
_> I used to have a preference for Ruby but Python has a single killer feature
missing for me from Ruby and that is explicitly imported module symbols._

As someone who has to now deal with a couple of complicated/convoluted Ruby
codebases, that is one of the biggest things I miss from Python too.

~~~
sanderjd
Yeah, I've come to think this is perhaps Ruby's biggest design miss. It can be
_really_ hard to trace dependencies in Ruby, and doing so is a prerequisite
for any deep understanding of what's going on. (Granted, this is mostly a
problem in Rails projects, but the fact is that Ruby makes this problem
possible.)

------
pmontra
The Ruby story in Europe is very similar to the American one: Rails, Rails and
Rails. However the last thing I wrote in Ruby is a scraper for a web site, a
few hours after patching a Rails app I've been maintaining for a customer for
at least five years.

About more non Rails stuff, I started writing small text processing scripts in
Ruby a few years ago. I wrote them in Perl before, but I eventually got more
at ease with Ruby, notwithstanding the compact convenience of Perl's while
(<>) loop and the implicit input variable. I also made a mruby program run on
AWS Lambda just because I could. Interesting but probably not extremely useful
in that context (pun intended).

I wonder if there will be a second Ruby wave from Japan, if their community
keeps growing and their use cases start reaching abroad. Remember that the
first wave (Rails) was actually from the USA.

~~~
holydude
Hopefully! The problem with ruby is it's just fine as in good enough but not
better or more compelling than X or Y. I hope Crystal changes this or there
will be some breakthrough in the mri.

~~~
ZenoArrow
I expect a second wave is most likely to come if TruffleRuby takes off
(perhaps when it has full support for Rails).

[https://pragtob.wordpress.com/2017/01/24/benchmarking-a-
go-a...](https://pragtob.wordpress.com/2017/01/24/benchmarking-a-go-ai-in-
ruby-cruby-vs-rubinius-vs-jruby-vs-truffle-a-year-later/)

~~~
cutler
.... and Substrate VM. JRuby has also made great strides recently.

~~~
holydude
But the question is when that will be available? It might be too late.

------
asveikau
I am American, and remember the first I heard of Ruby was in '99/2000-ish. I
didn't get into it but it sounded interesting. It was presented as a
smalltalk-like language with good interop with C, or even objc for OS X apps.
Pretty similar to the niches that Python fills.

Then it seemed like one day some years later, a very faddish, I will be blunt,
charlatan type seemed to dominate that discussion. This is the type that
confuses ruby with rails, git with github, the internet with the web. They are
using ruby in the same way that the old ASP crowd would have used Visual
Basic.

I was never involved in any of this, just watching from the sidelines, but it
does seem like a bit of a shame.

------
manmal
So, embedded (IoT) and a bit of machine learning is what Japanese developers
do with Ruby? The article is a bit thin on the "what they actually do with
Ruby aside from Rails" side..

~~~
holydude
Yeah the article is not telling us much. IoT and ML that is it but who, how
and where ?

------
ktamura
Ruby definitely owes a big part of its popularity and awareness to Rails. I
think all Ruby committers admit this fact.

That said, Rails is hardly the only framework that has brought Ruby to the
communities outside of Japan. Chef/Puppet/Fluentd played a key role in
bringing Ruby to the ops world while books like "Understanding Computing" by
Tom Stuart demonstrates Ruby's potential beyond web programming.

There's a tangible tension between Rails fanatics and sans-Rails Rubyists, but
they have needed each other to get where they are today.

------
nextos
A decade ago I got introduced to Ruby by writing a static analyzer which used
abstract interpretation [1] more or less following the hardcore lattice book
[2] as taught by the Nielsons themselves.

I used Ruby because my groupmates found Lisp, ML or Haskell too difficult, and
Ruby has(had) a very nice Set datatype plus pretty good metaprogramming and
DSL abilities.

The code was on Github for some time and it was always funny to see recruiters
reaching me, looking for people with > X years Rails experience, as they
always equated Ruby to Rails.

[1]
[https://en.wikipedia.org/wiki/Abstract_interpretation](https://en.wikipedia.org/wiki/Abstract_interpretation)

[2]
[http://www.imm.dtu.dk/~hrni/PPA/ppasup2004.html](http://www.imm.dtu.dk/~hrni/PPA/ppasup2004.html)

------
uiri
I'm Canadian. Ruby was my first programming language. I don't know Rails. Now
that I know Python, a lot of my first programming projects are the kinds of
things that I would use Python for nowadays.

 _American audiences often ask, "why would you want an embedded Ruby?"_

You might as well ask "why would you want an embedded Python?"... the answer
to that is fairly obvious to anyone who knows Python and C, and who has done
embedded programming. So why is it less obvious to those same programmers why
someone would want an embedded ruby?

~~~
chillacy
Last week there was a big thread talking about how Arduino was extraneous
overhead and we should be using the AVR libraries directly. I think they would
have died upon hearing about running a garbage collector on a microcontroller.

~~~
vidarh
The lines are rapidly blurring, given that you can fit, and power, an ARM core
sufficiently powerful to run Linux (actually, you can run Linux on far smaller
systems than that) with a WIFI interface and web server _and run Perl on it_
on an SD card form-factor device... 4 years ago [1]. Of course there are
plenty of niches where you still _need_ a much lower power device, but a lot
of areas where you needed that a few years back are areas where you can put a
much bigger stack now and still do ok.

[1] [http://maisonbisson.com/post/17379/transcend-wifi-sd-card-
ha...](http://maisonbisson.com/post/17379/transcend-wifi-sd-card-hacking-
links/)

~~~
uiri
Arduino and AVR are 8-bit microcontrollers. ARM chips are 32- or 64-bit CPUs.
There are plenty of ARM SoCs out the which can run Linux off of an SD card:
raspberry pi and beagle bone black come to mind. There are plenty of use cases
where an AVR chip is underkill (e.g. anything that needs parallel processing)
and an ARM chip is overkill (e.g. digital thermometer).

~~~
vidarh
> There are plenty of ARM SoCs out the which can run Linux off of an SD card:
> raspberry pi and beagle bone black come to mind.

In case you misunderstood: The above is not about running Linux off of a
stored diskimage on an SD card. The ARM SoC in question fits _in_ an SDcard.
They're intended for e.g. putting in your camera so you can have wireless,
wifi access to the images on the SDcard.

Other than that I agree - there's certainly still room for both. But the point
is you can physically fit a Linux capable computer in an SDcard form factor,
and drawing 100mA, which means the niches where smaller micro-controllers is
the only alternative have narrowed accordingly.

------
verisimilidude
I picked up Ruby in Japan before the era of Rails, back in 2004. There was a
lot of enthusiasm around the language in Japan even at that time; it seemed
like people were using it for everything. Personally, I knew a bunch of people
who were using it for all their command-line tooling. These days, I bet most
Western Ruby devs couldn't even tell you what _gets_ does, but back then it
was like magic.

~~~
franciscop
From another comment, it seems like it was invented to specifically support
Japanese characters. It might have been the only scripting language for a
while in Japan so it makes sense that it became popular over there.

~~~
nandemo
> It might have been the only scripting language for a while in Japan

No way. Perl used to be quite popular.

~~~
franciscop
*with support for Japanese characters

~~~
nandemo
What do you mean? Perl did have support for the (several) standard Japanese
encodings.

------
Asooka
Basically this reads as "Ruby was Python with better Japanese documentation
and much better string encoding handling for Japanese use-cases". IIRC they
came out at about the same time with about the same goals (correct me please),
but I wouldn't wish to make programs that have to handle Japanese text in
Python 1.

~~~
k__
Python 1991

Ruby 1995

But I don't know if Python was good with Japanese text in 4 years after
inception.

~~~
jacquesm
Python only supports native Unicode strings from Python3.

~~~
int_19h
Unicode strings were added to Python in 2.0 (released in 2000). What changed
in Python 3 is that they became the _only_ string type, with what used to be
non-Unicode strings effectively becoming immutable byte arrays.

However, Japanese often _don 't_ want Unicode, because of Han unification, and
the associated controversy. Thus, other encodings are often preferred, and
languages that can handle them in a transparent way have the advantage. It's
largely for this reason that Ruby avoided a Unicode string type for a long
time, treating strings mostly as raw byte arrays, with a few places that
needed encoding supporting them on an ad-hoc basis.

In Ruby 1.9 (2007), they finally added encoding-aware strings; but unlike
Python 3, where the encoding is always Unicode, in Ruby the encoding can be
anything, and string is bytes + encoding. So you can do UTF-8, but you can
also do e.g. Shift_JIS (which many Japanese users prefer). The cost is that it
means that e.g. a+b is no longer always valid for two arbitrary strings, if
they are in different encodings that cannot be reconciled.

~~~
lifthrasiir
I was quite amused by the design of Oniguruma [1] which is essentially the
Ruby's regular expression library. It contains tons of associated tables for
each supported character encoding---segmentation, character types, case
folding and the likes. I found it ironical that the non-ASCII case folding
doesn't seem to work for most CJK character encodings though (in my shallow
analysis).

[1] [https://github.com/kkos/oniguruma](https://github.com/kkos/oniguruma)

------
spo81rty
This article mentioned Rails is on the decline in popularity. Anyone have any
thoughts on the truth of that?

~~~
ZenoArrow
I don't know about its popularity, but from what I've seen it doesn't seem to
be on the hype train anymore. No technology stays on the hype train forever.
Of course this is just based on observing trends, it shouldn't dampen your
enthusiasm if you've found something that works for you.

~~~
nitrogen
Rails still solves all the problems it solved last year or two years ago. I'm
always astonished when teams give into the hype train and replace the two
things Rails excels at, templating and database access, with a 10MB frontend
JS blob and microservices running in a JVM language.

Just use Rails, it scales just fine. Your hand-coded DB layer for your
microservice will never be as good as ActiveRecord if you aren't Facebook.

~~~
baddox
Why do you say that Rails excels at templating? Ignoring for the moment the
obvious differences between server-rendered HTML and JS frontends, the Rails
templating doesn't strike me as one of the most prominent solutions Rails
provides. The templating is fine, but other than a few niceties (like layout
hierarchies and resource-based forms) it's not much more than a thin syntax to
embed Ruby eval inside HTML.

If I had to pick the top things that Rails excels at, I'd point to ActiveModel
and resourceful routing. I know REST isn't the hotness any more, but it sure
is great for CRUD web sites or APIs, and Rails makes setting up database
models, associations, and REST routes a breeze.

~~~
ooqr
I'd go so far as to not only agree with your assertions of the best points of
Rails, but to also extend your skepticism of the excellence of Rails'
templating to calling that the worst part of Rails. Of course, one can use
Rails as an API only service and it's quite adept at that.

~~~
randomdata
I don't know if I would call Rails templating excellent, but it is acceptable.
The nature of HTML allows for quite a lot of flexibility. However, I have to
disagree with your view of Rails in API usage. Maintaining a client contract
for fields and value types is far more difficult in Rails, at least out of the
box, than similar offerings.

If you send the wrong HTML tag, the content just might look a little funny to
the end user. If you send the wrong datatype to an API client, it generally
won't be able to do anything with it, and may not fail gracefully at that.
Constructs to ensure you cannot make that mistake are invaluable in API
design.

~~~
nitrogen
It's a bit late for this reply, but check out [shameless plug] the ClassyHash
gem.

------
webbrahmin
Even in Japan PHP and Java are more popular than Ruby. As per a Japanese
headhunter friend of mine who works for a big placement agency there there are
about 3 times more PHP jobs & 6 time more Java jobs than Ruby jobs in Japan.

~~~
ninjabeans
Yeah but no one writes their personal projects in those.

------
holydude
I am wondering why Rubymotion is not more popular in Japan. Is it because it
is relatively very expensive or is not enough ruby ro gain momentum?

~~~
emptybits
It's a good question because I understand Japan to be the region in the world
where iOS dominates smartphones the most (over 50%?). I know RubyMotion has
Android support and it continues to get better but I think it's fair to say
RubyMotion is strongest for iOS/macOS work.

The company is under new ownership/management since very recently ... perhaps
Amir or someone will look at regional situations and gain more mindshare for
the platform.

