141–150 of 304 posts
It's been a sec since I've used Ruby. How's the typing story? Seems like Sorbet is doing quite well, but are there comprehensive typings for the ecosystem, like TypeScript? Because with ergonomic, comprehensive type checking and a JIT, Ruby might be a tempting option again.
Earlier quoted context omitted.
I used to have that attitude. Then I wrote my first Ruby project as an experiment. That was 17 years ago, and the majority of the code I've written since has been Ruby. What clinched it was that the first Ruby project I wrote involved trying to reimplement a piece of C code we had. It ended up 10% the size with more functionality, and it took me a tiny fraction of the time to write. If you write code the way you writ…
I don't know if I'm just a bad programmer and everyone knows something I don't, but it seems to be the benefits of a strongly typed language are wildly overblown. It's a different way of thinking about building software and it saves you from a few mistakes you could otherwise make, but you'd think I was writing code with a hammer and chisel the way people on HN talk about languages like Ruby. It feels a lot like the…
However, once you have strongly + statically typed languages, you can very often create safe-by-design (tm) APIs, APIs that are simply impossible to misuse (for some definition of misusing). A trivial example (which among industrial languages works only in Rust and perhaps Ada) is a file system API in which the compiler detects that, in some codepaths, you're attempting to try to write to a file after closing it.
Exactly how much value this has for your programming depends on how many invariants you need to guarantee. If you're writing (for instance) a CRUD for non-critical data, that's usually not many. If you're writing a network protocol or a garbage collector, this can save you from worlds of pain. I have had to fix data loss and privacy issues in Firefox that would have been detected years earlier if we had used a strongly-typed language such as TypeScript (which didn't exist at the time) instead of JavaScript for the front-end.
In fact, I wear a large number of scars from fixing Firefox bugs in JavaScript (or C++) code. These days, I prefer strong, static typing. I sleep more soundly :)
But, as usual, we're not in a one-size-fits-all industry. There are developments for which static typing gets in the way of zero-to-deployment.
As usual, tradeoffs everywhere!
Note: Strongly + statically typed languages also typically offer strong support for other forms of static analysis (e.g. model checking, abstract interpretation, etc.) that are considered critical in some industries (e.g. aeronautics – or writing Windows device drivers). But we're getting into something of a niche.
I thought Shopify wanted to migrate to TruffleRuby which would likely give them at least a 2x speedup?
[0]: https://eregon.me/blog/2022/01/06/benchmarking-cruby-mjit-yj... says
Earlier quoted context omitted.
I used to have that attitude. Then I wrote my first Ruby project as an experiment. That was 17 years ago, and the majority of the code I've written since has been Ruby. What clinched it was that the first Ruby project I wrote involved trying to reimplement a piece of C code we had. It ended up 10% the size with more functionality, and it took me a tiny fraction of the time to write. If you write code the way you writ…
I don't know if I'm just a bad programmer and everyone knows something I don't, but it seems to be the benefits of a strongly typed language are wildly overblown. It's a different way of thinking about building software and it saves you from a few mistakes you could otherwise make, but you'd think I was writing code with a hammer and chisel the way people on HN talk about languages like Ruby. It feels a lot like the…
For anyone thinking Ruby is dying or slow, it's not the reason people like me used it and sticked with it in first place! It's about the experience when you write the code itself. It's natural, like a flow of water, and you're suddenly in Zen mode, where your thought just naturally flow without even you're aware or not. I first time learn Ruby from zero to "hero" in production confidently is in just under a week. And…
https://survey.stackoverflow.co/2022/#technology-most-loved-...
Earlier quoted context omitted.
It's not like strong typing came after Ruby. In fact, duck typing was a _feature_ of Ruby on its days. At the end of the day, you choose your battles, it's not a black-or-white decision.
No, but gradual/optional typing did come after Ruby. Back in 2005, you could choose between static typing with type checking but lots of verbosity (e.g. Java "Point point = new Point();" or C++ "for (std::map ::iterator it = myMap.begin(); it != myMap.end(); it++)") or dynamic typing without type checking but also without the verbosity. Since optional typing, dynamically typed languages got the guarantees of type che…
But in truth, you're right. Very few people know/cared about type inference at the time.
Earlier quoted context omitted.
No, but gradual/optional typing did come after Ruby. Back in 2005, you could choose between static typing with type checking but lots of verbosity (e.g. Java "Point point = new Point();" or C++ "for (std::map ::iterator it = myMap.begin(); it != myMap.end(); it++)") or dynamic typing without type checking but also without the verbosity. Since optional typing, dynamically typed languages got the guarantees of type che…
>"for (std::map ::iterator it = myMap.begin(); it != myMap.end(); it++)")" All you really needed is: for (auto it : myMap) and you still get compile type safety
Earlier quoted context omitted.
The main issue I have with Ruby / Python is the fact that it's duck typed, it makes the maintenance and refactor pretty hazardous. You get objects you don't know what's in there, 6 month later someone changed it, no compile error but it will break when you run it. And so to overcome those major issues they added really ugly stuff that is not core to the language, linters, annotations etc ...
Python now has an optional type system and if you add one of them such as mypy or pyre to your CI process and you can configure GitHub to refuse the pull request until types are added you can make it somewhat strongly typed. If you have a preexisting codebase I believe the way you can convert it is to add the types that you know on commits and eventually you will have enough types that adding the missing ones should…
YMMV
Earlier quoted context omitted.
The point is that compilation automates all this. It's just one more failure point you have to devote man hours to.
Compilation won't tell you whether your code follows the business logic it's intended to do. You do need to rely on tests even if the implementation of the programming language compiles it or not.
Unfortunately, most people got a taste of static typing with Java and the initial language and library design were done in such a way that types were well, if not entirely useless, then certainly under-used. But if you look at many libraries for languages such as Rust, Scala, OCaml, Haskell, F#, ... (I haven't looked at Java in a while, but I don't hold high hopes on this specific front) you'll find many examples in which the API and the type system cooperate to guarantee that high-level protocols are enforced.
That being said, I absolutely agree that strong static typing does not mean that you don't need tests. As everything, if you want to be safe, you need a defense in depth, with good API design and many test layers.