Hacker News Reader

Comment by vosper | Hacker News Reader

I question starting people on Ruby for web development. It was big and popular, but I feel that the popularity is fading (has faded?) for new projects, and there's a lot of magic in that language, too.

Anyone starting web development now would do well to stick with Javascript. No, it's not the nicest language, but there's no avoided it. And you can always use that on the backend if you have to - and if you need to spend time learning something for the backend part you'd be better served learning about relational databases than Ruby.

Anyway, between JS, HTML, and CSS, you're going to have a lot to learn. At least with CSS these days you can pretty much start with flexbox for layout, and maybe if you're lucky you'll never have to learn all the old horrible methods of getting things to look reasonable - or you'll have a solid foundation when you do encounter them.

View on HN

Problem is, none of the frameworks allows you to get up and running as quickly as Rails. Even Django doesn't come close in matching the sheer amount of magic in the Rails. There are gems available for everything under the sun; it's fun and all to play around with new frameworks but having to reinvent the wheel gets tiresome really quickly. Debugging can be a bit tricky and it's not the most performant framework out there but the overall productivity still outweighs everything else on the long term. Nothing else (except perhaps MS Access and their RAD tools) comes close to the speed at which one can get a CRUD app up and running and CRUD apps are pretty much 80% of all web apps.

The nodejs ecosystem with npm allows you to create CRUD apps very quickly. Look into express.js.

Also, my experience with the nodejs ecosystem has in general been better than with Ruby Gems. I have always hated Ruby magic and the problems it causes in gem incompatibilities.

Magic is wonderful when it works right, and painful when it goes wrong. I will absolutely agree that the magic built around speedy crud apps that handle 80% of what a web developer does making it only take a small fraction of time is a wonderful thing for productivity.

The problem with the magic for the 80%, is that the remaining 20% takes up the remaining 80% of the time. With the first 80% of the delivery in 20% of the time, the final 20% taking 4x longer because of the lack of understanding of the magic gives no advantage in the end.

Thats if everything goes well. If the 80/20 rule fails, you get the ninety-ninety rule ( https://en.wikipedia.org/wiki/Ninety-ninety_rule ).

RoR lets one build crud without understanding what goes on beneath the ActiveRecord. RoR is great when there is low complexity of the code and it is easy to follow the data through the pipes. Once it goes beyond that, adding complexity to that with the spooky action, highly declarative style that RoR encourages it can be painfully difficult to do - and something that far beyond what the 'write crud in 30 mintes/hours/days' classes offer.

Beyond that, with the failure to understand the before and beneath, one gets the impossible to debug bugs and security holes that lie within libraries that have been imported ( https://williamedwardscoder.tumblr.com/post/43394068341/ruby... ).

> RoR is great when there is low complexity of the code

I disagree. RoR is great when there's moderate complexity. Microframeworks (Sinatra) are better for low complexity, and everything with high complexity is a unique and special snowflake.

> Magic is wonderful when it works right, and painful when it goes wrong

...and really educational when you start digging into it, and then you generally realize it only went wrong because you were trying to do something stupid.

> the remaining 20% takes up the remaining 80% of the time

Sure, but that's because the first 80% took a fraction of the time, not because that last 20% takes a multiple.

Do you have a particular example?

> spooky action, highly declarative style that RoR encourages

This is a bit of a "cognitive style" difference. In most of RoR - particularly your models - you want to be describing the idea of the thing. Since most people start programming by writing procedures, this is a bit of a leap. RoR Models are not about how a thing gets done, but about what that thing is. When you think from this perspective, RoR models are easy and nice.

> Beyond that, with the failure to understand the before and beneath...

Straight up, I want you to explain the complete before and beneath of your favorite tech stack or this is problematically hypocritical. I would then also want you to explain why it's reasonable to expect this of all programmers, rather than just senior programmers.

> Straight up, I want you to explain the complete before and beneath of your favorite tech stack or this is problematically hypocritical.

I can answer this one. I could explain to you every aspect of go's net/http package and database/sql package. The interface is compact, and even the source is very legible and easy to digest. You don't need all the extra bullshit to build API and run CRUD operations. I am a former RoR developer. I have lost no speed in just using simple tools and simple packages.

Also, I can have a junior or associate developer from any background get up to speed in a matter of days. Where as when I was at the Rails shop, you specifically had to hire a "rails guy/gal" and even then still took them days to get started.

(Don't mean for this to be a "go is great" rant, I am sure there are equally simple tools out there - Dropwizard is another one that comes to mind -- just a bunch of jars glued together)

I suspect that you learned a lot from Rails, though. For example, your applications probably have a thought-out directory structure, you clearly understand how the applications are layered, you probably pay attention to having good names, and think about testing.

It is possible to learn good practices without seeing well-structured applications that you can use as "role models", but it's really hard (I know, I had to read how to structure n-tier applications from books, and then apply it to a deficient platform that my employer had standardized on).

The "just use standard library" argument often seems a bit deceptive to me, though. For example, how are you managing schema updates?

> I suspect that you learned a lot from Rails, though. For example, your applications probably have a thought-out directory structure [..]

Absolutely, not saying my experience doesn't translate. However directory structure doesn't exist like you think in go. Files are the primary organization, and the only thing that goes in subfolders are different packages. It's actually quite nice, now I don't need to dig into 4-6 folders to get to the important stuff like I did in my Java/RoR days.

> The "just use standard library" argument often seems a bit deceptive to me, though.

It is absolutely a mantra in the go community. No deception here.

> For example, how are you managing schema updates?

Use your favorite tool! So funny you mention, I have a RoR background and I loved active-record migration, so I use standalone active record migration https://github.com/thuss/standalone-migrations, but you can just as easily use any other schema migration tool like Liquibase.

But what I am learning more and more these days is to just write sql. Write your migrations in plain sql. It's always easier for everyone involved. SQL is a ubiquitous language.

> every aspect of go's net/http package and database/sql package

Nice! That sounds really appealing; I want to learn Go, I just haven't felt like I've identified a problem I want to solve that's best solved in Go.

That said, the obvious direction this questioning is going is...

Well, but either you're relying on the database and networking magic, or you need to understand the before/beneath of the database and networking; and it keeps recursing down until you get to the point of electrons in silicon, and then the switch is "magic of the scientific method".

How do you draw the line of "this magic is fine" and "this magic is not fine"?

It sounds like maybe the line isn't "do you know" but rather "what does it take to learn", and that Go makes it easy to learn the before / beneath?

But I think if you really are just starting out learning programming then it's still a lot of effort to get a Rails system up and running (you need a database, too, which is another new thing) compared to the bare minimum, which is to use something like Meteor, Firebase, or even (gasp!) Mongo.

I'm not saying that Rails has no place, and it might well be the best next step, but I wouldn't put it (or Django, maybe Express) in a course for absolute beginners. Perhaps in the follow-up course :)

Getting php with the laravel framework running is much easier and quicker

But then you'd have to work in PHP

Yeah, who would do that ? Seriously, who are those Facebook, Wikipedia or Wordpress anyway...

I'm currently working with Laravel and have worked with other PHP frameworks, as well as Rails and Sinatra. Both Rails and Laravel can be very easy to create new projects with, but I don't think that claims of a clear advantage for Laravel can be substantiated.

>none of the frameworks allows you to get up and running as quickly as Rails

Nearly every single PHP framework is faster and more intuitive to deploy than Ruby on Rails.

I find that rather hard to swallow. If you are trying to deploy PHP frameworks on your own there are a number of hoops you need to jump through on the server side to get things going. If you are using a deployment service, it's hard to beat things like Heroku and AWS ElasticBeanstalk for deploying Rails application.

I am definitely a fan of Ruby and Rails. So I am biased. But I have deployed my fair share of PHP and find it hard to imagine how it is easier.

For many php frameworks it's as simple as downloading a zip file and ftping files to your hostgator shared account.

Places like digitalocean have prebuilt machines for both. On a new centos or ubuntu server installing php/composer/laravel can be done in 10 steps.

In the laravel world we have forge which allows you to script and provision your stack

>AWS ElasticBeanstalk

We're talking about novice web development and you're invoking AWS?

PHP is unzip, plug and play. Or single click any VPS "LAMP" package and go.

EDIT: Also, let's assume the target person runs a Windows machine. XAMPP is at least... 10 times easier to set up than Ruby/Rails on a local instance. And that's being exceptionally charitable.

For me the value of Rails is that it puts a lot of good practices into every application.

Once you are more advanced as a developer or have a larger project then you might not like some of the choices that Rails makes, but it not only saves work but does more than most teams could or would realistically do if they have to assemble an application with just Sinatra or Express as a base.

For learners, having the framework lay out known-good stuff in a standard structure for all of the dozen or so elements that a Web application needs is incredibly helpful. You can let Rails create the application skeleton, and then work through the different parts, knowing that it all hangs together.

I'm one of the maintainers of the project, I think that Ruby is still a good language for beginners to learn programming.

Ruby has very expressive syntax, allowing beginners to focus more on the core programming concepts. Its object model also makes it a nice language to learn the basics and best practices of OOP.

The resources out there for beginner programmers and Ruby are also top notch and the community is very friendly to beginners.

This is completely anecdotal, but we've had a fairly decent number of students come into the chat rooms telling us they started with javascript as a beginner but weren't getting it, ruby was much easier for them to get up to grips with.

I admit that I've seen a few students put off with the magic in Ruby, but those really have been a very small minority of students compared to those who really embraced learning it.

In saying all this, we have plans to focus more of our efforts on Javascript and give students the option to choose a javascript track in the curriculum.

When hiring junior developers, I look for experience in at least two general purpose languages, because I think comparing and contrasting at least two languages gives you a valuable and necessary perspective. In web software engineering, Ruby+JavaScript (or Python+JavaScript or Go+JavaScript, etc) is a convenient and powerful way to check this box, but "full-stack JavaScript" falls short.

I think Java would be a better second language than Ruby. It is radically different from JS despite the name and is incredibly useful to know due to its wide usage. It also serves as one or the lingua francas of the CS community (alongside C of course).

Not that I think Java is a pleasant language. It is quite a monstrosity in terms of syntax and verbosity, but that doesn't mean it isn't useful to know.

As a data point, I started actual-programming in Perl 15 years ago, started on Rails about 10 years ago, and am now taking Java classes to get some interview-question fundamentals under my belt, since Rails is historically a recovery path for Java programmers. I don't know how it works the other way around, but for me Java has been pretty easy after writing Ruby for some years.

And you're coming into java at a better time - lambdas and inferred generic types for contractor calls reduce the boiler plate a little. I work on a big java project - I'd love to write new stuff in kotlin though.

It's really interesting to be going in the other direction. People learn Java/C++ in university, then get jobs writing PHP or whatever. I can't imagine how cynical that would make a person, at the very least against their student loans! Not to language-war, natch. But going "in reverse" really feels like an excavation. "Interesting, this is what they had (have, like in your case) to do before langs/frameworks evolved!"

Hah, do you happen to be expecting the need for junior developers in the coming year? ;)

And an actual question: when hiring for [junior] web development roles, would you for example take into account knowledge of non-web languages like, say, 6502 assembly & C++?

I'm curious as in the coming year I'll be graduating and on the hunt. Although I consider myself proficient in JavaScript (and Python to a much greater extent) my hobby interests lie more in microcontrollers, "retro" programming, and just general electronics. Would that sort of background be a boon in your opinion, or would you prefer a candidate with more strength in web technologies? (though by golly I swear I will one day get my homebrew computer connected to the World Wide Web!)

Based on what I've seen "in the wild", my current recommendation is to first learn the basics in Ruby (a week or two - from basic arithmetic through objects), and then jump to Javascript.

This is primarily because most of the "learn X" that I've seen for Javascript is pretty web-centric, while the "learn Ruby" things that I've seen are much more general CS. So the idea is to first get a basic grounding in general programming, and then jump into the thing you'll use a lot for your particular application.

Example: Learning about scope in JS versus basically anything else.

Also, Rails really does encode basically all the best-practices - so when you literally don't know any better, you can still succeed. And then when you move away from Rails, you have a known-good way to start anything.

Probably the same reason there's so much jQuery in the front-end curriculum. Five years from now it may not be true, but there's still a ton of jobs in Ruby and jQuery. (more so than in some of the "cool" stacks)

Yeah. You just don't hear about those because people are actually working instead of writing medium.com posts about cool stacks. :^)

im not so sure if js is the right choice for beginning developers. i actually would not encourage beginning developers to jump into javascript. well, im assuming we are talking full stack here and not just client side, as the state of js is in flux and the js fatigue is real. and i cant imagine letting beginning developers to go through that even when experienced devs are having trouble dealing with it.

basically nodejs is not just getting into express anymore. although optional, most likely you will soon have to get into things like react, flux, transpiling, and understanding immutable and fuctional programming, which are all IMO a bit too much for developers to jump in to. also, js is currently changing at a rapid pace, what they learned a year ago is most likely obsolete in todays standards, ie: es5/6/7/next. i have not seen a language change so many times in such a short period of time, i cant imagine how beginning developers can deal with it.

i actually had a chat with recently grad bootcampers who went through a 3months courses of rails and then nodejs/react from General Assembly in LA. their responses to rails was easy to learn and they picked it up right away. but once they got to react/nodejs their experiences were something closer to horror.

id say js indeed was a good choice for beginners 3 - 4 years ago but now there are so many baggages involved such as dealing with setting it up through webpack and its many ways to transpile such as esnext/jade/stylus/etc.

so unless you have a few years of programming experience, i would not recommend devs to go through js at this time.

basically i can teach someone rails on how to build real world applications in a few weeks. but with js, id still be explaining the internals like what is a promise, async vs synchronous function, etc. and this even before diving into the world of redux, map reducers, webpack, immutablejs, higher order functions, and ... the list goes on.

anyway you take it, its a long road ahead with js, much longer than most people will tell you.

    I question starting people on Ruby for web development.

Heavens forbid using a popular, practical language combined with a mature and even more popular web framework.

    Anyone starting web development now would do well to stick with Javascript.

Yes, let's recommend people to use a language where the things they learn (to use) stop being maintained/used/relevant 1 month later.

    And you can always use that on the backend if you have to

You can use Ruby in the frontend as well: http://opalrb.org/

    and if you need to spend time learning something for the backend part you'd be better 
    served learning about relational databases than Ruby.

What? Learning Ruby doesn't somehow mean you can't learn about relational databases.

When learning/teaching something you very much want to pick something that:

1. Has been around for at least 5 years

2. Is actively used, maintained, and overall has proven itself

3. Has good documentation and tooling

4. Perhaps has programs to help people getting started (Rails Girls, PyLadies, etc)

5. Is still around 5 years from now

Ruby and Rails are a perfect choice for this, though Rails (just like most frameworks out there) _is_ a bit complex for total beginners.

I was trying to suggest that it's already a lot to learn Javascript, CSS and HTML for absolute beginners. I don't think adding Rails to the mix does anything except make things more complicated. In another comment, I added that I wouldn't use Django, either, and suggested that Meteor or Firebase are probably a better place to start brand-new developers. The fewer new things you're throwing at them in one go, the better.

And if you look at the recently published (and fairly well received) IEEE language rankings, you'll see that Ruby is ranked 9th for the number of jobs, and has Java, C#, Python, and PHP ahead of it - all languages with one or more major web frameworks. Any of them would be a better choice for someone looking for work, according to these charts.

Also, let's be honest - in the scheme of things, no-one uses Ruby on the front-end.

[0] http://spectrum.ieee.org/static/interactive-the-top-programm...

If you are writing RDBMS centric apps, the way your app interact with your DB matters a lot, maybe even more than choice of a programming language. This is where ruby has real superstars, Sequel and ActiveRecord. Nothing I've seen in other languages comes close to Sequel's power, expressiveness and flexibility to query databases. This is the main reason I use ruby. On top of that, ruby is so elegant, it often puts a smile on your face, when you realize how elegantly you have solved a particular problem.

I tend to agree. Ruby isn't super applicable in 2017 either. Most tech companies have moved to a microservices architecture and while they may have some legacy Ruby hanging around, it's unlikely they're building anything new with it.

Someone learning web development now has a long road ahead of them. They'll need to learn everything. Not just some backend language, but all the front-end frameworks, functional programming, Sass, build tools, typescript, etc. The list is endless.

> I question starting people on Ruby for web development.

This.

What's a synergistic language? Javascript (i.e. it's required learning for the browser, and you get the backend with Node - and you point this out.) Javascript has advantage from browser monopolization.

What's a great and increasingly popular language for the backend? Python. And Python is so nice that we don't need a slogan about how "Guido is nice so we are nice" (with apologies to Matz and the dwindling Ruby community).

Write your software so simple that there are obviously no deficiencies, not so complex that there are no obvious ones (Hoare, 1980). Ruby is way more complex than Python because there's a bajillion different ways to do it.

To me the only point of learning Ruby is if you're already in a job that maintains a Rails app.

The battle for the supreme interpreted language isn't over, but, like Perl, it's my humble opinion that you can count Ruby out.

> we don't need a slogan about how "Guido is nice so we are nice" > there's a bajillion different ways to do it

I would definitely say that these are serious strengths of Ruby, not weaknesses. Here's why:

Ruby is foremost concerned with the experience of the person using the tool. To use an analogy, many of us spend a lot of time finding keyboards and layouts that harm us less, or do not actively harm us. You would avoid using a hammer if the grip was painful to hold.

Ruby may appear to have a bajillion ways to do something, but actually, it's just many different ways to communicate the same few things to other people. Since you are free (and able) to use any of many ways, you can choose the one that is actually the most communicative, not the one that should be the most communicative. But, as you begin to peel back that facade and understand what's underneath (that everything is a thing that is a combination object, reference, and function), you see that it's actually pretty simple.

The result of this is that in Ruby, you can - and can benefit from - deeply considering the structure of the thoughts that code describes. Particularly in Rails, you can consider the idea of the thing you are dealing with, and then you write down the description of that thing; Ruby magic then makes that description code.

That is, ultimately, why I think Ruby is a "synergistic" language, and an excellent one with which to start: it [can] teach you to think in a way that's independent of any given language - about what is occurring for the computer, and more importantly, what is occurring for the programmer. You can then take that learning and apply it everywhere else.

Mostly, I just know how bloody frustrating it is to work with (most) libraries and APIs that aren't from (or inspired by) Ruby-land, and how (generally) easy and convenient it is to work with things from (or inspired by) Ruby (and Rails).

As someone who prefers Ruby to Python I lament the odd coincidence that Ruby, the language most strongly influenced by Perl, seems to be suffering the same fate as its predecessor - fiddling while Rome burns. Ruby needs 3x3 yesterday to compete with all the languages that are eating its lunch but I doubt if we'll see it before 2020. Worst case scenario is Ruby 3x3 turning into another Perl 6.

This assumes you want anything to do with the front end :).

Maybe a better tact at why JavaScript first: people are far more likely to hire junior front end people than junior backend.

This is how I hire

> I question starting people on Ruby for web development.

news.ycombinator.com and its various tentacles runs on Ruby and Arc

Right. There's a lot of stuff that's in use I wouldn't recommend for starting with.

Reply on news.ycombinator.com