Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Rails still relevant in 2018?

blog.eq8.eu

Post reply on HN
Print view View original

121–130 of 346 posts

Re: Is Rails still relevant in 2018?

#121

Post by vasilakisfil »

fouc wrote: post #118
zerogvt wrote: post #116

I'm not a web or compiler/interpreter dev so this is probably a noob question but here it goes anyway. If the main complain about ruby is that it is slow then why not trying to make it faster? I don't know how easy or feasible that is but is there an effort towards that?

Absolutely. Ruby has had major performance improvements. Plus there's also JRuby for those that want access to the Java ecosystem. Alternatively we can detect bottlenecks and re-write those in a different language, such as Rust.

..or Crystal.

Re: Is Rails still relevant in 2018?

#122

Post by sjwright »

fsloth wrote: post #35
thinkingkong wrote: post #16

I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish? If we know something really well and there are enough developers to support an ecosystem and the talent pool in your is big enough just use whatever you want. PHP in 2018? SURE. C++ in 2018? SURE (You masochist) Rails in 2018? Youre damn right I would. GO in 2018? OK. Fine. Whatever. This is…

"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

Jai? (Obviously not yet a good alternative, but worth being aware of in case it perfectly suits your project...)

https://inductive.no/jai/

Re: Is Rails still relevant in 2018?

#123

Post by golergka »

pjmlp wrote: post #63
fsloth wrote: post #35

Earlier quoted context omitted.

"C++ in 2018? SURE (You masochist)" I know this is tongue in cheek, but if one is doing anything related to real time graphics programming I'm not aware of any good alternatives.

C# is slowly getting there thanks to Unity efforts with HPC# and Microsoft's improvements on SIMD support, stack allocation and slices. Then on the browser you are stuck with GLSL 3.0 shaders, or any JS library that generates them on the fly. But yeah for the layer that actually talks to the metal, it is still going to be C++ for many years, specially thanks to the ongoing language improvements since C++11 revision.…

I'm a fulltime Unity lead developer and I love C# as a business logic (or game logic) language, but it becomes quite ugly for hot code that is perfomance-critical. Once you get thousands of objects that you have to process every frame, you have to throw the usual C# object-oriented style and things like Linq (and I'm a fan of Linq!) out of the window and write code that reads like C. And when you get to object pools, well, that's practically the same thing as writing your own allocator (only instead of allocating arbitrary memory, you allocate objects).

Seriously, for this kind of tasks there's nothing better than C/C++ - and I write this as someone who is actively AFRAID of power of C++ and uses less powerful tools whenever and wherever possible (because I don't want all that power to shoot in my own leg).

Re: Is Rails still relevant in 2018?

#124

Post by ryanbrunner »

onion2k wrote: post #109
thinkingkong wrote: post #16

I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish? If we know something really well and there are enough developers to support an ecosystem and the talent pool in your is big enough just use whatever you want. PHP in 2018? SURE. C++ in 2018? SURE (You masochist) Rails in 2018? Youre damn right I would. GO in 2018? OK. Fine. Whatever. This is…

...our jobs are to make stuff that works in a predictable, less risky way. Do that. This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging to…

> These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job.

All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees. Certainly not in every situation, but enough that it doesn't make sense to dismiss them out of hand.

Re: Is Rails still relevant in 2018?

#125

Post by lbriner »

Lots of these discussions are about how "nice" a framework is but there are other genuine pressures, including the availability of developers - either outsourced or in-house. As newer frameworks and languages become the weapon of choice, developers in other frameworks dry-up and it becomes easier to, say, port a system from .Net to Node/Angular/etc.

Of course, not everyone has the luxury of being able to rewrite or create a new site from scratch, which is why lots of companies really struggle to succeed.

There is also the issue of trade-offs, not just in the more obvious "performance" but as the OP mentioned, in velocity, in security defaults, in documentation, in community support. Something that might seem attractive to a newb who just needs to do something quickly might not appeal to a more experienced developer who would rather have something that works more correctly/securely/performant.

Re: Is Rails still relevant in 2018?

#126

Post by ryanbrunner »

gadders wrote: post #117
onion2k wrote: post #109

Earlier quoted context omitted.

...our jobs are to make stuff that works in a predictable, less risky way. Do that. This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging to…

>> You shouldn't jump from one language to another every few months, but you should keep a close eye on what other languages are doing and ask yourself if switching would improve the code you write. Shouldn't that last sentence be "... if switching would improve the end product or service you are delivering." The focus should be on what people are paying you for. Better code doesn't always mean a better product, or b…

The two are equivalent in most cases. There's a relatively small set of problems where the choice of programming languages will have an effect on the product that doesn't come down to the code being more understandable and more amenable to change.

Pretty much speed is the only concern for the vast majority of web applications, it isn't really that big a concern for most web applications, and even then it's less about choosing the fastest language and more about limiting yourself to a still pretty broad set of "faster" languages.

Re: Is Rails still relevant in 2018?

#127

Post by joelbluminator »

meijer wrote: post #104
joelbluminator wrote: post #85

Earlier quoted context omitted.

I think the types argument is bullshit but it's just my opinion. Do python or ruby devs really feel they are less productive than java devs because they have no types? What I see happening is languages like java becoming more dynamic (var etc) and languages like ruby/python getting better IDEs (auto completion will continue to improve).

> Do python or ruby devs really feel they are less productive than java devs because they have no types? Yes, I do.

OK, it's a fair opinion to have. But that's all it is, an opinion. Also - what makes you stick to python/ruby then?

Re: Is Rails still relevant in 2018?

#128

Post by [deleted] »

onion2k wrote: post #109
thinkingkong wrote: post #16

I mean... Let's pause for a minute and remove the year, and remove the language / framework. What are we trying to accomplish? If we know something really well and there are enough developers to support an ecosystem and the talent pool in your is big enough just use whatever you want. PHP in 2018? SURE. C++ in 2018? SURE (You masochist) Rails in 2018? Youre damn right I would. GO in 2018? OK. Fine. Whatever. This is…

...our jobs are to make stuff that works in a predictable, less risky way. Do that. This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging to…

[deleted]

Re: Is Rails still relevant in 2018?

#129

Post by ryanbrunner »

schizoidboy wrote: post #19
sho wrote: post #9

Of course it is. The question is kind of silly. For basically any startup, my advice would be: unless and until you can credibly explain a genuine reason why you can't use Rails - use Rails. I'm not some crazy fanboy but until someone can actually name a seriously competitive, batteries-included, all-in-one framework* which delivers everything, or even most of, what Rails does - it is very relevant and you ignore it…

> your list of 30 random npm packages does not satisfy the requirement I like Rails, but to be fair, doesn't Rails also require a list of 30 random gems? Unless things have changed, authorization and authentication aren't even built-in, so people have to navigate random third party gems, and remember, you don't want CanCan, but you want the fork, CanCanCan. Again, I like Rails, and maybe it's still the nearest to an…

Authentication is built into Rails, albeit in a less "batteries included" way than something like Devise. You'll have to code your own user model, but `has_secure_password` will give you perfectly fine security around storing passwords.

And while gems like CanCanCan are great, not every application needs them, and it's relatively straightforward to set up authorization logic directly for most simple cases (i.e. something like "users control their own things, admins control everything".

You're right in the sense that I've very rarely seen sizeable apps that are mostly "stock" Rails outside of things literally developed by Basecamp.

Re: Is Rails still relevant in 2018?

#130

Post by beaconstudios »

ryanbrunner wrote: post #124
onion2k wrote: post #109

Earlier quoted context omitted.

...our jobs are to make stuff that works in a predictable, less risky way. Do that. This is very true, but it doesn't mean "Use the thing that's worked in the past because that's less risky." Languages get better and tooling improves, and if you're still using one that isn't keeping up then you're increasing risk. These days if your chosen language doesn't have things like strong typing, interfaces, good debugging to…

> These days if your chosen language doesn't have things like strong typing, interfaces, good debugging tools, a good compiler, etc, then you should definitely be asking yourself if it's the right tool for the job. All of these things existed long before Ruby on Rails gained in popularity. Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits…

> Unless the popularity of Rails, Python, PHP, and Javascript was all just collective insanity, dynamic languages do offer benefits in some circumstances over languages with stronger type guarantees.

with strongly typed languages it's harder to perform exploratory coding. This drives a kind of backpressure on the design stage of development where it becomes more prudent to design your classes and interfaces before you start coding, because changing interfaces part way through development is a much larger undertaking than in, say, Javascript. On the other hand, strongly typed languages provide a lot of guarantees that have to be coded for in dynamic languages. This is why I prefer gradual typing - you get the best of both worlds.

Post reply on HN