Some Rust libraries have started to implement unioning multiple error types and handling a subset of them while propagating the rest. But as far as I know, the idea hasn't caught on. Here are the crates I know of.
Somebody save Kathy Sierra’s blog! https://headrush.typepad.com/ I’ll try to archive it. I love her work. But even if I save it, it should live on somewhere else.
Pinboard was a clone with a different business model: users actually paid for it.
Fast forward, and delicious died, only to be acquired by — you guessed it — Pinboard [1]. Because Pinboard was actually serving its paying customers, it just kept trucking along.
Yes, I did this at my startup. Fast forward a few years, and now the company has more Rust code than Python, and the majority of the company's IP is in Rust.
I suggest beginning with small, one-off things that don't have much impact. People, even developers, tend to shy away from things that aren't familiar. By introducing Rust in a small, low-risk way, it helps people get familiar with it. They get to build familiarity with building Rust projects, navigating the project structure, and reading docs. I submit pull requests that get people to read Rust code, even if it's just to say "looks good". Their familiarity builds slowly over time, meaning they'll be less triggered by seeing Rust in a larger, more impactful project down the road.
How do you boil a software developer? Slowly.
If they give Rust a chance and your team has a champion to guide them, they'll see its merits. I think a lot of people come to Rust for the performance, but that's not why they stay.
Yeah, this is just baffling. A team can be so averse to learning new tools, good ones too, that they would rather dump their time into rewriting. Instead of getting paid to level up their skills, they'd rather block forward movement of the company's goals to maintain the status quo.
This is simply false. Ruby has first-class functions.
Not only that, it has blocks, which few other languages have. Ruby optimizes for the common use-case of a method that takes a single callback/piece of code, and I miss it in most other languages, including Python.
In Python, the "with" statement is super special. But in Ruby, it's just a method that takes a block. And any method can take a block, not just one per class.
Git isn't designed for "noobs trying to pick up coding just to experiment". It also isn't really designed for solo developers as the OP is about.
Git is designed for collaboration. Git's UI is absolutely unintuitive, especially coming from other version control software. But that's irrelevant. Everyone wants to use it because of the network effect.
In terms of _why_ the UI is unintuitive, I believe it's because it intentionally exposes its internal representation. Unlike its predecessors like subversion, Git has infinite flexibility in terms of the workflow that teams of people can adopt. But the flexibility comes at the cost of learning how to use a distributed graph of commits.
Personally, I never learned git by reading recipes of commands, like the OP. I only really grokked it by understanding how it works internally. This article helped me:
When I was new to Ruby and hadn't learned the available tools yet, I had similar problems because I brought practices from other languages that didn't work.
Typically, what you're describing is solved, in different ways depending on your setup. I literally never think about the issue you're describing when using Ruby.
- With Rails/ActiveSupport in development mode: Module B is autoloaded lazily when C refers to it.
- With Rails/ActiveSupport in production mode: All modules are eagerly loaded at startup.
- Plain Ruby: There's a few ways, but most gems simply have a file at the top level that eagerly requires all files when the gem is required. Same with an app.
If startup time becomes an issue, you can configure the autoloading at the top level, and the appropriate file will be required lazily when it's referred to. But at that point, just use ActiveSupport.
This is simply false. Ruby modules are first class. They're objects that you can pass around like any other object. You can put them in a local variable. You can define methods on them. You can do metaprogramming using them. You can build classes by mixing modules together. You can create modules (and classes) at runtime. Many things that need to be built-in in other languages are just a library in Ruby.
Files and modules in Ruby are two distinct things. While Python makes files one-to-one with modules, Ruby allows you to define as many modules as you like in a file, zero or more.
It's true that if you define a constant at the top-level of a file, it uses the global namespace.
By convention, if you have a file named `foo.rb`, you'd write:
module Foo
# Code here
end
and it's equivalent to what's done in Python. But it also has all the other features.
https://github.com/komora-io/terrors
https://github.com/mcmah309/eros