Sick of Ruby, dynamic typing, side effects, and object-orientation (2014)

for at least 90% of the problems out there, its the the best approach. There are a lot of design patterns out there, but you can do a lot with MVC. From what i've seen, the reason developers tend to shy away from it is because it's TOO simple. They don't feel proud of it, because its so cut and dry. They want to create something unique and interesting and challenging, even if a simple solution would do just fine.

But it's not a balance, or a 50/50 sort of decision making. Really, MVC should be your first choice, and you better have a really good reason for it to not be, and a really viable alternative.

If you're writing 1000 lines of throwaway code I agree with you. If you're writing a 100,000 lines of code that is meant to be supported for years - then I disagree wholeheartedly.

No, JS won because the web won. There's a web browser on almost every computer out there. If you write your software in JS, you can run it just by following a link to a URL. That doesn't have anything to do with JavaScript's absurd module ecosystem.

There's a Rails way, Python famously aims for one obvious way of doing things. That just isn't true of Javascript exactly because there is a history of developers writing several styles of JS, the "right way" to write JS being redefined by diligent people like Douglas Crockford & John Resig and things changing yet again and yet again.

And look at ES6, the JS ecosystem barely resembles what was considered good, idiomatic Javascript just a few years ago. There are a bunch of devs who have managed to stay on top of what's current and I'm sure are laying down examples of good practices & building tools in that style. But you are also talking about an ecosystem that includes people that started writing JS 4-10 years ago, have adopted some of the absolute newest flavor of the month practices but also have seen JS change so much over the years that they aren't throwing themselves into everything that is now considered a best practice because they know their code works and there could be another seismic change in 8 months.

Writing Javascript nearly every line of code is haunted with "is this still the way I should do this?" and no other language has that much hassle.

Before I get into the details, as a general comment I find that while you're not wrong, I've found that I need much less 'diving into a pool' when I enter other language ecosystems. I understand why this is the case with JS, and personally I have a soft spot for the language, but even if it's not JS 'fault', I find that it is not a good thing that it takes such a 'deep dive'. They're valid concerns.

> - There is exactly one way to define a module. Write a file. Done. Webpack takes care of it.

it's a lot better now, but this has not been true even until recently. I've probably lost weeks of time over the years figuring out how to load module <x> using import statements where require() worked instantly, and from what I understand it can be a serious headache for module developers to support both 'ESNext' imports and CommonJS requires.

I can't tell how often I still need to search whether it is import x from 'x', import {x} from 'x', or import * as x from 'x', or in some cases the only thing that works is require(x).

> - The fact that Webpack either wasn't on your radar or already solving your problems says a lot.

Not really. I've used Webpack since the early days, and I've tried switching to Rollup, Brunch, and Gulp because Webpack just didn't make any sense to me. Then came Webpack 2 and half the tutorials and documentation stopped working.

FWIW I generally go for Webpack 2 these days, and it's an improvement. But it's a solution that causes quite a bunch of problems of its own. Plus, it's a solution that isn't even needed in anything but front-end JS. For good reasons, and I don't think JS is the cause of the problem (rather, it's bandwidth and general front-end concerns). Nonetheless, it's not even remotely simple.

> JS stdlib seems like nonsense? Lodash.

Why yes. I love lodash. But it's a huge library that I'd rather not load in its entirety if I'm not using most of it. Have you actually tried loading parts of lodash using import statements? Last I checked, a few months ago at most, this was not possible. I had to do require('lodash/blah'). That's not obvious until you've figured it out.

> Feels like you're importing too much bloat? Webpack tree shaking takes care of that. Closure compiler eliminates all the code you're not using. There's no reason not to use a first-class stdlib, whether it's Lodash or whatever else you prefer.

Webpack tree shaking is relatively new. Much of the online help (tutorials, etc.) still refers to Webpack 1.

> - The JavaScript community seems to have the opposite of NIH syndrome, so that even basic functionality is offloaded to a third-party modules (see leftpad). The project I'm working on has over 1000 modules in it's dependency tree.

> This is the power of JS. It's the thing to force yourself to embrace. You need to join the cult of bullshit and just mentally force yourself to love this rather than hate it.

I don't see how defending JS by telling someone to embrace the suck is any kind of valid argument in favor of the JS ecosystem. Could you elaborate?

> It's why JS won. You can hate it all you want and revel in the insanity, but there is zero reason to do that other than as a way of making yourself feel good. Which is just another way of saying we're all acting very selfish when we lash out at JS like this.

First of, JS won despite its quirks and the insane ecosystem. And second, selfish in relation to who? Brendan Eich? I think complaining about the things that do suck about JS and its ecosystem are important toward improving things. As a fan of JS, I don't feel offended when people say it sucks. It sucks, and while I think that's not primarily the language's fault, I also don't get my self-worth from being (predominantly) a JS programmer.

> Yes, you're correct. Every one of your points is absolutely true. Yet it's all so very wrong. I wish I could put it into words better than this.

Without meaning to be snarky, I'd love for you to elaborate. In the grand scheme of things I'm not a great programmer, and I got started with JS, so it's quite possible that I'm overestimating how much better the non-JS ecosystems are.

> Look dude. I've been around the block. [rant that I fully agree with]

> JS works now. That is not the expected behavior. It's difficult to convey how fucking strange this is. Anyone who lived through that 2006-era transition knows what I mean.

> But the way you know these things is by being a JS dev. Living and breathing it every day. There's no way around that. You either throw yourself wholeheartedly into the pool or keep one toe in while complaining about how big the ocean is.

> This rant came out quite a lot harsher than I intended; it's just a reaction to the very common trope that HN throws around of "JS is shit, the web is shit, this is shit." Yes, this is true. And yet -- simultaneously -- no. No no no. We can do magical things now. Hooking up Vue with hot reloading is literally magic. If 2007-era me had these tools, I would have launched a startup that could dominate everyone else solely due to the advanced tooling that we now enjoy. Our tooling now vs 2007 is like Lisp vs C++ back in 1999.

This I do agree with. I'm incredibly happy that front-end development has made massive steps in being saner than it used to be. And it does often frustrate me to read low-effort criticisms that don't really add to the conversation.

But in the past year I've ventured further and further out of my JS world, and I'm starting to understand why so many people are so negative about JS. If I were an experienced dev with little JS experience, the ecosystem would strike me as insane, to the point of just giving up and doing everything with 'server-side' languages. And honestly in the past few months I've been wondering if perhaps I've underestimated how much the JS ecosystem sucks. How much perhaps I've been Stockholm Syndrome'd into thinking this is normal in any way.

All that said, the constant criticism is grating. It doesn't solve anything, and it often carries a whiff of 'if only sane people were working in this area things would be different'. Which is utter bullshit. The JS ecosystem sucks, but it's the best we have, it's not because 'JS devs r dum', and in the end it often offers enough advantages to be worth the trouble. But that doesn't mean it isn't insane. It's batshit insane even now, but for the first time in years it's at least less frustratingly insane. We're moving in a good direction.

EDIT: let me add that I do agree that comparing JS to Ruby/Rails is not perhaps the best way to argue that JS isn't good. I'v encountered plenty of batshit in the Ruby ecosystem.

So the JS ecosystem is a giant pool right? Everyone is swimming in all possible directions with all sorts of contraptions like rubber tires, inflatable dinghies, pieces of wood, plastic garden flamingos, etc. A lot of the swimmers naturally pee in the pool because it's more convenient than exiting (that was frowned upon at the beginning, but people kinda got used to it - and it keeps a steady development speed!).

This might look quite horrifying to those on the outside, but for the swimmers it's nice and warm, while stepping outside is cold and scary, because they would have to learn all sorts of complicated and frightening technologies.

For someone like me that got out when the pool was small around 2006, there is no incentive to jump back in. I mean yes, if I closed my eyes and jumped I would probably adjust after a while. But why jump in the JS pool when I can swim in the open sea? :)

I agree 100%. If you're not infected you don't get it. Just like a healthy person may not understand the babbling of a delirious patient.

>I've been around the block. I vividly remember what this shit was like in 2008.

All the way back to 2008? Quite the block.

>JS works now.

JS doesn't 'work'. The language is still a mess. But the platform is beautiful. The runtime and compiler and the JIT are great. In the same way that NAT gave a ipv4 a lease on life, transpilation is what makes JS development tolerable.

But there are indeed still several module systems in use:

* globals (i.e. none)

* CommonJS

* AMD (just kidding, nobody uses this for new code)

* UMD (which mixes AMD, CommonJS and globals)

* SystemJS

* ES modules (via Webpack, browserify, whatever)

* ES modules in the browser (which behaves slightly differently)

That's 7 so I'll stop there. Yes, it's cheating a bit but of those I'd say AMD and UMD are the only ones that are dead as a doornail (for new code anyway -- plenty of libraries still use UMD for nostalgia). You'll only end up using one of them (or maybe two if you mix ES imports and CommonJS requires for some reason) but which one depends on which part of the ecosystem you end up with.

It seems that most of the community has adopted Webpack as the one true bundler for apps. Rollup is generally seen as better for libraries though.

Angular I think still promotes SystemJS, React is half-way between CommonJS and ES modules (via Webpack/Babel). I have no idea what Ember is doing.

If you want to add type safety, Angular strongly favors TypeScript while React is slanted towards Flow for obvious reasons.

The JS ecosystem is complex. Even if you cut out all the nostalgic stacks (MVC with Backbone and jQuery is still cool, right kids?) there are still many paths to pick from.

But I agree with your final conclusion: the reason the JS ecosystem is so complex is that it has changed a lot over the years and has seen massive improvement while still maintaining backwards compatibility at a language level with tons of legacy code that's still out there and still running in production.

Does that work yet? Last I heard, tree shaking was completely broken...[0]

[0] https://github.com/webpack/webpack/issues/2867

I remember what shit was like in 1998, which is why I get the same sort of aggressive reflex anytime someone is criticising Rails.

Back then, a web project could, and this is only slightly hyperbolic, include a file ```/project/htdocs/version-2.0-old/real/includes/templates/config.passwords.production.INC.php3~```

...and that file would start with ```<table>``` and, somewhere, include the SQL to delete a user.

That was the state of our industry when Rails was released. Which is why anybody who went through that transition weeps whenever people today regurgitate this bullshit about "magic" and "OOP considered harmful". Maybe functional programming is incrementally better. Maybe Rails is past its prime. But on a purely emotional basis, I feel defensive when some article doesn't start with a paragraph praising the genius of DHH before offering its criticism.

If you fight it, you are in a world of pain and that's even much worse if you don't the design choices they have made in Rails.

Having said that, if you jump into Rails the whole project structure will start to make sense after a while.

I completely agree on your impression of Ruby vs Rails.

Eg for "Hello World", you're not going to touch 99.9% of the auto-generated code. But you need to know where to look.

I agree that a lot of people don't make the distinction between rails and ruby. I had interns who where quite surprised you could use ruby without rails, and that "it's actually a complete language!". Ruby on its own is charming indeed. Rails gets the job done: few other tools enable you to finish a functional MVP in a day or two. But if you start to add gems for everything it just becomes a pain in the ass.

edit: I was f*cking mad when they added coffeescript. fortunately it's simple to disable (just removing the gem and changing a setting for the file generators)

Any framework seems "Crazy" and "Magical" at first. But once you get to know it, it becomes clear.

Rails is an opinionated, full featured framework with plenty of bells and whistles.

The core of rails is convention over configuration which means you will have a hard time going against the it.

Doing this bare minimum of due diligence is easy if you have 10 dependencies, but quite costly for a 1000.

I find it also funny that JS is at the top of the discussion about of article about ruby.

Many readers will be web developers. The biggest and most lucrative alternative to Ruby in that space is JavaScript.

Therefore: lucaspiller decided to remind people that switching to JS is not a good solution to Ruby's problems.

I don't like node.js, but I occasionally use Typescript like a more powerful C#.

Sadly, I'll probably never have a stretch of time to re-learn the C necessary to build one.

Following a GET request through a web server usually just involves some middleware, a dozen lines of route handler, a dozen lines of database queries or service calls, maybe an html template, and you're done.

Ruby is in that regard a lot like C or Perl. It gives you lots of power and options to solve a problem your way but that doesn't mean you should always do so. Rails has used those options extensively and that explains a lot of the criticism you hear about it.

This also means Ruby is not for everybody but what language is? IMO you can write unmaintainable code in any language and there is none that makes that hard enough, so I'm firmly in the camp that I'd rather have the full power at my fingertips when I need it than being restricted.

Although with the renaissance of functional programming, I would also love to discover a functional language that felt as fresh, powerful, and elegant as Ruby was for OO programming.

But the key there is that the meta-programming involved is very, very limited for a very high payback. As it is, it raises the barrier for new hires, and we want to make sure not to raise it higher.

And most of the rest of the code is taking an increasingly functional approach.

I tend to think there is "too much magic" in a lot of Ruby projects, so I try to be very careful and limit it to places were it so drastically cuts down on the amount of code that we can justify quite a lot of explanation and still come out far ahead. But when everything lines up, the benefits can be dramatic.

It's the maintenance that's driving this guy nuts, not the language itself. Haskel just happens to be his side project, which will, of course, look cleaner. I felt the exact same way when moving from Perl to Python.

Maturity as a programmer means being able to identify and do what it takes to get things done. Whether a developer is "happy", or "passionate" only begins to matter when they're doing what needs being done.

A true sign of maturity is when a programmer is faced with a workload that they are deeply unhappy about, but still get it done, because it needs to be done. The corresponding sign of mature leadership is acknowledging that developer's unhappiness and giving them extra money, work they enjoy, and/or time off after the crap work is done.

That is to say, picking products mature enough for production use, and executing your migration without feeling the need to justify it to the world by shitting all over your old environment.

Age has little to do with it. FWIW, Haskell is trendy right now. Probably for good reason. My issue isn't with the direction, it's the method.

- UNIX and C.

- Android and Java

- Windows and .NET/C++

- JME feature phones

- iOS and Objective-C/Swift

Or to taking it down to memory lane,

- Burroughs and ESPOL/NEWP

- IBM RISC systems, IBM zOS and PL/8

- IBM 400 and PL/S

- Lilith and Modula-2

- Native Oberon and Oberon

- UCSD and Pascal

- Lisa, Mac OS and Object Pascal

- Lisp Machines

- Smalltalk workstations

- Xerox Star and Mesa

- SpinOS and Modula-3

- .... (plenty more to list)

My time is pretty much 50% Ruby, 50% JavaScript. "stdlib can be patched to do random stuff" is a complaint I've often heard about Ruby, but in practice, I've encountered it precisely once in the last five years (extlib breaking with recent Ruby because of a to_h conflict, IIRC). I've lost way, way more time than that to JS idiosyncrasies.

    > Math.abs(-1)
    1
    > Math.abs = function(x) {return x + 1}
    > Math.abs(-1)
    0

Ruby's slowness is often mentioned, but Ruby is quick enough for many situations. I am very productive in Ruby and servers are cheaper than developers so for many purposes it works out just fine. I have tried Phoenix (Elixir) and I found it too verbose and complex to work with. I am sure though that others love it, so to each his own.

I get why people would like to pretend that everything is made up of beautiful uncomplicated small pieces, but that is not how life works. At some point you have to understand your tax returns, mortgage contracts and communications with incoherent external APIs. Making me jump to section 4.1.2 and from there to section 7.2 in order to understand the parties mentioned under 1.1a are subject to the rules set out in Appendix A section 42.1 does not make the contract easier to understand. So why would code that feels like a legal document be easier to understand?

That can be a good way to improve type-checking in code that would otherwise pass around bare strings. It reduces the chances that e.g. a plain text string is confused with an HTML string.

If your language supports it, an opaque type alias would be more explicit:

https://flow.org/en/docs/types/opaque-types/

Totally agree. Python does it in a more explicit way, so that you know "Here be Dragons" (in this object, that was defined in that specific place)

It's not like a piece of casual code in any module can turn your world upside down.

It's not a cultural bias. It's a critical difference in the language designs.

In python, monkeypatching is scoped to a module.

In Ruby, monkeypatching is global to the execution environment.

So in Python, you can look at the source code for a module in isolation and deterministically reason about what it does.

In Ruby, you can't. Because you can't know what the execution environment will be.

IMO, it's the main reason why Ruby projects become harder to manage as they grow. Somewhere, someone is monkeypatching, and reasoning about the code becomes harder and less local. I spent 2 years with Ruby and will never use it again if I can help it.

Imagine you need to know what time it is, and you're offered two options to find out.

One is to recite an incantation, a magic word, and the current time will appear in the air in front of you.

The other option you are offered is a clock or a watch. With this option, anytime you need to know the time you can simply look at the clock face and simply and immediately know, but when peeling back the surface, you can see an intricate set of gears all working together to keep track of the time.

On the surface, both of these options are equally easy to use and useful to find out the current time, but the clock will be far more fixable and extensible.

IMO we should strive to make our frameworks "mechanical" like the clock rather than magical.

Do not regret one bit

I'd rather use a combination of tests and stricter type checking. There's no sense in being a fundamentalist about either approach.

Wish I had time to look into Clojure. Excellent programming paradigm along with the interoperability, libraries, and platform support of the JVM.

It's a compiler that is built for each project with types specific to the domain problem being solved.

Language type checking misses the point. The types I want to check, and the extent I want to check them, are in the spec files.

Go type inference, for example, is deeply primitive and an awful lot of Go code seems to spend its time implementing duck typing via work arounds. It looks an awful lot like dependency injection for the 2010s.