Happy Birthday, Ruby • Hacker News Board

Re: Happy Birthday, Ruby

#151

Post by 0xADEADBEE » Thu, Jan 10, 2019, 8:03 PM UTC

cure wrote: post #105

tomc1985 wrote: post #97

Earlier quoted context omitted.

Django has a lot going for it in terms of simplicity but it lacks most of Rails' advanced features and timesavers. In my experience it sits somewhere between Sinatra and Rails

Also, having to deal with Python packaging is a world of hurt. No thanks. There's about 16 ways to package and distribute Python, and they all are half-complete and a royal pain to deal with. Ruby's packaging isn't perfect, but it's a thousand times better than any of the Python packaging solutions out there.

Package management is a hard problem, but we know that good and adequate package managers do exist. I'm not sure why more effort hasn't been expended by the Python community, particularly since it's often the first thing a new user will encounter when picking up a language for the first time.

I use Pipenv currently, but only because it's the best of a bad lot and would jump in a heartbeat if a serious competitor came along. It has its own set of problems (slow, young and idiosyncratic) but offers me at least two things its predecessor didn't: separation of production/dev dependencies and seamless integration with different versions of Python, both of which have been available in Ruby since I started programming in it.

This is a perfect exemplifies my experience with both languages: I have found while Python might be better at a lot of things, the user experience is invariably superior with Ruby efforts and I wish the Python community would put more effort into this area.

Re: Happy Birthday, Ruby

#152

Post by cutler » Thu, Jan 10, 2019, 8:04 PM UTC

pavlov wrote: post #80

skywhopper wrote: post #48

Earlier quoted context omitted.

I don't understand your bit about "cuteness over familiarity". Can you give an example outside that's not Rails-related (given that Rails seems to be the main source of your concrete complaints)? Sigils in Ruby actually do have strong and clear meanings. And the difference between symbols and strings is a useful distinction. And contrary to your statement, Ruby's stdlib is far more complete and more internally consis…

Yes, maybe my problem is more with Rails. (Because of monkeypatched APIs, it’s not always obvious to me whether a particular weirdness originates from Ruby’s standard library or is a Rails addition. Arguably this is something the language has also encouraged though.) Is there any reason to use Ruby outside Rails? Its niche seems to completely overlap with Python and modern JavaScript, and those have enormously more e…

Utter nonsense. Whilst Ruby/Rails may no longer be cutting edge Indeed.com/USA currently has 302 Rails jobs by title search compared with 567 for Node, 204 for Django and 142 for Laravel. That's a long way from the “COBOL of Web 2.0” by any stretch of the imagination. Rails also maintained a high score in the review of last year's Who Is Hiring:

https://letstalkalgorithms.com/analysis-of-2018-hacker-news-...

As for Ruby outside Rails, have a look at Metasploit, Puppet, Chef, ROM, Rhoda and dry-rb to name just a few.

Re: Happy Birthday, Ruby

#153

Post by TheRealDunkirk » Thu, Jan 10, 2019, 8:06 PM UTC

colechristensen wrote: post #145

TheRealDunkirk wrote: post #67

Earlier quoted context omitted.

So, I'm old, and have done lots of stuff in lots of languages in frameworks. For about a dozen years, Rails was my go-to toolkit. I've written a couple dozen production applications with it. Unfortunately, Rails has really fallen out of favor lately. Even a Rails-specialty shop I worked for briefly has pivoted to using ASP.NET. I've played around in that stack, and found it lacking. (EF just doesn't compete as an ORM…

Opposite ask: What would your state of the art be for starting something new with Rails? / suggestions to become quickly productive

Good question! When I worked at the Rails shop, we had a standard Gemfile which we started with. It had way too many things in it. Some of the absolute requirements would be to start with 'better_errors', 'letter_opener', 'haml-rails', 'simple_form', 'devise', 'cancancan', and (probably controversial, but my favorite) 'cocoon' (i.e., the thing that makes nested models take so little code). You can probably throw in twitter-bootstrap too, but...

Also, I'm still using RVM. I never made "the switch" to rbenv; I never saw the problem with RVM.

MySQL vs PostgreSQL doesn't matter to me. I've done a lot of both. And Oracle. And SQL Server. I've never seen a problem with using any database with ActiveRecord.

Starting a new project, I just install the latest, stable Ruby, install the bundler gem, then grab the latest, stable Rails, add the basic gems, bundle, and start letting rails generate the basics.

I'm bootstrapping my projects with Vue support, because I think that's the JS framework that fits most-nicely in Rails, and there's always a presentation-heavy page that needs that kind of treatment.

(I'm assuming a Mac or Linux here. I've done this on Windows for a time, but WSL has changed the game there, and I've not actually tried to use it in anger.)

Re: Happy Birthday, Ruby

#154

Post by chc » Thu, Jan 10, 2019, 8:08 PM UTC

cutler wrote: post #146

chc wrote: post #137

Earlier quoted context omitted.

As somebody who was a Rubyist for about a decade but has worked at a Django shop for several years now, I definitely see how they're similar, but I don't think Django is clearly the better of the two. Django is simultaneously less helpful (you have to do more things explicitly, such as specifying routes) and less flexible (for one example, Django doesn't have a public query builder and doesn't have a replaceable ORM…

Where is the evidence, outside Hacker News, for this increasing popularity of static typing? The fastest growing languages by most metrics are currently Javascript and Python, both of which are dynamically typed.

According to GitHub's 2018 stats, the two fastest-growing programming languages last year were Kotlin and TypeScript. GitHub explicitly pointed out that "type safety" appears to be one of the biggest factors influencing language popularity in 2018. And even Python, the fastest-rising dynamically typed language, has been adding new static typing features in every release for the past three years. The last new Python app I wrote was fully type-annotated and typechecked, and the new data classes feature actually requires type annotations.

Re: Happy Birthday, Ruby

#155

Post by dnautics » Thu, Jan 10, 2019, 8:08 PM UTC

Karunamon wrote: post #130

dnautics wrote: post #119

Earlier quoted context omitted.

It does bring cognitive overhead, when it's not explicit

But you’re writing an ActiveRecord migration. It’s explicit in the same way that echoing a string out is ‘puts’ instead of ‘print’ because this is Ruby and not Python.

what if you're on a team where your responsibilities are divided and you only touch ActiveRecord sporadically?

What does ActiveRecord consider the plural of "fish"?

Re: Happy Birthday, Ruby

#156

Post by marcosdumay » Thu, Jan 10, 2019, 8:09 PM UTC

ken wrote: post #92

Buttons840 wrote: post #90

Earlier quoted context omitted.

Early in my career, I only "knew" a little C++ from a high school programming class I had taken, and I knew a tiny bit about Java. Then I found Ruby, and people talked very highly of it. But it had all these "Gems", I couldn't figure out what a Gem was. I didn't know enough. I thought it was like a compiler plugin or something. I thought that just like there were different versions of Java, there were different versi…

Python has a Cheese Shop full of Eggs. I love straightforward names as much as anyone, but I don't think Python is exactly the leader in this department, either.

Python's libraries come as eggs, wheels or source packages. Ruby has gems.

Rust inherited that characteristic, what is not great. It's not a big problem either, but it's there.

Re: Happy Birthday, Ruby

#157

Post by dnautics » Thu, Jan 10, 2019, 8:15 PM UTC

empath75 wrote: post #11

sho wrote: post #3

> Ruby isn't the most beautiful language out there Huh, I sure think it is. I wonder what the author thinks the competition might be? Ruby has its issues for sure, but aesthetics ain't one of them - far and away my favourite out of any major language.

I'm not sure what language would be more beautiful than ruby, to be honest, and it's not even my favorite language to use. Let's do a mini code challenge in the thread -- implement fizzbuzz in the most beautiful way you can, in the most beautiful language you know:

> I'm not sure what language would be more beautiful than ruby.

Elixir (with static type analysis) - gets a bit of an edge, IMO, thanks to pipes, which are way prettier than .then:

    defmodule FizzBuzz do
      @spec fizzbuzz(integer)::String.t
      def fizzbuzz(int) do
        cond do
          rem(int, 15) == 0 -> "FizzBuzz"
          rem(int, 5) == 0  -> "Fizz"
          rem(int, 3) == 0  -> "Buzz"
          true              -> inspect int
        end
      end
    end

    1..100
    |> Enum.map(&FizzBuzz.fizzbuzz/1)  #[0]
    |> Enum.join("\n")
    |> IO.puts

    #[0] function variables are a very slightly "ugly 
    #syntax" part of the language due to erlang legacy

Other stuff that's really pretty in elixir is the first class documentation. Elixir docs are out of the box prettier than ruby docs.

Compare from the official (but as a user you get these docs too):

https://ruby-doc.org/core-2.6/Array.html

https://hexdocs.pm/elixir/List.html#content

But again, it's only a bit prettier. Of course, if you try to browse both on mobile, Elixir wins handily. This is great for when you have to use the bathroom at the same time as you're in the middle of debugging and need to look up what a library module member function does, so there's some developer benefit edge too.

Re: Happy Birthday, Ruby

#158

Post by vidarh » Thu, Jan 10, 2019, 8:20 PM UTC

pavlov wrote: post #80

skywhopper wrote: post #48

Earlier quoted context omitted.

I don't understand your bit about "cuteness over familiarity". Can you give an example outside that's not Rails-related (given that Rails seems to be the main source of your concrete complaints)? Sigils in Ruby actually do have strong and clear meanings. And the difference between symbols and strings is a useful distinction. And contrary to your statement, Ruby's stdlib is far more complete and more internally consis…

Yes, maybe my problem is more with Rails. (Because of monkeypatched APIs, it’s not always obvious to me whether a particular weirdness originates from Ruby’s standard library or is a Rails addition. Arguably this is something the language has also encouraged though.) Is there any reason to use Ruby outside Rails? Its niche seems to completely overlap with Python and modern JavaScript, and those have enormously more e…

Monkeypatching to a large extent fell out of favour with Ruby developers maybe a decade ago, largely because of Rails. It's still being used, but with much more care and it tends to be far more "opt-in" (as in providing the facilities for you to specifically ask for it).

> Is there any reason to use Ruby outside Rails?

Personally I've disliked Rails for about as long as I've used Ruby (14 years). What appealed to me about Ruby then, and still does boils down to:

- Concise while being by far the most readable language I've worked with. The day something beats Ruby on that, I'll consider switching. If they don't beat it on that, they'll have to bring immense other advantages.

- The flexibility the blocks and meta-programming brings and general Smalltalk influence on the object model.

Ruby is in many ways basically a well supported Stalltalk with pretty syntax.

I'd turn it around: I don't see any reasons not to use Ruby for any of the type of work I do.

> faster VMs, better tooling,

The faster VMs would be nice, but Ruby performance is improving fast enough. In some niches it will matter, but you can call out from Ruby to other languages easily enough - you can run JS, C, Python code from Ruby if you need to, so both the performance and tooling is largely moot for my uses, while I can understand it's an issue for some.

The last time I saw a need to rewrite any code in C to speed it up was a decade ago. Of course that depends what you're doing, but for a lot of areas, it's just "fast enough" that there's little need to worry about speed. Premature optimisation and all that.

> large corporations on committees developing language features, etc.

Yeah, no thanks. That's a good reason for me to prefer Ruby as well.

Re: Happy Birthday, Ruby

#159

Post by vidarh » Thu, Jan 10, 2019, 8:28 PM UTC

pavlov wrote: post #34

welliman wrote: post #31

Earlier quoted context omitted.

Whimsical inventiveness is the one thing that keeps me enjoying the art of programming. There's a tension in programming between being verbosity and ingenuity. More flexible languages and programmers general favor ingenuity, while rigid ones favor verbosity. When people complain about the "magic" in Rails, it's usually because it's a pattern that is new to them, and they would have preferred an older pattern even if…

> "Whimsical inventiveness is the one thing that keeps me enjoying the art of programming." A personality difference then. Reading clever code does nothing for me. I'm much happier digging around hulking layered codebases that may look ugly but do something valuable for the user. I agree that the cuteness of a programming language is just a matter of taste and habit. I'm not going to pretend my criticism was anything…

What made me switch to Ruby was after I as an experiment rewrote a queuing middleware server that was about 5k lines in C, into about 500 lines of Ruby that had more functionality. It was slower, sure, but it drove CPU load from 1% to 10% of a single core before we hit disk IO limits, so it just didn't matter. What did matter was the improved maintainability of simplifying the codebase that much..

The point being that often the "hulking layered codebase" doesn't need to be.

Re: Happy Birthday, Ruby

#160

Post by dnautics » Thu, Jan 10, 2019, 8:30 PM UTC

eropple wrote: post #127

andjd wrote: post #123

Earlier quoted context omitted.

> And I think that a typed Elixir would get my attention right quick. Elixir _is_ statically typed, it just uses strong type inference so you rarely have to explicitly type things out. A key difference between Crystal and Elixir is that Crystal tries to replicate ruby syntax in a more performant language, whereas Elixir tries to apply the sensibilities of Ruby and the Ruby community to the Erlang VM.

I was using "typed" as shorthand for "statically typed", but Elixir is not statically typed. Typespecs aren't static typing and IMO they get messy when you want to do more than specify primitives. https://elixir-lang.org/getting-started/typespecs-and-behavi...

Dialyzer is indeed a pain in the ass, but what is not a pain in the ass is vscode's elixir_ls plugin which incrementally dialyzes and gently nudges you into making static type declarations (your code shows up uglier when you don't do it).

Life changing. It's stopped me from pushing runtime errors probably about 20 times now, in the last few weeks that i've been using it. At this point I'd say that it's strong enough to close 95% of the difference between static and dynamic typing.

Elixir's (maybe going to be merged into the standard library) property checking semantics (ExUnitProperty and StreamData) are quite amazing and super easy[0], and will catch whole classes of things that your compiler won't so I would strongly suggest checking out Elixir now.

[0] today I implemented in an hour a property check that makes me confident that a mathematical algorithm that I implemented for a fuzzer is ok (my first attempt was wrong), and then a property check that demonstrated that that algorithm applied to a stateful set of events doesn't violate critical invariants.

Also, you will almost certainly never get a statically typed Elixir, because it makes a lot of things like hot updates hard or inelegant. Sending interprocess/internode messages is something could be extremely intolerant to a static type system, because, in a way you're breaching the purity of the functional paradigm (it's the BEAM language's "one big lie"). Go struggles with this a lot in its channel semantic, and it's why there is a ton of boilerplate in gRPC (and almost no boiler plate in erlang RPC).

Also gently breaching the type system is incredibly useful in mock tests - for example, in my current project I do about 60 high-load end-to-end tests in parallel with clones of my central scheduling algorithm - this is possible because my test suite reaches into the main body, dynamically creates a new scheduler, and appends that information into an HTTP request, which is passed into a "plain old map" and intercepted only in test environment. This not only greatly accelerates the end-to-end tests (I run the full suite as a matter of course before each commit) but it also gives me confidence that my system will run under a load that is greater than I can manually trigger.