We use Crystal a lot too at Crunchy Bridge. It is used for all of the on-instance programs, the per-region monitoring service, as well as the customer CLI. I'm a big fan of Crystal, and wrote the postgres driver for the language :)
However a main reason we used Ruby was for the production REPL which lets us manage our entire server fleet with like 1/3 of the staff we'd need otherwise.
Amen to that. We reached $2M ARR as 3 engineers at Missive [1]. As the CTO, I can tell life wouldn’t quite be the same without the ability to save the day in the production console at the speed of light.
For the control plane part of Crunchy Bridge, on day one I decided to go with the deleted_records table that is mentioned at the end of this post. It's been great. No need to keep around dead data that no one ever looks at.
We don't need to have `where deleted_at is null` on every single query. But the best part though is our actual working data set of records we actually care about is tiny compared to the deleted cruft that would have otherwise been just sticking around forever. Backups and restores take no time at all. It's really cool that postgres lets you have conditional indexes on things, but it's even cooler not to need them.
Overall sorbet has been good and useful, so thank you. But you just have to be careful when you're not using the same version of ruby that stripe uses. I recently got hit by a bug:
# typed: strict
extend T::Sig
sig {params(x: Integer, y: String).void}
def run(x:, y:)
puts(x + 1, y)
end
args = {
x: 1,
y: "Hi"
}
run args
type checks just fine in sorbet, but is an error in ruby 3+. It works though (with errors) in 2.7 and lower which is what Stripe uses from what I gather.
Note that Shopify is much better about keeping up with regular Ruby updates (Stripe takes a pretty conservative approach there), and they're using it with Ruby 3+ with no problem.
You're right that Sorbet does not yet catch these bugs yet, and we'll likely get around to it in the future. It's being tracked in this issue[1].
We haven't quite prioritized this yet partly because it doesn't actually prevent you from using Sorbet in a Ruby 3 codebase, it just won't report all the errors it could (e.g., Sorbet allows using `T.untyped`, which can also cause runtime errors to go unreported).
Now that you've jogged my memory, there used to be some weirdness in our internal representation for method calls that made implementing this feature tricky. But we've since refactored some internal data structures and now it's probably a lot easier. Maybe I should look into how much work this would be again ...
If there is something like heartbleed that needs to update a common dependency, how does NixOS deal with that? Do you need to rebuild everything that uses that dependency, instead of just changing the shared library on a more traditional os?
Yes, but that's not a problem. In traditional systems the reason to avoid rebuilding everything isn't because it takes time (it does, but not that much time); the reason to avoid rebuilding everything is the fear that, halfway through rebuilding everything, you'll discover that some shared lib is missing, or some crucial toolchain has been uninstalled, or that some updated packages rely on incompatible versions of the same dependency, and it turns into a nightmare of toolchain and dependency resolution, leaving your system in a half-upgraded mess. But if the promise of Nix is true, then that's no longer possible; you rebuild everything, all the dependencies work out fine, and you go on with your day.
It needs one of those things that alerts anyone who tries to right click :) An even better one would be to totally preventDefault oncontextmenu. That'll stop them!
This was probably the funniest yet interesting and technical talk I've seen recently.
Definitely inspired me to think outside the box and look for these fun things!
I'm actually impressed at how incredibly expensive they made this. $0.50 per million 1KB writes, which is 20x what aurora charges, since aurora allows 8KB writes. And Aurora is already expensive if you actually read/write to it.
> $0.50 per million 1KB writes, which is 20x what aurora charges, since aurora allows 8KB writes.
That's a weird comparison. 20x is only true if you write 8KB with every entry, and you haven't included the storage and instance savings.
It's not hard to come up with suboptimal scenarios where this is more expensive, but that's missing the point. It's optimized for a specific kind of usage pattern.
I really don't think it's 20x the cost of Aurora in general, considering that Aurora costs are not that simple, but I don't have time to run the numbers, so let's go with that for a moment. Do you really think Amazon would introduce a product that's 20x as expensive if they didn't know there was a market for it?
"With Timestream, you can easily store and analyze log data for DevOps, sensor data for IoT applications, and industrial telemetry data for equipment maintenance."
They don't get to choose. They don't own the copyright on Redis, Salvatore does. He is their employee now but if they try to pull something like this I suspect he won't be for long.
Based on this interview from 2016 Salvatore
agrees with the issues of BSD and cloud vendors so he may be a lot more amenable to a license change than you suspect: https://venturebeat.com/2016/06/19/redis-creator/
>But now, for the first time, GPL could be interesting again because of the cloud vendors. Because with BSD, cloud vendors are able to extract a lot of value from an open-source project, to the point of making it very hard for the project’s initial creators to make a business out of it. Let’s call it the “AWS problem.” The AWS problem, technically, could be enough in some way to create problems for the whole open-source ecosystem. Now people know that if they start an open-source project and put a lot of effort into it, they could be marginalized by AWS. That could mean that GPL would return again as the primary license for open-source software in the future.
You are right that they are making something new available, but they are not open sourcing it according to the commonly accepted meaning of the term -- and the original article actually says "... any software under this new license is non-open source by definition".
Now you might think that commercial use is a small semantic detail. But it is one that the open source / free software community has always insisted on, up to and including left-loonies like Stallman.
Of course none of this means that it is wrong or unfair of RedisLabs to do this. It merely means that what they are doing is not open sourcing anything.
On one hand I admire RedisLabs for acknowledging what all major cloud vendors are doing... embracing and extending open source packages but not giving back enhancements.
On the other hand, the terms of "commons" are not in the spirit of the license and software they've built their business upon.
If in the end Salvatore Sanfilippo were getting funded by the licensing of commons modules, I'd be less concerned.
Pragmatically, this is still open source software, because the software source is freely available.
It might not be Open Source Software now, perhaps according to some zealots like RMS et al.
> According to the Open Source Initiative (OSI), open source licensing cannot limit the scope of a license – it only applies conditions to exercising it. With this model, no one can stop you from doing whatever you want with the software, whether commercial or non-commercial, or (famously) good or evil. Therefore, the no-sale restriction imposed by Commons Clause means that any software under this new license is non-open source by definition. However, in practice, Commons Clause only adds a limitation concerning fair use, and we believe that both licensing approaches share the same core value of making software available for use by anyone.
> Pragmatically, this is still open source software,
No, it's free of charge shared-source software. The OSI and FSF open source and free software definitions are virtually identical despite their very different philosophy because any less freedom than they call for quickly collapses the benefits of the arrangement.
I'd say GP is correct, but only insofar as that Redis Labs hasn't changed it yet:
> Today, most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis’ permissive BSD open source license allows them to do so legally, but this must be changed.
"He could no longer pay for the personnel, produce and precision that go into charging one-star prices." Apparently the NY Times can no longer pay for the precision that goes into subject-verb agreement.
A bit off topic, but journalism thses days is brimming with minor grammatical errors, such as omissions of articles, repeated ‘the’, etc. It seems no one cares enough to hire rigid proofreaders and the software tends to miss little things. Does anyone care?
I'm sure there's a reason, but I always thought it strange that when the subject in singular, the verb often gets an 's' ending (mirroring the plural ending for most nouns) but when the subject is plural (often ending in an 's') the verb normally doesn't get an 's' ending.
The frogs play in water.
The frog plays in water.
Why does the 's' effectively swap locations?
Why not, "the frogs plays in water." Or "the frog play in water"?
Or why not drops the singular/plural distinction from verbs altogether?
What's interesting to me is that we use the same morphological operation (-s suffix) to express two very different concepts. You see this in other places as well, for example the Germanic -en suffix is used in at least 3 different ways in English: as the past participle verb tense (speak -spoken), as a way to transform adjectives into verbs (wide-widen) and (a very old) way to transform nouns into adjectives (gold-golden).
Why not use different morphology for these different grammatical concepts? The language would be cleaner and more consistent. My theory is that, basically, it's hard to learn to pronounce many different sounds, but it's easy for our brains to sort through the ambiguity that the morphological overlap produces.
It's because that's the way English verbs are conjugated. English actually has a very simple way of conjugating (regular) verbs. Most of the complexity of the ancestral Germanic has been lost. Contrast that to other Germanic languages. Swedish present tense, for example, is very simple. German still retains a complex morphology.
The only inflection English retains in the present indicative is the -s suffix for 3rd person singular (frog). Third person plural (frogs) does not have an -s.
The -s suffix for noun plurals, and for possessives (vestigial genitive case), add exceptions that make learning English a little harder.
What makes you think the -s ending is naturally plural, rather than just being completely arbitrary?
I am pretty sure the etymology of the plural ending -s and the third person present verb ending -s (which used to be -eth in pre-modern forms of English) are unrelated, and they just sound the same by coincidence.
Well at it's core language is sort of completely arbitrary, but that's beside the point I'm making. I'm not debating the origin or why it is the way it is, but simply observing that this is how it is currently and it looks strange and counterintuitive.
I still don't understand what's strange about it. There is nothing inherently plural or singular about "s" or any other combination of sounds.
English evolved a 3rd person singular verb ending. It randomly happened to be "s". It also evolved a plural noun ending. That too randomly happened to be "s". There's nothing deeper going on than that.
I'm not suggesting there's anything deeper nor do I understand why you think I am. I'm just pointing out that as English exists today, an 's' on the end of noun makes it plural while an 's' on the end of a verb makes it singular.
I'm not suggesting plurals be removed from language, merely a different way of representing it. Such as the Indonesian structure you mentioned, I like that.
The amount that people care is measured in dollars. We can likely conclude that the amount that people care is less than the prevailing wage of a professional proofreader.
A publication may one day be able to accumulate those who care the most as their customer base, and thereby assure the production of grammatically correct ephemera, but for now, other business interests prevail.
Please don't take HN threads into such nitpicky weeds, whether you happen to be right or not. In this case I don't think you were—Muphry's Law and all that—but there's nothing wrong with being wrong as such. Far worse on HN is being snarky.
However a main reason we used Ruby was for the production REPL which lets us manage our entire server fleet with like 1/3 of the staff we'd need otherwise.