HN user

jgavris

130 karma
Posts2
Comments77
View on HN

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.

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.

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.

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.

https://github.com/TartanLlama/expected

Fast Rust Builds 5 years ago

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 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!