Live data from Hacker News

Ruby 3.3

ruby-lang.org

191–200 of 277 posts

Re: Ruby 3.3

#191
post #186

Earlier quoted context omitted.

Why Rails, instead of a lighter-weight framework, if performance is such a priority? Obviously that wouldn't get you to [anywhere near] the performance of compiled Go code, but Rails has a lot of overhead. What database is on the backend, and is that db serving cached content? What happens if you cache it with e.g. redis to avoid the heavyweight rails ORM stuff? Do you have granular benchmarks for the db query, reque…

First implementation was in Rails because the company is a Rails shop and the monolith was the easiest place to get something that works. If you rewrite it anyway, might as well use something else than ruby. The db (mysql) is not the problem in the scenario I described.

> If you rewrite it anyway, might as well use something else than ruby.

You just said the company is a rails shop, why would you force a new language on everyone who already invested in understanding ruby?

Re: Ruby 3.3

#192
post #183

Earlier quoted context omitted.

Hi-tech are cyclical. Ruby got nothing else bigger than Rails unfortunately no matter how people in that community is hyping Ruby out. It's okay if Ruby and Rails on a downward trend it might pick up again in the future. C'mon now, we all know that our industry is like a Fashion industry. The only reason why Rails is making a comeback is because we're in tough time: no more VC money to hire tons of Engineers to build…

Correct. But now there is another complication to an eventual reemergence of ruby on rails: the competition defeated the initial comparative advantage - i.e. the simplicity - of the RoR platform. The premises that justified RoR in the past are too weak today in my opinion. The framework was sold on how easy and no-nosense it was setting it up and start prototyping your commercial solution in a time where the competit…

Now?

Spring Boot has been there for ages. It changes nothing really.

Spring Boot was created solely for spinning up Microservice quickly. This is a different segment than Rails.

Spring Boot was overtaken by Golang in the microservice arena in US hi-tech scene. There's just way too may Go-based infrastructure that boosted Go ascend to the Microservice arena from 2016/2017-today. My experience might be just anecdotes but I worked for multiple companies that used to be Java based shop and they all moved away from Java/Scala to Golang and build tons of microservices (whether that strategy is the right thing to pursue or not is a different discussion altogether).

Yeah, Spring Boot might eventually decided to "tack" on the UI option (thymeleaf) but it's too late. Hi-tech already jumped to the latest fashion: Go, docker, k8s, with some sprinkle of ELK and Prometheus for monitoring.

> It's really hard to see a bright future for RoR and ruby and I think that most of their contribution was already given.

They're going to sit nicely in the corner where they belong: web-app. Nothing more, nothing less.

I'd argue the one trending down is Spring, especially after they joined VMWare and now VMWare is part of Broadcom.

Take this with a lot of grain of salt from someone who was a staunch defender of Java during the Spring (DI, MVC), DropWizards, Hibernate=>JPA2 era, skipping Ruby/Rails hype. I moved on from Java to Golang in 2018-2019 and haven't looked back despite switching multiple companies. Prior to that, I was swimming in Java world with multiple companies.

Now that I'm back in the market for my own webapp (side project, fun), I'm not going to use Golang for good reason and I'm not planning to go back to the Spring world either. Rails it is for me...

Re: Ruby 3.3

#193
post #78

Earlier quoted context omitted.

I'm so glad that you said this and weren't downvoted into the ground. Honestly, Ruby needs to die. It performs like a go cart in a Formula 1 race. I'm actually just exhausted watching smart people tell me this is a language and toolchain worth dedicating brain cells to.

What a bizarre take. Ruby is primarily used in web applications, where round-trip http requests, database queries, and other 10s-of-ms things are commonplace. Ruby is very rarely the bottleneck in these applications. Choosing to make your job significantly more challenging in order to maximize the performance of a small portion of the total response time of a web application is not, in my estimation, a smart decision…

You're literally the exact person I'm talking about. No serious application developer who's interested in speed is working in Ruby. This isn't my opinion. I don't care personally, it's just a fact if you care about reality. When Netflix announces that they use Ruby because it performs faster than Node.js, I'll change my opinion, because my opinion is based on facts and not feelings. I didn't make Ruby, so whether it does well or fails isn't personally important to me. If Ruby was the fastest interpreter, I'd be pro-Ruby but it absolutely isn't and pretending it is is depressing and shows you are making political or selfish decisions, not practical ones.

Re: Ruby 3.3

#194
post #88
post #78

Earlier quoted context omitted.

I'm so glad that you said this and weren't downvoted into the ground. Honestly, Ruby needs to die. It performs like a go cart in a Formula 1 race. I'm actually just exhausted watching smart people tell me this is a language and toolchain worth dedicating brain cells to.

Ruby and Python are the only two ecosystems that seem to prioritize developer happiness. They're a pleasure to work with. So they're not going to die anytime soon.

Python is somewhat pleasure. Ruby might as well be sandscript as far as I'm concerned. The use of pipes is gross, uncoordinated and lacking direction.

Re: Ruby 3.3

#196

Earlier quoted context omitted.

Further, with a lot of the batteries-included web frameworks you end up with a ton of suboptimal database queries (e.g. unintentional query-in-loop). Some would argue that you can just profile your code and optimize the hot spots, but I would tend to think it still slows you down quite a bit overall.

One of the biggest breaking changes that EF Core did was to explicitly disallow such generated queries that required application-side evaluation and could not get compiled to pure SQL (you can get other behavior back with a toggle but it is discouraged). I strongly believe it is wrong to do otherwise and is a source of numerous footguns unless you invest in tracking them down.

I will admit I'm behind the state of the art with EF, but I switched to dapper in the early days of dotnet core and never looked back. It gets out of my way so I can properly utilize postgres' advanced features like jsonb while cutting out a lot of the boilerplate associated with hand-rolled queries.

Re: Ruby 3.3

#197
post #169
post #164

Earlier quoted context omitted.

> ... lack of first-class functions and iterators/generators, as well as the general iteration protocol. I'd love to hear what makes you say this - none of it is meaningfully true (ruby doesn't have functions, but it has blocks and callables). It has: https://docs.ruby-lang.org/en/master/Enumerator.html

What is the distinction between a function and a proc? I would say that a proc is a (first-class) function.

As I said, claiming that ruby doesn't have first-class functions isn't "meaningfully true". Ruby does not have functions, only methods. But that's mostly irrelevant.

https://en.m.wikipedia.org/wiki/First-class_function#Languag...

> The identifier of a regular "function" in Ruby (which is really a method) cannot be used as a value or passed. It must first be retrieved into a Method or Proc object to be used as first-class data. The syntax for calling such a function object differs from calling regular methods.

https://blog.appsignal.com/2018/09/04/ruby-magic-closures-in...

> Ruby doesn’t have first-class functions, but it does have closures in the form of blocks, procs and lambdas. Blocks are used for passing blocks of code to methods, and procs and lambda’s allow storing blocks of code in variables.

Re: Ruby 3.3

#198
post #18

I believe with version 3.3 Ruby is back in a big way! The language focused on developer happiness and derided for its slowness is slow no more. YJIT is an amazing technology, and together with other innovations like object shapes and various GC optimizations, Ruby is becoming seriously fast! Big Ruby shops such as Shopify [1] have been running 3.3 pre-release with YJIT and reporting double digit percentage performanc…

I’ve never met literally anyone who saw ruby and was happy. It’s always “but it’s written in ruby”

I have to write awful primitively-obsessed Python at work. I LOVE Ruby.

Re: Ruby 3.3

#199
post #191
post #186

Earlier quoted context omitted.

First implementation was in Rails because the company is a Rails shop and the monolith was the easiest place to get something that works. If you rewrite it anyway, might as well use something else than ruby. The db (mysql) is not the problem in the scenario I described.

> If you rewrite it anyway, might as well use something else than ruby. You just said the company is a rails shop, why would you force a new language on everyone who already invested in understanding ruby?

Because people know Ruby well, including use cases that it's not a good fit for. We use Go in other places, too.

Re: Ruby 3.3

#200
post #66

Earlier quoted context omitted.

I worked with ruby, ruby in rails(RoR) more specifically, a bit more than ten years ago(2011-2013). At that time it was already the afterglow of RoR, the framework for web development that had come to life in 2005 and raged between 2007 and 2009. The latest-technology-addicted crowd was jumping into the boat of node.js, that was crazy fast compared to anything done RoR, and API oriented development with angularjs. In…

> Ruby doesn't do anything better I'll bite. Even at the most basic level of built in functions/methods (String, Array, Hash) - I found Ruby's to blow Python's out of the water. https://ruby-doc.org/core-2.5.1/String.html https://www.w3schools.com/python/python_ref_string.asp Even Python's choice of naming and syntax to use these basic functions just hasn't been thought through as much as Ruby's implementation. There…

Kitchen sink isn't the best design imho. I see many of the additions are regexp functions. While I do use them it's rare because they quickly become unreadable. Agree with the python design to decouple and discourage them by requiring an import.

With the recent additions of the prefix/suffix methods I have no desire for any more.

https://docs.python.org/3/library/stdtypes.html#string-metho...

Post reply on HN