How is Ruby different in Japan?

https://appfolio-engineering.squarespace.com/appfolio-engineering/2017/5/24/how-is-ruby-different-in-japan

by galfarragem • 9 years ago

302 166 9 years ago

appfolio-engineering.squarespace.com

manmal• 9 years ago

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..

holydude4• 9 years ago

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

holydude4• 9 years ago

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?

sotojuan• 9 years ago

What's the Japanese use of (Japanese-developed) apps vs mobile sites?

hrktb• 9 years ago

There was already a long history of app development when the smartphones came around, especially in Java, and iOS (or really any Apple product) japanese support was excelent from the start.

IMO on the mobile side, there was already a strong native culture that made it a harder sell to go the cross platform route.

emptybits• 9 years ago

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.

phamilton2• 9 years ago

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.

di4na3• 9 years ago

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

chao-• 9 years ago

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

pault• 9 years ago

Doesn't this create extreme state synchronization and scaling issues?

phamilton2• 9 years ago

In an embedded system? No.

Even in distributed systems, coordination of data from stateless systems can be a nightmare. Requiring a bit of stickiness simplifies a lot of things.

For example, I've worked on a few large scale adserving auction platforms. One of them had the auction and impression events recorded statelessly (ie each event was generated on a random machine). This required a big hadoop job to match up all the events from a single auction. Another system used sticky events, where all events for an auction would hit the original server that ran the auction. It would store all events for an auction in memory and then flush it to the billing system when the data was finalized. Was it perfect? If the one machine crashed, all pending ad info wad lost. But that didn't happen often so the cost was negligible.

spo81rty• 9 years ago

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

ZenoArrow3• 9 years ago

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.

nitrogen3• 9 years ago

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.

wolco• 9 years ago

https://www.tiobe.com/tiobe-index/

It declining here. Whatever value you place on that.

breckenedge• 9 years ago

Yes it has declined from the Dec. 2008 high but has rebounded from the Feb. 2015 low [https://www.tiobe.com/tiobe-index/ruby/].

Edit:

Oddly that page describes May 2016 as it's high (#8), but that's not reflected on the charts.

galfarragem• 9 years ago

According StackOverflow it's true:

https://insights.stackoverflow.com/trends?tags=ruby-on-rails...

And for Ruby also:

https://insights.stackoverflow.com/trends?tags=ruby%2Cpython

jacquesm2• 9 years ago

Node is going after that space so you can see an increase in server side javascript stuff coupled with a decrease of Ruby and probably some PHP and Java as well. Ruby is the most vulnerable of those.

friedman23• 9 years ago

With Python people are doing data analysis and machine learning in addition to web development, with JS you can do frontend web development and if you use JS for the backend you can even do server side rendering for React/Angular. With Ruby you just have Ruby on Rails.

vidarh5• 9 years ago

With Ruby you just have Ruby on Rails.

As a Ruby developer who has used Ruby since 2005 without using Rails, that's news to me.

pmontra4• 9 years ago

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.

holydude4• 9 years ago

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.

ZenoArrow3• 9 years ago

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...

ksec3• 9 years ago

There is a new VM with Method JIT coming to MRI.

https://news.ycombinator.com/item?id=14576077

abrowne• 9 years ago

SUSE re-wrote their setup/config tool YaST¹ in ruby a few years ago.

1: https://en.wikipedia.org/wiki/YaST

SOLAR_FIELDS2• 9 years ago

I'm a non-typical consumer who simply has used Ruby as a Python drop-in for text manipulation and interacting with API's.

Overall I found the philosophy to Ruby to be a bit more elegant than Python's, but I struggled with some of Ruby's philosophies about what an object is and how to store them.

In general I enjoy Ruby as a general purpose language, but code I wrote to interact with REST APIs was eventually replaced with Python at my work because "not enough people know Ruby".

What is Ruby's killer feature to help drive adoption in situations such as these? By "these" I mean as a general-purpose scripting language.

pmontra4• 9 years ago

There is no clear cut killer feature for Ruby over Python in that context, and viceversa. Both are fairly good compared to the alternatives. The only true killer feature of Ruby is Rails, much better than Django and Web2py I had to work with in the last year, but that's out of the scope of your question. If your team knows Python you're likely to stay there.

I find Ruby to be much easier to read and understand than Python but I have 10 years of customers paying me to write Ruby vs one in Python. I assure you that it would be the other way around if I had worked in Python for 10 years.

I never picked Python for my own projects in all those years because I find many of its design choices weird and painful (I joke saying it's Ruby for the masochist), but that is very subjective. People liking Python consider good even what I find to be objective weaknesses of Python (example: only one line lambdas.) This means that probably both languages are good enough.

vidarh5• 9 years ago

You may be aware of this, but for those who aren't: Ruby has much of this. Perl is perhaps Ruby's other "parent" besides Smalltalk, for good or bad, and there are a lot of stuff stolen from Perl that sees relatively little use in Ruby today.

The "-n" switch adds an implicit "while gets; ....; end" loop, leaving the input line in $_. "-a" will do "$F = $_.split", which means it splits on the contents of "$;" which can be set with "-F" like with awk.

E.g.:

    ruby -naF[someseparator] -e '[some ruby expression]'

Is equivalent to wrapping [some ruby expression] in:

    $; = [someseparator]
    while gets
        $F = $_.split($;)
    end

Which incidentally also gives a halfway decent awk impersonation given that Ruby also supports awk-like BEGIN {} and END{}.

rjeli• 9 years ago

More on this:

https://robm.me.uk/ruby/2013/11/20/ruby-enp.html

https://robm.me.uk/ruby/2013/12/03/argf-ruby.html

https://robm.me.uk/ruby/2015/10/31/dollar-underscore.html

and his book:

https://pragprog.com/book/rmtpruby/text-processing-with-ruby

nextos• 9 years ago

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

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

btilly• 9 years ago

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• 9 years ago

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• 9 years ago

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

fenomas• 9 years ago

no scripting language which could handle Japanese text.

Matz doesn't say this anywhere I can find. He usually says he wanted a more object-oriented scripting language and wasn't satisfied with Perl or Python.

paulddraper2• 9 years ago

If that's true, it's surprising then that Ruby handles encodings so badly.

String encoding cause some pretty obtuse errors in non-obvious spots.

    irb(main):001:0> str = "\xAA"
    => "\xAA"
    irb(main):002:0> str.split('')
    ArgumentError: invalid byte sequence in UTF-8
        from (irb):2:in `split'
        from (irb):2
        from /usr/bin/irb:12:in `<main>'

WTF?

bhaak3• 9 years ago

First, you're looking at a feature of modern Ruby that got added in 1.9. Before that, Ruby only supported a single encoding. If you're interesting in the details, look up how the $KCODE global variable used to affect in Ruby <= 1.8.

Second, what do you expect if you have an invalid byte sequence in your UTF-8 string? str.valid_encoding? would have told you that the string contains invalid characters. String#encode gives you fine grained control over how to handle invalid characters in your strings.

Ruby lets you set the encoding by string.

  > str = "\xa4"
  > puts str
  �
  > puts str.force_encoding("iso-8859-1").encode("utf-8")
  ¤
  > puts str.force_encoding("iso-8859-16").encode("utf-8")
  €

verisimilidude• 9 years ago

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.

franciscop2• 9 years ago

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.

nandemo2• 9 years ago

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

No way. Perl used to be quite popular.

ninjabeans2• 9 years ago

I have been using it for all my scripting needs almost since it first came out.

qiqitori• 9 years ago

I currently live in Matsue. When I tell people I am a programmer, even decidedly non-computer people will ask "Ruby?" They have Ruby-branded instant ramen in souvenir shops (with the proceeds going to the/some Ruby association). And they have that billboard as seen in the article.

Asooka• 9 years ago

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__• 9 years ago

Python 1991

Ruby 1995

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

jacquesm2• 9 years ago

Python only supports native Unicode strings from Python3.

Lordarminius5• 9 years ago

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 ?

yzmtf20082• 9 years ago

I consider Ruby a far superior language

Have you looked at the C source of Ruby? :) In terms of that, Python is far, far superior to ruby.

EDIT: to clarify, CPython is much cleaner than MRI, and has a much-better-documented API for extensions. This is what I believe part of the reason that Python has a much better coverage for scientific packages.

rurban2• 9 years ago

Disagree. I deal with the C parts of Perl, Ruby and Python and better VM's on a daily basis. Ruby has by far the cleanest implementation of the VM. Almost like the VM of a good Lisp/functional lang. Python and Perl are the worst of all, on par with PHP.

Ruby is unfortunately also the slowest. But not because of the VM implementation, only because of the everything is a method architecture, even for the simplest primitives. The ruby API is pure and clean, this is what makes it slow.

For the python or perl API too much inner state needs to be handled, which makes it slow also. Because you cannot use a better design for data and code. Only php made significant advantages there recently, so you don't have to worry about inefficient data and code, only about the eye blead VM.

ksec3• 9 years ago

I remember Charles Nutter ( Head Dev of Jruby ) Tweeted a while ago saying how clean the CRuby Code base was.

jeltz3• 9 years ago

Having worked with both I found the MRI codebase very clean and nicer to work with than CPython.

flavio81• 9 years ago

Python is slightly less powerful but is pretty fine for many tasks, and much easier to learn than Ruby, with a consistent syntax. So you can quickly learn it and then spend the rest of the day focusing on getting things done.

Lordarminius5• 9 years ago

It should be possible to delineate a "core" syntax for Ruby as well and leave the language esoterica to more adventurous practitioners.

Why is this not a thing ?

See my previous comment

sametmax2• 9 years ago

How is Python less powerful ? They both have metaclasses, monkey patching, first class functions, unicode... Ruby has blocks, Python has decorators. You can solve pretty much the same problems with the same number of lines.

int_19h5• 9 years ago

Python is arguably more "obviously readable", in a sense that when you see some construct, and you don't know what it is, but you have a guess, that guess is usually correct. It makes the grammar more verbose than Ruby in many ways, and idiomatic Python is almost always more verbose than idiomatic Ruby, but for many people, ease of reading and understanding is preferable.

ouid2• 9 years ago

I dunno man, I don't think the languages are properly comparable for readability.

  5.times do

    print "s"  

  end

vickychijwani2• 9 years ago

Care to elaborate with an example? I use Python day-to-day and did quite a bit of Ruby a few years ago, but I fail to see significant differences in verbosity.

What I do see is that Python is somewhat less consistent and readable (list comprehensions beyond the simplest ones are unreadable, Ruby's blocks allow cleaner DSLs, len(a) vs a.size, little things like "3.times", allowing "?" and "!" in identifiers). But Python has a bigger and more diverse ecosystem. So although I would prefer Ruby over Python, the ecosystem aspect makes the point moot.

brazzledazzle• 9 years ago

It's one small thing but string interpolation annoys the crap out of me when using Python and while it might tick the understandable check box I wouldn't say it's easier to read. After using Ruby it's such a chore to read or write in my opinion (which admittedly doesn't mean much having so little experience with Python).

cutler3• 9 years ago

According to Indeed.com (title search) there are 4 PHP jobs to every Ruby job in Japan and 15 Java jobs to every 2 Ruby jobs.

hetman3• 9 years ago

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• 9 years ago

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.

Daishiman• 9 years ago

This is the number 1 failure in Ruby for me. It makes large codebases unmaintainable in the long term.

jeltz3• 9 years ago

Yes, Ruby is my favorite language but they really messed up the module system. Ruby basically has no module system at all and everything is in the global namespace.

nine_k• 9 years ago

Ruby embraces and favors magic. Python shuns magic and goes for one correct and explicit way.

The languages are pretty similar. The community attitudes are different.

setpatchaddress2• 9 years ago

The languages are not very similar. What gives you that idea?

rurban2• 9 years ago

Cannot agree. Ruby loves its MOP, python loves its method overloads. Both are highly magic, but a MOP is technically superior to overloads, because you just flip the vtables and don't have to look at every single method call, if some python programmer decided to overload it. Perl has no builtin MOP, and even worse overloads than python.

uiri2• 9 years ago

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• 9 years ago

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.

vidarh5• 9 years ago

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...

doktrin• 9 years ago

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.

owebmaster2• 9 years ago

Back in 2008 Rails was the real fun. And their proposed way of doing web software was mainstream until angularjs exploded.

bauerd3• 9 years ago

Angular is a frontend framework, Rails is a backend framework. Care to elaborate?

copperx• 9 years ago

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

I'm looking for Rails alternatives.

prh82• 9 years ago

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.

cyberferret2• 9 years ago

For some reason, I could never get the hang of Rails. But when I found Sinatra, it all made perfect sense to me.

Now I exclusively use Padrino [0] as the framework to build all my web apps. It is a framework on top of Sinatra that gives you a lot of the Rails goodness, but allows you to be really agnostic in terms of ORMs, Testing/Mock frameworks, rendering platform etc.

[0] http://padrinorb.com

nextlevelwizard3• 9 years ago

I've done RoR stuff and something about "doing-things-the-rails-way" bugs me to no end. After being paid to work on a RoR app I started to hate Ruby. Some time after I wrote something small and silly for my thesis (to visualize some data and give my classmates something to play with) in Sinatra and it rekindled my love for the language.

Something I can't really put my finger on just rubs me in the wrong way in Rails, but using Sinatra felt like shattering chains that were holding me back. Maybe it was partly that I was learning NodeJS at the time, I dunno, but I can't recommend Sinatra enough. This being said I have zero experience with Sinatra in an production environment, so take this anecdote with a shovel(s) of salt.

wx196• 9 years ago

Roda, https://github.com/jeremyevans/roda

vidarh5• 9 years ago

Similar here. I've used Ruby since 2005, but mostly for backend code, with a sprinkling of Sinatra for my web projects. Sinatra is spartan compared to Rails, sure, but it also means you get to bring just the components you need, and Sinatra is tiny enough to just read the code if you don't understand exactly what's going on. In fact, before Sinatra, I had a couple of projects where I used Camping - _why's micro-framework for the same reason: It brought just the bare minimum, and you could hold all of what it did in your head with ease.

I don't quite have the same hate for Rails, I think. If a client asks for it, I'd consider it. But I also usually tell them I'd rather refer them elsewhere.

asveikau• 9 years ago

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.

ktamura• 9 years ago

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.

webbrahmin• 9 years ago

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.

ninjabeans2• 9 years ago

Yeah but no one writes their personal projects in those.

How is Ruby different in Japan?

Related Stories