>Why not use Ruby, or Python, or JavaScript -- or even Go, Rust, Clojure, or Scala? (Yes, I realize that the latter two run on the JVM, which would have been problematic in other ways.) Heck, they could have bought RubyMotion and made Ruby the high-level language of choice for development.
Because OBVIOUSLY none of them solve the problems they wanted to solve (interoperabillity with Objective-C, fast, native, IDE integration, etc. Including RubyMotion which is a half-arsed implementation.
> Rubyists in general want to use Ruby for everything.
Well… why not?
This is a relatively objective statement; the problem with ruby tends to be the crappy interpreter we're forced to suffer through - not the language itself. The Ruby language, in my biased opinion, as far as OO-functional languages go is pure awesome.
My initial reaction was: "A Ruby to Obj-C ABI compiler? Fuck no, what is wrong with you."
Upon learning it was the MacRuby dude: "Holy shit fuck yes".
I really don't want to ditch my entire development workflow to pick up Xcode, and Objective C, and miss out on all of the development libraries and vibrant community that I already have access to.
The problem with company led development environments is that they're tailored to the vendor's, and not the community's, needs. Development is rigid and low on innovation.
If this framework is half as good as it seems to be, within a month we'll see a dozen libraries that abstract all sorts of pain away from iOS development. Abstracting the pain away is something the Ruby community tends to do well.
I've gone from being totally uninterested in iOS development to being excited in what I can do inside UIWebviews. Naive, maybe, but it's probably significantly lowered the amount of investment I have to make into creating an iOS app.
Really? At my company it seems like 90% of the tests are catching things that would be caught automatically if we had used a proper language with strong types/compiler.
IMO Ruby is slow, not particularly beautiful (yes, this is subjective), and seems optimized for shoving crappy REST endpoints out the door as quickly as possible.
> Are they optimizing for cost or speed of development?
Historically I would agree. There are options now that are both easy to develop in and are blazingly fast (C#, Go, Rust, Kotlin to name a few).
The elephant in the room is that both Ruby and Python fell behind in relative ease of use and computational performance with respect to other ecosystems and instead of addressing pressing matters there is a lot of mental gymnastics and cognitive dissonance at play such as presenting false dichotomies.
> First off, popularity of a language shouldn't be as important as you seem to make it in starting a project.
I think there is a minimum threshold to this. I support a large application written in an extremely obscure language (it's basically me and 5 other people on an old yahoo mailing list that make up the entire community). It is terrible. No unit testing frameworks, no http framework for rest calls, no decent UI templating, and on and on. 100% of functionality that I need comes in the form of calls to command line tools.
Obviously, Ruby is way past that threshold, so I do not disagree with what you said at all, but just wanted to point out there is a limit. I would not write a new commercial application in any language today that did not already have strong package system. As one person, you can write a few essential modules that you need, but you cannot write all of them.
> Some people will point to language design characteristics, which are part of the story, but I think the deeper reason is that ruby does not have a serious corporate sponsor.
Spot on. Biggest reason why I don't think Ruby/Python will grow bigger than what they are today is this. Meanwhile NodeJS/JavaScript is adopted by _many_ companies: IBM, SAP, Google, Joyent, Microsoft, etc. Ruby had some momentum before but none of the big guys extend their support as far as NodeJS/JavaScript.
Having said that, I'd probably use Java for a new company , why not?
Some people say "bulb" I'd say "matured"
Some people say "verbose" I'd say "explicit than implicit" (or code is written once to be read multiple times)
Some people say "bloated framework" I'd say "stable and backward compatible without sacrificing speed and flexibility" or "does not have to reinvent my memory mental model" (compare to different JS API programming style).
Some think Maven "sucks/bloated" but I'd think nothing can touch it for the most part...(plus Maven's idea is copied everywhere else..)
To each of his/her own I suppose.
PS: I use JavaScript 100% to build 2 enterprise products as my day job
> if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast
Context is pretty important to the original comment:
> python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.
they're not looking for a fast language in isolation, they're looking for a fast language in the broader context of their existing technological stacks. Java doesn't help that much when you're looking into ways to speed up your Ruby application, at least not easily.
Furthermore, Java has the issues that it's only fast when memory is plentiful and it has a long startup/running time, it's "eventually fast" if you will.
I question that. Ruby is very slow, dynamically typed and suffers from scaling challenges because of its multithreading support.
I think Ruby is increasingly falling into a niche: prototyping. Get a prototype up and running in a few weeks and once the proof of concept is established, switch to a statically typed language on the JVM.
> folks coming from Python and Ruby, looking for something that has better perf and concurrency
Long-time Ruby developer here, relunctant Go developer. Absolutely.
I want performance, concurrency, efficient memory usage, and static typing. Ruby is lacking in all these areas. Go is mildly better, but is regressive in many other respects.
For me, Go is a step back in terms of productivity, but a step forward in creating stable, fault-tolerant code. It's a compromise. Go feels like a stopgap solution until something better comes along.
For example, I've learned to design the internals of my code around a functional style that makes code composable and the data flow simple. Go doesn't support that style, not really. Go promotes simplicity, but a lot of stuff that should be simple in Go isn't "simple". Like mapping and reducing an array.
What's interesting is that working in Go reminds me a lot of using Borland's ObjectPascal back in the mid-1990s: A small, natively compiled (and super fast to compile), not-functional language with built-in reflection and a stupidly strict, cumbersome type system. Go makes very few innovations over ObjectPascal, and inherits many of its problems; Go's notorious lack of generics, for example, caused exactly the same issues back then. And nobody should be surprised about that.
Currently, the language that looks closest to my ideal is Nimrod. Unfortuantely, it has almost zero mind share, and has a surprising amount of odd, off-putting warts for such a young language (perhaps not too surprising when you realize that for many years it was just one guy hacking away at it, TempleOS-style), disappointing since many design choices just feel just right, like someone has read my mind. Currently I'm on the fence with Nimrod. Jonathan Blow's jai also looks promising.
As well as by not-Ruby programmers, which is why they keep getting used in non-Ruby languages that don't keep other aspects of Ruby.
> Why is it that Ruby programmers are incapable of imagining anyone doesn't love Ruby?
I think most Ruby programmers are capable of understanding that lots of people don't like Ruby, and more importantly that lots of people don't like aspects of Ruby that those Ruby programmers find most attractive.
Sure, some Ruby programmers have problems with this, but, OTOH, some non-Ruby programmers seem incapable of understanding that other non-Ruby programmers might find some aspects of Ruby attractive that they, themselves, do not.
> I've met plenty Java programmers willing to admit the shortcomings of Java
Well, sure, the more likely you are to be compelled to use a language because of corporate inertia, the more likely people that actually do use it will be the people that don't like it and use it under duress. So I'd expect Java to be among the languages with the highest proportion of active programmers who not only are willing to admit its shortcoming, but who outright despise it.
> I've yet to meet a Ruby programmer who doesn't believe that Ruby is the best thing since sliced Jesus.
Given the number of non-Ruby programming languages created with substantial input from (or even under the leadership of) people in the Ruby community specifically because, while they like many things about Ruby, they find it not optimal for some uses, I think this says a lot more about your limited exposure to the Ruby community than about the Ruby community itself.
Yeah, but there are people who'd rather use Haskell, Clean, Agda or Idris. Kotlin, Swift, Rust and other such things seem like a reasonable middle ground from this perspective.
> I wanted to know which direction Elixir is going to take? Will Elixir be mostly compatible enough with Ruby so that Rails can run directly off on Elixir?
Elixir is not even approximately compatible with Ruby, nor is it intended to be. It just has syntax that is very loosely reminiscent of Ruby. Someone might one day write a Rails-like framework for Elixir, but it will never be the same Rails that runs on Ruby.
OTOH, if you want something no GIL that can run Rails, there is always JRuby.
> I want one language that works on both sides and in fact allows OOP code sharing between the two.
I think, having one language in both frontend and backend does not work in long run, regardless of your preferred language of choice.
we love ruby and yet where I work - we actively maintain Ruby, Python, Javascript and Java applications. Besides, I find it too hard to write OOP code which is reusable within same problem domain, writing OOP code that crosses the concerns between backend and frontend sounds like inviting lot of problems and lot of useless discussion on - which code goes where.
EDIT: I didn't mean business agnostic code can't be shared between frontend and backend btw. Date parsing, uri parsing etc are examples of such libraries. But overall aiming to write business code that can be shared between frontend and backend is problematic.
>What business we choose to build with the language will outweighs the impact of language choice a hundredfold.
This isn't always the case. If I tried to build a HFT company using Ruby for literally everything, it's almost guaranteed to be a completely failure, not only because it's extremely difficult to write allocation free low level code in pure Ruby, but also because anyone I tried to hire with relevant experience to build the platform would be like "WTF, why are you building a HFT platform entirely in Ruby, that's such a stupid idea, no way I'm working on that".
Or for that matter if I decided to start a company to build a web browser in pure Ruby.
Because OBVIOUSLY none of them solve the problems they wanted to solve (interoperabillity with Objective-C, fast, native, IDE integration, etc. Including RubyMotion which is a half-arsed implementation.
reply