Wuby?
It looks like the Installer issue has been taken up by some new folks,
cool. Still, it begs the question, is almost everyone doing Ruby doing so
on a non-Windows platform like Linux, Mac, or other *nix?
Leam
*shrug* There's still developers working on Windows on
ruby-core, but they're a minority. The problem with proprietary
platforms is that ordinary programmers are not allowed to fix
problems with the platform itself. We can't even read the
internals to see goes on at the OS level, at least not without
dealing with NDAs and legal BS.
With Linux; anyone who can send plain-text email can contribute
to the kernel, CCAN, and GNU dependencies (glibc, gcc, gmp,
bison, ...) No NDAs, terms-of-service, or anything to sign(*).
So developers who work on one of these can more easily
contribute to other parts when problems present themselves
across software project boundaries. And we (ruby-core) can even
study the intricacies of these platforms to make Ruby work
best on them.
(*) unfortunately, many GNU projects, including glibc does still
require copyright assignment :<)
···
leam hall <leamhall@gmail.com> wrote:
It looks like the Installer issue has been taken up by some new folks,
cool. Still, it begs the question, is almost everyone doing Ruby doing so
on a non-Windows platform like Linux, Mac, or other *nix?
It does make you wonder how the Python folks manage it.
···
-----Original Message-----
From: ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] On Behalf Of Eric Wong
Sent: 24 May 2017 23:01
To: ruby-talk@ruby-lang.org
Subject: Re: Windows and Ruby?
leam hall <leamhall@gmail.com> wrote:
It looks like the Installer issue has been taken up by some new folks,
cool. Still, it begs the question, is almost everyone doing Ruby doing
so on a non-Windows platform like Linux, Mac, or other *nix?
*shrug* There's still developers working on Windows on ruby-core, but they're a minority. The problem with proprietary platforms is that ordinary programmers are not allowed to fix problems with the platform itself. We can't even read the internals to see goes on at the OS level, at least not without dealing with NDAs and legal BS.
With Linux; anyone who can send plain-text email can contribute to the kernel, CCAN, and GNU dependencies (glibc, gcc, gmp, bison, ...) No NDAs, terms-of-service, or anything to sign(*).
So developers who work on one of these can more easily contribute to other parts when problems present themselves across software project boundaries. And we (ruby-core) can even study the intricacies of these platforms to make Ruby work best on them.
(*) unfortunately, many GNU projects, including glibc does still
require copyright assignment :<)
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>
Well, not sure my opinion is the favored one, but I can point out as a newbie that the "Hey, use Ruby" flag waivers often. After about half a dozen times of being told to upgrade Ruby on a large enterprise so that I was on the latest and greatest I wrote a blog post about why that was not practical. Whenever someone said "You should upgrade, we don't support that version any more" I'd point them to the blog post.
The Ruby Core Team (RCT) is probably doing the best they can to keep things fun and working for the rest of us. I appreciate their effort, Ruby has brought me a lot of happiness.
However, at least in the US, the majority of enterprise class Linux servers do not come with a supported Ruby version. Red Hat Enterprise Linux 6 (RHEL) included Ruby 1.8.7. RHEL 7, the latest, includes Ruby 2.0. Most larger companies are probably still on RHEL 6 though. Which means that server tools like serverspec can't be used since they require Ruby 2.x.
My guess is that the RCT has a lot of work to do and the Ruby attraction of "fun" doesn't always bring in people who can set aside fun for "get the job done". Python has a much larger user and tool base and it continues to grow into areas like data science, etc. As a server guy I've been honest with my team lead and pointed out that Python would be better for server support teams than Ruby, even though I prefer Ruby. For compatibility, supportability, and hire-ability the choice is Python.
I spend a lot of time agonizing over this. My goal is to be a better programmer and Ruby is fun. Yet I can't use Ruby at work as I don't have enough tools and skill to make it useful. Stuff I write at home has a user base of one since most of my target market doesn't have Ruby installed and the learning curve to do so outweighs the usefulness of the code. So whatever "programmer learning" I do in Ruby will have to be translated to some other language if I want to quite resetting passwords and get paid to code.
I've been sort of hoping that the concepts like TDD, git, and basic OOP translate well. Since I don't know the real market my plans are mostly hopes.
Leam
···
On 05/25/17 03:20, Andy Jones wrote:
It does make you wonder how the Python folks manage it.
-----Original Message-----
From: ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] On Behalf Of Eric Wong
Sent: 24 May 2017 23:01
To: ruby-talk@ruby-lang.org
Subject: Re: Windows and Ruby?leam hall <leamhall@gmail.com> wrote:
It looks like the Installer issue has been taken up by some new folks,
cool. Still, it begs the question, is almost everyone doing Ruby doing
so on a non-Windows platform like Linux, Mac, or other *nix?*shrug* There's still developers working on Windows on ruby-core, but they're a minority. The problem with proprietary platforms is that ordinary programmers are not allowed to fix problems with the platform itself. We can't even read the internals to see goes on at the OS level, at least not without dealing with NDAs and legal BS.
With Linux; anyone who can send plain-text email can contribute to the kernel, CCAN, and GNU dependencies (glibc, gcc, gmp, bison, ...) No NDAs, terms-of-service, or anything to sign(*).
So developers who work on one of these can more easily contribute to other parts when problems present themselves across software project boundaries. And we (ruby-core) can even study the intricacies of these platforms to make Ruby work best on them.
(*) unfortunately, many GNU projects, including glibc does still
require copyright assignment :<)
This.
At work we are mostly on Centos 6 -- which ships with Ruby 2.0.0. Which is end-of-life.
Thankfully, compiling Ruby from source is pretty easy. But the infrastructure people here don't really want to build that into Chef scripts, and I can hardly blame them. So I have to target my code for a dead Ruby version, which is getting harder and harder ... although, hardly Ruby's fault.
When we chose Sinatra over Rails, it was partly for this reason too. It's a rolling target, and unless you are working with it 24/7, it rolls pretty fast and breaks your code when it does. (But also, Sinatra is faster, and smaller, and...)
···
-----Original Message-----
From: ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] On Behalf Of Leam Hall
Sent: 25 May 2017 10:21
To: Ruby users
Subject: Ruby Growth (was: Windows and Ruby?)
Well, not sure my opinion is the favored one, but I can point out as a newbie that the "Hey, use Ruby" flag waivers often. After about half a dozen times of being told to upgrade Ruby on a large enterprise so that I was on the latest and greatest I wrote a blog post about why that was not practical. Whenever someone said "You should upgrade, we don't support that version any more" I'd point them to the blog post.
The Ruby Core Team (RCT) is probably doing the best they can to keep things fun and working for the rest of us. I appreciate their effort, Ruby has brought me a lot of happiness.
However, at least in the US, the majority of enterprise class Linux servers do not come with a supported Ruby version. Red Hat Enterprise Linux 6 (RHEL) included Ruby 1.8.7. RHEL 7, the latest, includes Ruby 2.0. Most larger companies are probably still on RHEL 6 though. Which means that server tools like serverspec can't be used since they require Ruby 2.x.
My guess is that the RCT has a lot of work to do and the Ruby attraction of "fun" doesn't always bring in people who can set aside fun for "get the job done". Python has a much larger user and tool base and it continues to grow into areas like data science, etc. As a server guy I've been honest with my team lead and pointed out that Python would be better for server support teams than Ruby, even though I prefer Ruby.
For compatibility, supportability, and hire-ability the choice is Python.
I spend a lot of time agonizing over this. My goal is to be a better programmer and Ruby is fun. Yet I can't use Ruby at work as I don't have enough tools and skill to make it useful. Stuff I write at home has a user base of one since most of my target market doesn't have Ruby installed and the learning curve to do so outweighs the usefulness of the code. So whatever "programmer learning" I do in Ruby will have to be translated to some other language if I want to quite resetting passwords and get paid to code.
I've been sort of hoping that the concepts like TDD, git, and basic OOP translate well. Since I don't know the real market my plans are mostly hopes.
Leam
On 05/25/17 03:20, Andy Jones wrote:
It does make you wonder how the Python folks manage it.
-----Original Message-----
From: ruby-talk [mailto:ruby-talk-bounces@ruby-lang.org] On Behalf Of
Eric Wong
Sent: 24 May 2017 23:01
To: ruby-talk@ruby-lang.org
Subject: Re: Windows and Ruby?leam hall <leamhall@gmail.com> wrote:
It looks like the Installer issue has been taken up by some new
folks, cool. Still, it begs the question, is almost everyone doing
Ruby doing so on a non-Windows platform like Linux, Mac, or other *nix?*shrug* There's still developers working on Windows on ruby-core, but they're a minority. The problem with proprietary platforms is that ordinary programmers are not allowed to fix problems with the platform itself. We can't even read the internals to see goes on at the OS level, at least not without dealing with NDAs and legal BS.
With Linux; anyone who can send plain-text email can contribute to the kernel, CCAN, and GNU dependencies (glibc, gcc, gmp, bison, ...) No NDAs, terms-of-service, or anything to sign(*).
So developers who work on one of these can more easily contribute to other parts when problems present themselves across software project boundaries. And we (ruby-core) can even study the intricacies of these platforms to make Ruby work best on them.
(*) unfortunately, many GNU projects, including glibc does still
require copyright assignment :<)
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Click here to view Company Information and Confidentiality Notice.<http://www.jameshall.co.uk/index.php/small-print/email-disclaimer>