thảo luận Tương lai của Ruby 3.0.

Project mới viết giờ ít người chọn ruby. Do vậy số lường người dùng chỉ có giảm chứ ko tăng được.
 
Theo mình thì nó sẽ không comeback được nhưng nó cũng éo thể chết được, job thì cứ tà tà chứ cũng không hot, làm crud bằng ruby on rails thì mình chưa thấy thằng nào làm nhanh bằng, còn về performance thì khỏi bàn :D
Thử Django chưa?
 
Chắc là chủ yếu là mấy cái di kèm hầm bà lăng và support 3rd party ấy nhỉ. Sinatra thì chắc cũng chỉ routing
sinatra tương đương với expressjs của node thôi, feature có khi còn ít hơn.
được cái là dễ dùng, đọc cái README.md của nó là đủ, tiện cho thằng khác phải maintain.
 
Thử Django chưa?
Bạn đang so sánh về tốc độ build crud hay là performance. Performance của Rails chậm như rùa nên không cần so sánh cái này làm gì. Còn build CRUD thì với những library nó đã hỗ trợ trong Rails thì mình khẳng định là build nó nhanh hơn những thằng khác.
 
Bạn đang so sánh về tốc độ build crud hay là performance. Performance của Rails chậm như rùa nên không cần so sánh cái này làm gì. Còn build CRUD thì với những library nó đã hỗ trợ trong Rails thì mình khẳng định là build nó nhanh hơn những thằng khác.
Tôi nói về tốc độ build CRUD đó. Tôi ko làm Rails cũng gần 10 năm rồi, ko biết bây giờ nó còn có thêm những magic gì, nhưng tôi nghĩ cái CRUD bây giờ là quá đại trà rồi, Rails sẽ ko có gì nổi trội so với những thằng khác trong việc build CRUD đâu. Tôi lấy ví dụ Django nhé, 1 model Client có 3 fields: first_name, last_name, email. Code đại khái chỉ cần vầy thôi:

code.png


Là coi như xong, có ngay tất cả những endpoints cần thiết cho CRUD, tất nhiên là có sẵn luôn validations tùy theo attributes của từng model field, và nó cũng generate ra luôn cho mình cái swagger schema:
api.png

patch.png


Như vậy vẫn ko đủ nhanh gọn bằng Rails sao?
 
Tôi nói về tốc độ build CRUD đó. Tôi ko làm Rails cũng gần 10 năm rồi, ko biết bây giờ nó còn có thêm những magic gì, nhưng tôi nghĩ cái CRUD bây giờ là quá đại trà rồi, Rails sẽ ko có gì nổi trội so với những thằng khác trong việc build CRUD đâu. Tôi lấy ví dụ Django nhé, 1 model Client có 3 fields: first_name, last_name, email. Code đại khái chỉ cần vầy thôi:

View attachment 342174

Là coi như xong, có ngay tất cả những endpoints cần thiết cho CRUD, tất nhiên là có sẵn luôn validations tùy theo attributes của từng model field, và nó cũng generate ra luôn cho mình cái swagger schema:
View attachment 342176
View attachment 342177

Như vậy vẫn ko đủ nhanh gọn bằng Rails sao?
nói đến django lại buồn, tôi trước nghe người khác khen nức nở cũng nghĩ là django ngon ngang rails, cho nên có cái project remote làm cùng thằng bạn (mới quay lại code dc 1 2 năm), nó bảo là muốn làm BE với django thế là cho bạn làm vì nghĩ là django cũng chả vấn đề....

kết quả thì phải nói là chán luôn, django admin thì không customize được, bảo thêm này bỏ kia thì cứ quặc "django admin chỉ đến thế thôi", case insensitive cũng không làm được, gõ cái gì cũng phải chú ý đúng case.

tôi không rõ là do django thế hay do bạn tôi mới dùng nó thế, chứ ruby/elixir thì tôi dùng citext extension từ nhiều năm trước chả thấy vấn đề vẹo gì, admin thì không tiện bằng django thật nhưng có scaffolding nó cũng hỗ trợ tương đối, chỉ gõ đúng cái câu lệnh là ra hết một đống files, sau đó thì thích sửa thế nào thì sửa.

sau vụ này có thằng nào bảo là tao dùng django chắc tôi chạy luôn :)
 
nói đến django lại buồn, tôi trước nghe người khác khen nức nở cũng nghĩ là django ngon ngang rails, cho nên có cái project remote làm cùng thằng bạn (mới quay lại code dc 1 2 năm), nó bảo là muốn làm BE với django thế là cho bạn làm vì nghĩ là django cũng chả vấn đề....

kết quả thì phải nói là chán luôn, django admin thì không customize được, bảo thêm này bỏ kia thì cứ quặc "django admin chỉ đến thế thôi", case insensitive cũng không làm được, gõ cái gì cũng phải chú ý đúng case.

tôi không rõ là do django thế hay do bạn tôi mới dùng nó thế, chứ ruby/elixir thì tôi dùng citext extension từ nhiều năm trước chả thấy vấn đề vẹo gì, admin thì không tiện bằng django thật nhưng có scaffolding nó cũng hỗ trợ tương đối, chỉ gõ đúng cái câu lệnh là ra hết một đống files, sau đó thì thích sửa thế nào thì sửa.

sau vụ này có thằng nào bảo là tao dùng django chắc tôi chạy luôn :)
Cái manual của django in ra chắc cũng hơn 2k pages, nên tôi thấy đa phần các vấn đề là do lỗi người dùng chưa kịp đọc kỹ, đặc biệt là mấy cái ông nói ở trên, đều là những cái lookup rất basic của django: exact/iexact, contains/icontains, startswith/istartswith... Nếu những cái này còn chưa nắm thì làm sao nói đến chuyện customize django admin được. Còn mấy cái db extension như citext, unaccent... cũng đều có support hết, cứ import vào là tự động có ngay SQL migration scripts up/down luôn, ko cần phải vào db để run create extension hay drop extension gì cả.
 
nói đến django lại buồn, tôi trước nghe người khác khen nức nở cũng nghĩ là django ngon ngang rails, cho nên có cái project remote làm cùng thằng bạn (mới quay lại code dc 1 2 năm), nó bảo là muốn làm BE với django thế là cho bạn làm vì nghĩ là django cũng chả vấn đề....

kết quả thì phải nói là chán luôn, django admin thì không customize được, bảo thêm này bỏ kia thì cứ quặc "django admin chỉ đến thế thôi", case insensitive cũng không làm được, gõ cái gì cũng phải chú ý đúng case.

tôi không rõ là do django thế hay do bạn tôi mới dùng nó thế, chứ ruby/elixir thì tôi dùng citext extension từ nhiều năm trước chả thấy vấn đề vẹo gì, admin thì không tiện bằng django thật nhưng có scaffolding nó cũng hỗ trợ tương đối, chỉ gõ đúng cái câu lệnh là ra hết một đống files, sau đó thì thích sửa thế nào thì sửa.

sau vụ này có thằng nào bảo là tao dùng django chắc tôi chạy luôn :)
Cái customize quá nhìu thì nên tự viết React hay hơn là để cái Admin của Django(hoac bất kì fw nào cũng thế, cust nhìu thì tự làm dễ quản hơn).

Django mình đánh giá là quá khủng rồi, mình không dùng php nên ko biết bển thế nào chứ làm RDB truyền thống thì Django nhanh và tiện nhất rồi dù mình vẫn thích kiểu micro fw + data mapper flask + sqlalchemy hơn .
 
Trễ rồi Ruby giờ bị Python nó hiếp trên mọi mặt trận, mặc dù cũng thích Ruby nhưng phải công nhận giờ dùng Python vẫn ngon hơn :doubt:

Còn bên Python hiện giờ trên mặt trận web framework thì chỉ có 2 thằng đáng dùng thôi, full-feature thì Django, micro thì FastAPI. Tôi nói thật kết hợp 2 thằng này thì vô cmn đối mà làm nhanh vô cùng.
 

Ruby 3.0.0 Released​

We are pleased to announce the release of Ruby . From 2015 we developed hard toward Ruby 3, whose goal is performance, concurrency, and Typing. Especially about performance, Matz stated “Ruby3 will be 3 times faster than Ruby2” a.k.a. Ruby 3x3.

Optcarrot 3000 frames


With Optcarrot benchmark, which measures single thread performance based on NES’s game emulation workload, it achieved 3x faster performance than Ruby 2.0!

These were measured at the environment written in https://benchmark-driver.github.io/hardware.html. was used as Ruby 3.0. It may not be 3x faster depending on your environment or benchmark.

Ruby 3.0.0 covers those goals by
  • Performance
    • MJIT
  • Concurrency
    • Ractor
    • Fiber Scheduler
  • Typing (Static Analysis)
    • RBS
    • TypeProf
With above performance improvement Ruby 3.0 introduces a number of new features described below.

Performance​

When I first declared “Ruby3x3” in the conference keynote, many including members of the core team felt “Matz is a boaster”. In fact, I felt so too. But we did. I am honored to see the core team actually accomplished to make Ruby3.0 three times faster than Ruby2.0 (in some benchmarks). – Matz

MJIT​

Many improvements were implemented in MJIT. See NEWS for details.
As of Ruby 3.0, JIT is supposed to give performance improvements in limited workloads, such as games (Optcarrot), AI (Rubykon), or whatever application that spends majority of time in calling a few methods many times.
Although Ruby 3.0 significantly decreased a size of JIT-ed code, it is still not ready for optimizing workloads like Rails, which often spend time on so many methods and therefore suffer from i-cache misses exacerbated by JIT. Stay tuned for Ruby 3.1 for further improvements on this issue.

Concurrency / Parallel​

It’s multi-core age today. Concurrency is very important. With Ractor, along with Async Fiber, Ruby will be a real concurrent language. — Matz

Ractor (experimental)​

Ractor is an Actor-model like concurrent abstraction designed to provide a parallel execution feature without thread-safety concerns.
You can make multiple ractors and you can run them in parallel. Ractor enables you to make thread-safe parallel programs because ractors can not share normal objects. Communication between ractors are supported by exchaning messages.
To limit sharing of objects, Ractor introduces several restrictions to the Ruby’s syntax (without multiple Ractors, there is no restriction).
The specification and implementation are not matured and may be changed in the future, so this feature is marked as experimental and show the “experimental feature” warning when the first Ractor.new.

The following small program measures the execution time of famous benchmark tak function (Tak (function) - Wikipedia), by executing it 4 times sequentially or 4 times in parallel with ractors.

def tarai(x, y, z) =
x <= y ? y : tarai(tarai(x-1, y, z),
tarai(y-1, z, x),
tarai(z-1, x, y))
require 'benchmark'
Benchmark.bm do |x|
# sequential version
x.report('seq'){ 4.times{ tarai(14, 7, 0) } }

# parallel version
x.report('par'){
4.times.map do
Ractor.new { tarai(14, 7, 0) }
end.each(&:take)
}
end

Benchmark result:
user system total real
seq 64.560736 0.001101 64.561837 ( 64.562194)
par 66.422010 0.015999 66.438009 ( 16.685797)

The result was measured on Ubuntu 20.04, Intel(R) Core(TM) i7-6700 (4 cores, 8 hardware threads). It shows that the parallel version is 3.87 times faster than the sequential version.
See doc/ractor.md for more details.

Fiber Scheduler​

Fiber#scheduler is introduced for intercepting blocking operations. This allows for light-weight concurrency without changing existing code. Watch “Don’t Wait For Me, Scalable Concurrency for Ruby 3” for an overview of how it works.
Currently supported classes/methods:
  • Mutex#lock, Mutex#unlock, Mutex#sleep
  • ConditionVariable#wait
  • Queue#pop, SizedQueue#push
  • Thread#join
  • Kernel#sleep
  • Process.wait
  • IO#wait, IO#read, IO#write and related methods (e.g. #wait_readable, #gets, #puts and so on).
  • IO#select is not supported.
This example program will perform several HTTP requests concurrently:
require 'async'
require 'net/http'
require 'uri'

Async do
["ruby", "rails", "async"].each do |topic|
Async do
Net::HTTP.get(URI "https://www.google.com/search?q=#{topic}")
end
end
end

It uses async which provides the event loop. This event loop uses the Fiber#scheduler hooks to make Net::HTTP non-blocking. Other gems can use this interface to provide non-blocking execution for Ruby, and those gems can be compatible with other implementations of Ruby (e.g. JRuby, TruffleRuby) which can support the same non-blocking hooks.

Static Analysis​

2010s were an age of statically type programming languages. Ruby seeks the future with static type checking, without type declaration, using abstract interpretation. RBS & TypeProf are the first step to the future. More steps to come. — Matz

RBS​

RBS is a language to describe the types of Ruby programs.
Type checkers including TypeProf and other tools supporting RBS will understand Ruby programs much better with RBS definitions.
You can write down the definition of classes and modules: methods defined in the class, instance variables and their types, and inheritance/mix-in relations.
The goal of RBS is to support commonly seen patterns in Ruby programs and it allows writing advanced types including union types, method overloading, and generics. It also supports duck typing with interface types.
Ruby 3.0 ships with rbs gem, which allows parsing and processing type definitions written in RBS.

The following is a small example of RBS with class, module, and constant definitions.

module ChatApp
VERSION: String
class Channel
attr_reader name: String
attr_reader messages: Array[Message]
attr_reader users: Array[User | Bot] # | means union types, User or Bot.
def initialize: (String) -> void
def post: (String, from: User | Bot) -> Message # Method overloading is supported.
| (File, from: User | Bot) -> Message
end
end

See README of rbs gem for more detail.

TypeProf​

TypeProf is a type analysis tool bundled in the Ruby package.
Currently, TypeProf serves as a kind of type inference.
It reads plain (non-type-annotated) Ruby code, analyzes what methods are defined and how they are used, and generates a prototype of type signature in RBS format.

Here is a simple demo of TypeProf.

An example input:
# test.rb
class User
def initialize(name:, age:)
@Name, @age = name, age
end
attr_reader :name, :age
end
User.new(name: "John", age: 20)

An example output:
$ typeprof test.rb
# Classes
class User
attr_reader name : String
attr_reader age : Integer
def initialize : (name: String, age: Integer) -> [String, Integer]
end

You can run TypeProf by saving the input as “test.rb” and invoke a command called “typeprof test.rb”.
You can also try TypeProf online. (It runs TypeProf on the server side, so sorry if it is out!)
See the documentation and demos for details.
TypeProf is experimental and not so mature yet; only a subset of the Ruby language is supported, and the detection of type errors is limited. But it is still growing rapidly to improve the coverage of language features, the analysis performance, and usability. Any feedback is very welcome.

Performance improvements​

  • Pasting long code to IRB is 53 times faster than bundled with Ruby 2.7.0. For example, the time required to paste this sample code goes from 11.7 seconds to 0.22 seconds.
https://gist.github.com/aycabta/30ab96334275bced5796f118c9220b0b
  • The measure command has been added to IRB. It allows simple execution time measurement.
irb(main):001:0> 3
=> 3
irb(main):002:0> measure
TIME is added.
=> nil
irb(main):003:0> 3
processing time: 0.000058s
=> 3
irb(main):004:0> measure :eek:ff
=> nil
irb(main):005:0> 3
=> 3
 
Last edited:
Giờ ra ver mới thì cũng chỉ cho các dự án đang chạy thôi. Dự án mới team toàn build bằng elixir.

Với tôi, cả Ruby và Elixir đều là ngôn ngữ lập trình back-end tốt. Và yếu tố quan trọng để đưa ra chọn lựa giữa Ruby và Elixir là nhu cầu của dự án.

Trên thực tế, anh em có thể sử dụng cả hai công nghệ trong một dự án bằng cách chọn công nghệ nào trong số đó hoạt động tốt nhất cho từng tính năng riêng lẻ. Ví dụ: bạn có thể phát triển tính năng chat với Elixir Phoenix và phần còn lại của mã nguồn có thể được viết bằng Ruby on Rails! :)
 
Tôi nghĩ mà đắng lòng ko biết Ruby 3.0 nó ngon thế nhưng project mới thì ko ai dùng nó rồi. Có may ra các dự án củ migration lên thôi.
Ruby 3.0 mới ra, nên Ruby on Rails 6.1 chưa có các tính năng cập nhật fend à!
Ruby on Rails 6.2 sẽ update các tính năng mới và khi đấy sẽ có thêm developer tham gia! :)
 
Back
Top