The short version is that a regular corporation is required to operate in a way that maximizes shareholder profits; whereas a public benefit corp is allowed to take other factors into consideration too.
I like what you're doing. I was heavily involved in building DigitalOcean and thought often about a lot of what you're working on. Good luck, I think you're doing great work. =)
The language has "unique" types, meaning they have their own semantic meaning apart from their structure; they get a unique hash (currently implemented by adding a random salt to the hash of the structure, though it might as well be a guid). So "unique" types and "structural" types.
It produces a name conflict, but (unlike git merge conflicts) these don't prevent any previously written code from running normally. A name conflict only needs to be resolved as a convenience to the next person to try calling the function by that name, and even that next person might not have trouble if the two new functions with the same name have different types. The person just calls the one they mean, and the type-checker uses the one with the type that fits.
This is definitely an issue that is real, and is currently a problem, and that we will fix; probably by giving the function author an option to salt the hash of new definitions that have some semantic meaning beyond their implementations (appropriate for most application/business logic). No salt for definitions whose meanings are defined by their implementations (appropriate for most generic "library" functions like `List.map`).
We already make this distinction for data types, but not yet for value/function definitions.
Why not simply record where each reference occurs and ensure that if one definition is modified, the other is not? The programmer shouldn't have to think about salting any hashes, it should be automatic and hidden under the hood.
Not only do they have to provide a salt themselves but on top of that, they need to make a judgment call of when something has "more semantic meaning beyond their implementation" (to use your words) rather than being some more "fundamental" code.
I'm also surprised that you haven't solved this problem yet: at least once a day, IDEA warns me that some portion of my code is duplicated exactly in some other area of my code, so this kind of duplicated logic is already quite common.
Is there a fundamental limitation that would make it impossible to use a haskell-style coherent typeclass system, where the instance of a typeclass must be globally unique?
My guess is yes, since that would probably forbid modifying the instance, since we would now have both the new and old copy. Unless of course we couple type class instances with the definition of the type itself (or the definition of the class) and view the type together with all its instances as a unit (as Unison does with mutually recursive functions), but that would bring on its own set of issues.
Yeah, phone syncing is not a critical task. Alternative: Finder is currently syncing your phone and you click “Cancel Reboot” for the next 10 seconds if you want. Otherwise your phone sync will be canceled, your computer will restart, and you can restart the phone sync later.
Whatever gobbledygook you’re writing to specify how your system works, a programming language is better than a markup file.