In that case -- I definitely agree Ruby usually gets out of way. It's often my go to for hacking on something, unless it's data science-y.
I'll mention: implicit returns, return if, and safe navigation, the &. operator. Ruby's newer pattern matching features are really cool[1], especially for things like JSON structures, but I've only use started using them. Classes are also super easy to extend.
Many of these things are also incredibly easy to abuse - but they have their places.
Comparing Apple Silicon and x86 as the difference between having modern plumbing or not...not exactly where I expected the review to go! Gruber's hyperboles can be entertaining for sure.
But damn, I can't wait for the time for me to upgrade my Intel Macs.
But the difference really is stark. Hard to describe, you have to try it yourself. I was lifelong win/lin user but switched over to macos just because of m1 was better in the price range than anything else. I hated my work issued 2019 intel macbook with passion but I love my m1. I suspect it's going to be a long wait until I can switch back.
Classic. Switch from Intel to M1 felt more like an upgrade from NetBurst laptop to Core series for me, a great step forward but not really groundbreaking imho.
Oh I think they are! Gruber is by no means alone in his praise. And the technical details are impressive. (Plus the 14" and 16" are fantastic improvements.)
They didn't delete a part of container, they deleted a part of the docker file. Actually removing data from already built container image, as title suggests, would be much more impressive.
The final result is a 78% smaller docker image, not container. But the way they achieve it, is by running a container of the image, running the functional test suite, then remove everything that was unused when the test suite ran, creating a new image from the results of the removal.
I don't think the title is purposefully misleading, it's just incorrect by mistake (confusing image/container).
TBH, I thought that they would delete a part of a running container, something to do with de-allocating memory pages in runtime and all that low-level C magic, but now I see that it was just a really weird way to read this on my part.
More productive is really hard to say... But I personally prefer Ruby to Python. For smallish scripts, I really like Ruby's backticks for easily executing shell commands. And I find the metaprogramming support in Ruby great for some tasks. I'm not sure if that's what you're getting at.
But especially with "modern" Python features like f-strings and the walrus operator there's not tons of differences that really stand out as "productivity".
One thing to just remember: Ruby is not just the Ruby on Rails community. Rails is a dominate space, but it's not the only thing out there. At the same time, when it comes to scientific computing, ML, etc. the Python ecosystem is incredibly robust. There's plenty of awesome Ruby tools for these things too, but it is not the same.
Ruby and Python are the two languages I primarily teach courses in, and used professionally. Ruby is my cup of tea personally, but they're both modern dynamic interpreted languages.
> For smallish scripts, I really like Ruby's backticks for easily executing shell commands.
Executing external commands is pretty convenient in Python these days, now that we have subprocess.run [1], and passing the command as a list rather than through the shell seems a lot safer.
Doesn't backticks open up the classic command injection issues (i.e. the same kind problem as SQL injection with non-parameterized queries) unless you're extremely careful to manually apply proper quoting in every single case?
It would, but most of the time when I'm using backticks, it's because I'm writing myself/my team a little helper script that will never get "injected" with anything. Backticks (and the other more featured ways of doing shell commands in ruby) make it really easy to write what amounts to a Bash script, but with a little more features and readability, or pull in some relevant libraries for some more complex task that would be annoying to do in pure Bash.
Your use case might be different from mine, but I find that usually there is some parameter needed for the command, usually a filename or sometimes the output from another command. Even if you're not accepting hostile data over the network, you probably want it to work correctly for any valid filename.
With a bash script, or shell commands as strings in general, I can usually with some work be reasonably sure that I'm handling filenames with spaces correctly, so that it doesn't explode when it encounters something unusual... mostly, probably, in most places ... I hope. But what about filenames with newlines? Probably not as correctly. Etc.
With a parameterized API, this all just works and is correct for all cases, so you don't have to think about arcane quoting rules.
To be fair, there are some of the more complex ruby libraries that do provide those more protected/parameterized options. In general, even when I wrote a script that took input, I found it sufficient to just assume that if another dev tried to use it for something where it broke, they could work out how to fix it, or rename the file/folder on their system to make it work.
The fact of the matter is that it wouldn't even necessarily need to increase tuition. The UC system is a $50bn/yr enterprise. Lecturer salaries are a tiny amount, and really only about 20% or so of tuition money right now is directly attributed to instruction costs. If the University worked on a budgeting model that valued instruction, then I think the pay gap could be significantly reduced.
This is true, but it also sucks if we assume "part of a career path". That means there's virtually no teaching-focus career paths in the UC system which is terrible for basically everyone. (Students as well as other faculty.)
In reality, there's spots where it very well could be a career path but it's incredibly difficult to make it work in CS. (And in many many other fields too!)
Yeah, this is largely true. Teaching-focused career paths in California Higher-Ed would be at Cal State or the Community Colleges. UC is about research, and expects all faculty to focus on research, although there are some continuing lecturer positions here and there.
That's really not quite true. There are thousands of lecturers in the UC system, and many thousands more where it is a career choice. Because tenure track is simply just not possible at many places, especially if you want to teach and do not want to do, or do not have a research background. The UC system especially has a career progression for lecturers, though it is somewhat challenging to make it through.
The salary is as high as it is in part due to the Union -- but the UC starting salary for lecturers regardless of discipline and location is around $60K. But computer science is in a roughly better position because a few tenured faculty advocated for higher wages so they could actually make hires. Still multiple people are leaving because the workload/stress/salary are out of alignment.
"Entry level" is tough to define. Perhaps entry level for Berkeley, but these are positions which still require an advanced degree and a good bit of teaching experience.
I'll mention: implicit returns, return if, and safe navigation, the &. operator. Ruby's newer pattern matching features are really cool[1], especially for things like JSON structures, but I've only use started using them. Classes are also super easy to extend.
Many of these things are also incredibly easy to abuse - but they have their places.
[1]: https://docs.ruby-lang.org/en/3.0/syntax/pattern_matching_rd...