Almost spit out my coffee
HN user
jgavris
They’re trashing our rights!
I was just in the middle of writing something similar above, thanks!
The general approach is to do multiple migrations (add first and make new-code work with both, deploy, remove old-code, then delete old-schema) and this is not specific to Django's ORM in any way, the same goes for any database schema deployment. Take a peek at https://medium.com/@pranavdixit20/zero-downtime-migrations-i... for some ideas.
Of course, ActiveRecord back in 2005.
The Django ORM / migrations are still basically unmatched in happiness factor.
This is essentially how some fixed wireless providers (like Starry) deliver the last mile (twisted pair).
I still feel like Swift 5 (5.2?) was the sweet spot. Right now there are just way too many keywords, making C++ look easy again.
Similarly, I find Combine / GCD code far easier to write and read and understand, and the semantics are better than structured concurrency. I have plenty of production Combine code in use by (hundreds of) millions of people and it hasn't needed to be touched in years.
Git ‘remotes’ can have rules (hooks that run on push, and decline).
GitHub has ‘branch protection’ which prevents various changes. But GitHub is not Git. A common misconception lately due to its popularity.
Git itself is nothing more than a set of tools to manage the versions of a repository. How you choose to use it is up to you, and what you allow.
Solo developer? Rebase, or don’t.
Do you collaborate? Maybe consider using a SaaS product like GitHub and setup your rules.
Cyberarmy was pretty fun too
Definitely a fun demo!
It’s practically a requirement…let’s say there was no iOS class when I was in school, but there was an App Store.
Indeed, it’s not out of reach and compute density is higher than the Mac Pro with Minis (even the core i9). M1 / M2 is vastly higher.
I wrote a hacky version of SKIP LOCKED using advisory locks and a recursive CTE before it was released for a job queue. It worked splendidly, along with the transactional semantics of a proper database. I’m surprised more systems don’t realize they need it.
Like a store and forward wifi mesh network? I worked on this in 2008.
Lest we forget DotA was a Warcraft 3 mod to begin with…
Oh how I miss the computer labs with Kidpix, Oregon trail, Mavis Beacon, and maybe later Marathon LAN parties (when the instructor left the room for an hour)...
Even in a private monorepo, Google has tools like Copybara that make it somewhat easy to 'open source' small pieces of it and sync them in and out of a 'public' repo. The benefits of a monorepo and just having to 'git checkout' and your entire environment 'just works' (I'm looking at you, scripting languages and build systems) is not to be taken lightly.
I am fine with applying either OO / FP approaches. This example is a sealed class, it is just my opinion that the OO version reads better. And the added benefit of having the function namespaced / bound to the class for IDE support (autocomplete) and documentation.
Thanks. I'm just wondering why the example didn't show this extension method. It seems more idiomatic to just call it on the receiver instead of passing a parameter.
I'm genuinely curious, and I don't know much about Dart and haven't used it. The comparisons to Kotlin are interesting, especially sealed classes and pattern matching. For this example from the post, is it not possible use an extension method (common practice in Kotlin I've seen and written)?
double calculateArea(Shape shape) => switch (shape) { Square(length: var l) => l * l, Circle(radius: var r) => math.pi * r * r };
Aka:
extension Area on Shape { double calculateArea() { ... } }
Migrating from Java to Kotlin looks nice and easy on the surface (optionals!), but the lack of checked exceptions will absolutely bite you sooner or later if you are consuming Java code. Better carefully read the docs and source of all your transitive Java dependencies.
How big is your Go codebase versus your Rust codebase? Why not rewrite bits in Rust? This is very cool, but seems like a lot of effort and ongoing maintenance.
Eventually you'll be able to use std::expected in C++23!
https://en.cppreference.com/w/cpp/header/expected
Don't throw exceptions, require the caller to handle errors and propagate them up the stack (everything returns an expected) if they cannot be handled. You are forced to model the error domains instead of just throwing an exception and assuming the caller knows to catch it and do something with it.
Java has checked exceptions, but, Kotlin decided to abandon them.
The nice codebases I have worked on stick to the Result<T,E> type in Swift or Kotlin. And thus you are forced to 'translate' errors (exceptions?) as described in Alan Griffith's 'Exceptional Java'.
https://accu.org/journals/overload/10/48/griffiths_406/
"If a checked exception is thrown (to indicate an operation failure) by a method in one package it is not to be propagated by a calling method in a second package. Instead the exception is caught and "translated". Translation converts the exception into: an appropriate return status for the method, a checked exception appropriate to the calling package or an unchecked exception recognised by the system. (Translation to another exception type frequently involves "wrapping".)"
If you can't wait for C++23, there's a single header implementation here.
🆒
Of course, making the right abstractions and library / module / crate boundaries is still very much important to incremental build performance. For 'very large' Rust projects, setting up remote build execution can be hard, but a few of the original Bazel folks at Google are trying to make that easier for folks with EngFlow https://www.engflow.com/
I'm surprised nobody has mentioned trying out using Google's Bazel build system with the Rust rules. Bazel provides relatively straightforward 'remote caching' of build artifacts via Google Cloud Storage or S3.
We run OpenCL on top of Vulkan in a production application on Android, thanks to a project from Google / Codeplay and other contributors https://github.com/google/clspv. SPIR-V can't represent all of OpenCL, but maybe enough for most people's use cases.
I use macOS, but some folks have contributed a linux package / installer. And yeah, I added the v2 of the hook recently which is even faster!
Great post!
I wrote a (fast?) fsmonitor hook in Rust...benchmarked against the reference Perl implementation it's quite a bit faster. On a repo of 130k files, my monitor is able to `git status` in 18 millseconds.