codesnik

One mistake that bitten me a couple of times is not to reseed after fork(). AFAIR Perl calls srand automatically on fork, and I've been surprised that ruby at circa version 1.8 - didn't, which gave me quite some interesting behavior on production.

I'm sure some other runtimes don't do it, too.

I actually had a less than pleasant surprise when debugging sidekiq process with a higher than usual threads count, and noticing 100ms-multiples in my traces. 100ms before switch indeed seems to be too high for an app with a potential to misbehave.

we've seen newly government getting from shadow to the front row on the inauguration. No need to hide anymore.

and a very subtle f_f. I don't find those nice though.

yeah, you can combine it with % formatting operator to do stuff like `% %% % %%%`

thanks! I love ruby but I'd be afraid to do anything but web backends and shell scripting with it. it's people like you who move language adoption!

...but ruby is whitespace sensitive too. It's hard to notice, because rules mostly follow intuition, but there're cases when not only a missing newline, but absense or addition of a space changes resulting syntax. Currently I remember only difference in parsing unary vs binary operators, like + and *, and ternary operator ? : vs : in symbols, but there're certainly more other cases.

RSpec moved from that quite some time ago. Monkey patching nowadays is usually frowned upon, even refinements, which could simulate monkey patching in a limited scope, are rarely used.

huh. I'm not sure if I understood you right, do you script and configure those in ruby, or have you written them in ruby from scratch? Are the sources available to read/learn from?

poor man's chroot.

MUDs are played over network or on a multiuser mainframe, in realtime. DOS (and windows) machines back then were single user and networks for them were rare, specialized and/or asynchronous, like BBS.

I've played a MUD and accidentally learned Perl once.

unreadable perl?! I clicked on the link expecting something super-terse and unstructured, but it's anything but. What the hell is wrong with people casually dropping such remarks.

but it's also very extendable. It's ability to slap on new control structures and DSL's is on par with Lisp. I'd say it's very low level and much higher level than the most languages simultaneously.

um, a normal one? it looks exactly what I've seen on my grandmother's garden patch in my childhood. It's just that size is not very practical for supermarkets and a small family consumption, so current selection and harvesting methods go in the opposite direction.

I started on Perl as well back in a day, and used it long enough to get a list of things I didn't like, though I liked the basic principles. Ruby really is a Perl without unnecessary parts, which are surprisingly many. I remember noticing absense of reference and dereference operators in ruby and sitting dumbfounded for a minute, all that complexity and syntax noise just never needed.

I wonder in which language you think 1m locs would be manageable for an actual monolith (and not just a monorepo).

And method_missing is a such fundamental part of the language, that it obvious you skipped basic docs on the language. Besides that, there're not many "magic references". Unlike in python, btw, where "there should be 1 obvious solution to any problem" mantra doesn't hold for a veeery long time.

You can have indentation based syntax and ; for multiple statements in one line, or something even more powerful. But it doesn't matter.

Main power of blocks is not being multiline or being closure-like, many languages have this. But blocks are not just anonymous functions or lambdas, they have ability to return from the outer method (or from the method to which it was passed with break), acting as a powerful tool for creating your own flow control structures if needed, or just replacing "for". Of the languages I know or heard of only smalltalk does the same.

You can live without those, you can live even without early return, but blocks are not a misfeature, it's a great and intuitive tool. And python's rudimentary lambdas make me cry a little.

nobody serious uses indentation as a bad point against Python. Ruby pretty much could work with indentation instead of "end" almost without drawbacks. Maybe irb would be slightly less convenient, and that's it. Whitespace IS significant in ruby too, it's just goes so much along with the programmer's intuition that it rarely bites anyone.

I like ruby much more than python for many reasons, but that's one of those articles which present a lot of arguments so dubious and subjective that it almost convinces the reader that it's actually the opposite of what the title says.

also https://docs.docker.com/desktop/features/wasm/

for a lot of stuff we make from rubber various types of silicone polymers would probably work too.

"tech bankruptcy"! this is a VERY strong sentiment. First of all, I've never seen a rails-based company which has it problems from tech department, and not from product market fit or whatever, and that's in a 18 year carreer. I'm singlehandedly refactoring right now a 10-yearish rails app which had a period of neglect and bad contractors who broke every single test, and it is still very much manageable.

problem is that it does too much out of the box. Finding some sloppy formatting - ok. Fixing it automatically? even better. But rubocop tries to sniff "code smells", security problems, and it's not that great with it, not everything you can get about the logic and intent just from AST. There are so many rules that developers spent significant time appeasing rubocop and this sometimes takes away effort to make code actually readable by humans. Have you ever seen a tidy mess?

Even worse, it gives simple tools to write plugins to sniff more logic related stuff, and I've seen projects where developers really went overboard with it.

I also am not sure why it's intuitive at all. Article doesn't mention why - ruby has a parse phase, it doesn't scan your string byte for byte every time it runs looking for an interpolation. During the parse those "foo#{bar}" are replaced by something like 'foo'.dup << bar.to_str in the bytecode, but that happens only when parser hits #{ in a double quoted string, there's no penalty for that and it happens just once. Only really old, naive interpretators parse source code each time line is hit. (Or some weird ones, where interpolation can change semantics and argument count, like tcl and bash.)

strange, I think default rubocop setting is actually to add spaces around = in default values in functions. https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Layout/Spa...

this is an override in your project's .rubocop.yml

For me it's a bit opposite, I use and appreciate rubocop for simple formatting, not all of the rules but some of them, where autocorrect works. Recently I reformatted a big old project which was written by pretty sloppy developers who didn't care about whitespace, and it's just easier to work with now.

But I truly hate when rubocop tries to be smart about method calls, amount of lines in methods and amount methods or some other "code smell" metric.

yes, the tool allows to check for it, but it's not THAT smart. I have reasons. I'd happy to explain those reasons on code review to a human, but I'm not that happy to appease a dumb tool.

So, please do it as rails does, use bare minimals, something like https://github.com/rails/rubocop-rails-omakase

and ask other developers to stay away from .rubocop.yml

this isn't true for any half-ass interpretator out there. Perhaps some old PHP executable was slower with different quotes, but it's not true for ruby for decades. In bytecode there's zero distinction between "" and ''. Don't believe me? benchmark.

Nice. Now we can probably ask to move there half of the too nosy rubocop rules from the main rubocop repo. And then to never install rubocop-obsession!

if you're on os x, you can also do

  pbpaste > file

and if you're using zsh, just

  > file

is sufficient, without cat

if you prefer to use cat just to read your pipeline from left to right, you can just start your command with file redirection. It doesn't have to be at the end of the command.

  <file grep something | do something else ...

this works in bash too, but if you're using zsh, there're a couple of nice shortcuts

  <file

on it's own works as

  more file

and

  > file
  ...
  ...
  ^D

allows you to put something into the file quickly without firing up the editor. Though

  > file << end
  ...
  end

will give you nicer line editing experience.

more zsh redirection tricks here: https://zsh.sourceforge.io/Doc/Release/Redirection.html#Mult...