I do a lot of ML and AI work nowadays... I miss Ruby a lot especially the its culture around ergonomics.
Pstore: Ruby Built-In Hash Persistence
21–30 of 42 posts
Re: Pstore: Ruby Built-In Hash Persistence
#22I do a lot of ML and AI work nowadays... I miss Ruby a lot especially the its culture around ergonomics.
There have been some interesting ML gems rolled in the past few years: https://ankane.org/new-ml-gems Any thoughts on what the Ruby community would need to build in order for it to become an attractive tool for AI work?
Something would need to happen that makes Ruby far more attractive. Say performance parity with Crystal or Nim.
Re: Pstore: Ruby Built-In Hash Persistence
#23I do a lot of ML and AI work nowadays... I miss Ruby a lot especially the its culture around ergonomics.
Have you tried Scala?
Re: Pstore: Ruby Built-In Hash Persistence
#24Earlier quoted context omitted.
> too many issues Such as?
Marshal is Ruby's version of pickle in Python: it serializes arbitrary objects, which means that correct deserialization requires arbitrary code execution. This is bad enough on its own, but it also makes pivoting a file read/write primitive into code execution much easier.
Re: Pstore: Ruby Built-In Hash Persistence
#25Don't use this. Marshal has too many issues. If you really need persistence and can't use something like Postgres, use the Ox gem instead. It's more reliable between versions of Ruby and easier to parse from other languages if you ever have to.
> use the Ox gem The main thing is that it's part of the standard library. If you import a gem anyway, often you'd be well off with sqlite. As for storage format, there's also: https://ruby-doc.org/stdlib-3.1.2/libdoc/yaml/rdoc/YAML/Stor...
I even created a little gem when I was starting with Ruby, 10 years ago, that was a very thin wrapper around it so that I could play around using an ActiveRecord like syntax (https://github.com/brunnogomes/active_yaml). I used in some pet projects so I could do stuff like:
p = Post.new
p.title = "Great post!"
p.body = "Lorem ipsum..."
p.save
Post.all # => [#]
Post.find(1) # => #
Post.where(author: 'Brunno', visibility: 'public')
# => [#, #]
And have access to the data directly in the YAML files.Good times!
Re: Pstore: Ruby Built-In Hash Persistence
#26pstore has been a built-in with Ruby stdlib for as long as ruby has existed, so _over_ 20 years.
I'm assuming it pre-dates Rubygems because it really should be a gem. I can't speak for Japan but few people in the Western world seem to use it.
Or maybe it would be a hard task that didn't justify the effort.
Re: Pstore: Ruby Built-In Hash Persistence
#27Earlier quoted context omitted.
Marshal is Ruby's version of pickle in Python: it serializes arbitrary objects, which means that correct deserialization requires arbitrary code execution. This is bad enough on its own, but it also makes pivoting a file read/write primitive into code execution much easier.
Pickle is fine (in a pinch). It's not meant for untrusted data.
Re: Pstore: Ruby Built-In Hash Persistence
#28Earlier quoted context omitted.
There have been some interesting ML gems rolled in the past few years: https://ankane.org/new-ml-gems Any thoughts on what the Ruby community would need to build in order for it to become an attractive tool for AI work?
My guess is some kind of corporate sponsorship. Someone with deep pockets to maintain it, encourage new apis keeping up with the latest papers, and make sure it works out of the box with the accelerator people want to use this month.
Maybe that's why Ruby is best known for Ruby on Rails.
Re: Pstore: Ruby Built-In Hash Persistence
#29Re: Pstore: Ruby Built-In Hash Persistence
#30Earlier quoted context omitted.
I'm assuming it pre-dates Rubygems because it really should be a gem. I can't speak for Japan but few people in the Western world seem to use it.
There was a time when some stuff was being extracted (removed) from Ruby core and becoming gems and I really tought PStore and YAML::Store were going to be among those, but no, they decided to keep them in core. So maybe there are some important enough use cases that justify it being there. Or maybe it would be a hard task that didn't justify the effort.
It's now no longer technically stdlib, but a "default gem", a gem that is installed by default with ruby, see: https://stdgems.org/
Since a few years every version remove one or two rarely used default gems. The Ruby core team just doesn't like big breaking changes.