Live data from Hacker News

Ruby 3.4 Highlights

blog.sinjakli.co.uk

61–70 of 86 posts

Re: Ruby 3.4 Highlights

#61
post #41

Earlier quoted context omitted.

Yup. I don't mind switching languages, I've done it a few times and I enjoy learning new things. The market for ruby seems to have good salaries and job satisfaction despite being smallish, so it didn't seem like a bad area to get some experience in. Why, is there any issue with the choice I'm not aware of?

>Why, is there any issue with the choice I'm not aware of? No, not at all. I was just interested since there is a sudden influx of people joining Ruby ( I guess mostly Rails ) companies without previous Ruby background. As I have notice this across HN, Reddit, Twitter and elsewhere. And yes Ruby market tends to be on the slightly higher end because they mostly hire people with years of programming experiences and lac…

Ah well, as soon as I even glanced at Ruby my social media feeds were filled with tech influencers.

There is a niche there of very popular channels producing Ruby tutorials, seemingly aimed at the junior js-bootcamp dev crowd. They also focus on Neovim, tmux and other terminal based tools.

It is a completely anecdotal observation, but my guess is that it might explain part of the trend.

Re: Ruby 3.4 Highlights

#62
post #51
post #43

Earlier quoted context omitted.

Is that really something that's been slated to be added to the language proper? I attended RubyConf and in his keynote Matz seemed pretty opposed to adding types to Ruby source, and argued in favor of automatic typing instead.

You can always use Crystal or Dart if you want builtin types. I like Ruby the way it is an trust Matz with his language design decisions.

Yeah I actually did not necessarily mean to dispute Matz's perspective there. I actually think it will benefit programming as a whole if at least one widely used language takes the path of trying to eschew explicit type annotations.

Re: Ruby 3.4 Highlights

#63
post #51
post #43

Earlier quoted context omitted.

Is that really something that's been slated to be added to the language proper? I attended RubyConf and in his keynote Matz seemed pretty opposed to adding types to Ruby source, and argued in favor of automatic typing instead.

You can always use Crystal or Dart if you want builtin types. I like Ruby the way it is an trust Matz with his language design decisions.

Crystal is the closest alternative to Ruby with types we have, even though they are semantically different and differ in some places. I do not see why you mentioned Dart as an alternative thought, it’s a totally different language.

Re: Ruby 3.4 Highlights

#64
post #3

> In Ruby 3.4, it has been added as a default name for the first parameter passed to a block. Rather than specifying a name in trivial cases like the one above, you can now write: > [ > "beige chinos", > "blue jorts", > "rainbow jorts", > ].filter { it =~ /jorts/ } > # => ["blue jorts", "rainbow jorts"] This reminds me of Perl's $_ (which in Ruby is last line read from STDIN).

shame about that example, since

    ary.grep /(j|sh)orts/
already exists, and therefore sells the standard library short. try this:

    terms = %w(foo? bar q**x)
    Regexp.new "\\b(#{terms.map { Regexp.escape it }.join ?|})\\b"

    #=> /\b(foo\?|bar|q\*\*x)\b/
and observe that it's at the margins of instant comprehension where syntax shorthands like "it" add value.

Re: Ruby 3.4 Highlights

#65

Is ruby used outside of web dev (i.e., Ruby on Rails)? it seems like a nice cute language but I almost never hear about it.

I use Ruby extensively in ops scripting and text mangling, where it supplanted Perl for me around about the same time that Perl stagnated ca.2010-2015.

However, Ruby doesn't make sense to me as a general applications language (Swift & Kotlin have won me over from C++ & Java), or as a systems programming language (I'm still rusted on to C, pun intended), and I remain super ambivalent about Rails despite using it extensively to stick web interfaces onto things. That doubt is in large part because Rails frequently undermines the Smalltalk-ish heart of Ruby.

Re: Ruby 3.4 Highlights

#66
post #31
post #12

Earlier quoted context omitted.

At my day job we use Ruby with Sorbet to stitch together a large number of data engineering pipelines. It's a good choice since we also often stand up small Rails apps to expose the results from those pipelines, so we can keep everything in one language. The fluent functional approach it enables is pretty nice for that business logic (but I would not want to do it without the gradual typing on top). We do find oursel…

Oh nice! I haven't used Sorbet yet, but this is the second time I've heard good things about it outside of Stripe (where it originated). I'll have to give it a proper look.

I find it to be a mixed bag. Better than nothing, but doesn't come anywhere close to what something like typescript can do for example.

Re: Ruby 3.4 Highlights

#67
I have a love-hate relationship with Ruby. On one hand, it's a very expressive language that's excellent for building structured, lightweight applications. On the other hand, it requires significant discipline and a strong memory of your codebase and all the different types in play. When you combine this highly dynamic nature with Rails, especially its concerns and hooks, it can become extremely challenging to understand what's actually happening in the system.

Re: Ruby 3.4 Highlights

#68

Is ruby used outside of web dev (i.e., Ruby on Rails)? it seems like a nice cute language but I almost never hear about it.

Vagrant, chef, puppet and lots of other stuff is written in Ruby. It's also great as a scripting language replacing Bash, Python or Perl for any number of things. I write all my small, one off programs in Ruby.

Re: Ruby 3.4 Highlights

#70
I'm pleasantly surprised to see this improvement:

  Tempfile.create(anonymous: true) removes the created temporary file
  immediately. So applications don’t need to remove the file.
  [Feature #20497]
I use a similar pattern a lot:

  file = Tempfile.new.tap(&:unlink)
  file 
It's a neat trick to leverage the filesystem for large amounts of data (e.g. "psql \copy" generation), without littering tempfiles everywhere. Once the last fd disappears, the filesystem releases the data; so you don't have to "trap" signals and add cleanup routines. (Hint: you can also use these unlinked-tempfiles for command output, e.g. huge grep output, etc.)

On Linux systems, `open(..., O_TMPFILE)` is typically used, which provides additional safety. The created file is initially unnamed (no race condition between `open` and `unlink`).

When I needed safety, my non-portable solution was to use Ruby's syscall feature. (Btw, I love that you can do this.)

  require "fcntl"

  SYS_OPEN   = 2
  O_TMPFILE  = 0x00410000
  O_RDWR     = Fcntl::O_RDWR

  def tmpfile
    mode = O_RDWR | O_TMPFILE
    fd = syscall(SYS_OPEN, "/dev/shm", mode, 0644)
    IO.for_fd(fd)
  end
But... Another pleasant surprise from the PR (https://bugs.ruby-lang.org/issues/20497).

  Linux 3.11 has O_TMPFILE to create an unnamed file.
  The current implementation uses it.
Excellent to see :) Makes the PR even better!
Post reply on HN