3 ms·

Alternatively, we could use a model in which functions are immutable, and therefore make such breaking changes impossible. This is the approach taken by Unison:

Alternatively, we could use a model in which functions are immutable, and therefore make such breaking changes impossible. This is the approach taken by Unison: https://www.unison-lang.org/docs/the-big-idea/ https://www.unison-lang.org/docs/the-big-idea/

naasking 1y ago
This also has issues with security fixes, unfortunately.
- lolinder 1y ago
  How so? You can always deprecate the old functions and encourage people to use the new ones, it just doesn't automatically force everyone to do so immediately by breaking their compilation.
  - jcelerier 1y ago
    but that's the crux of the issue: some people think that if software is insecure, it is better for it to be actually unuseably broken. see for instance how many valid usecases of software that "spies" on global key input are broken by X11 -> wayland for the sake of better security: stuff like autohotkey, global recording in apps like OBS Studio, global key displays, yaquake-style terminals..
    - ssivark 1y ago
      Why is it a good model to allow some software engineer "at a distance" to enforce whether some downstream user must drop every other priority and upgrade? I agree that attitudes towards security are generally very poor, but breaking working infrastructure sounds like a crazy practice. Like any sensible system, a good/robust design should allow staged upgrades / hot reloading for anything but a very tiny core of critical functionality. Erlang/BEAM is a great example; it just requires software engineering to adopt a different mindset.
      - naasking 1y ago
        > I agree that attitudes towards security are generally very poor, but breaking working infrastructure sounds like a crazy practice. Yes, breaking infrastructure is bad. But letting already broken infrastructure continue can be worse. The point is that we want a better way to detect when breaking changes happen so that security fixes can be applied without breaking anything, while permitting optional upgrades on our own schedule for other features. There doesn't seem to be a great solution yet, it's either "it never breaks but you're possibly vulnerable to security issues that can't be easily patched", or "things can break at any time due to updates so we have to manually verify this doesn't happen".
        TeMPOraL 1y ago
        Yeah, though 'jcelerier brought up a case where "insecure" behavior is a feature, and the more "secure" design is directly incompatible with it. These cases of breakage can't easily be solved though better coding, and are not random mistakes - there's a fundamental incompatibility that needs to be resolved.
        naasking 1y ago
        > Yeah, though 'jcelerier brought up a case where "insecure" behavior is a feature, and the more "secure" design is directly incompatible with it I don't think it's fundamentally incompatible with a secure design though, you just need to reify the authority to do those things so you can explicitly grant them to specific programs as appropriate.
        jcelerier 1y ago
        this is how you end up with the living hell that are Android and iOS
        naasking 1y ago
        That seems a little melodramatic, particularly since your only other options are that every untrusted program can access every authority like capturing every keystroke, or all programs are effectively neutered.
theamk 1y ago
I've read about Unison a lot, and while "remote execution" idea sounds extremely cool, all of other properties seem very dubious. For example re "no breaking changes": - Imagine that in my project, I have a "FOO" function, which is called by many others - I've decide to change type of one parameter of FOO function. This would be a breaking change in regular language, but in Unison, nothing breaks - I push the new definition, but every caller is still using old version. - New callers come up, and they use new version. So far so good. - Some times later, I've discovered a critical business-logic bug in FOO function! So I fix it, and I have to update all the callers to use the latest version... except for half of them I can not, because the parameter types do not match. Seems like I cannot ship the fix to the customer until I spend a bunch of time rewriting the existing code to accommodate argument type change. As long as there are functions, there are always some kinds changes to them that require one to fix up the callers. How this is enforced can be different - in strictly typed languages, code may fail to compile; in dynamic languages, you may see runtime failures; and in Unison, things will work until you try to edit the caller, at which case it'll fail to compile (unison docs call that operation, converting from text to internal language's representation, "typecheck"). I am not convinced that the "postpone failure until you edit the caller" is the best approach here. When I refactor, I normally want to see any problems surface right away, while I still have the context for the change.

naasking 1y ago

This also has issues with security fixes, unfortunately.

lolinder 1y ago
How so? You can always deprecate the old functions and encourage people to use the new ones, it just doesn't automatically force everyone to do so immediately by breaking their compilation.
- jcelerier 1y ago
  but that's the crux of the issue: some people think that if software is insecure, it is better for it to be actually unuseably broken. see for instance how many valid usecases of software that "spies" on global key input are broken by X11 -> wayland for the sake of better security: stuff like autohotkey, global recording in apps like OBS Studio, global key displays, yaquake-style terminals..
  - ssivark 1y ago
    Why is it a good model to allow some software engineer "at a distance" to enforce whether some downstream user must drop every other priority and upgrade? I agree that attitudes towards security are generally very poor, but breaking working infrastructure sounds like a crazy practice. Like any sensible system, a good/robust design should allow staged upgrades / hot reloading for anything but a very tiny core of critical functionality. Erlang/BEAM is a great example; it just requires software engineering to adopt a different mindset.
    - naasking 1y ago
      > I agree that attitudes towards security are generally very poor, but breaking working infrastructure sounds like a crazy practice. Yes, breaking infrastructure is bad. But letting already broken infrastructure continue can be worse. The point is that we want a better way to detect when breaking changes happen so that security fixes can be applied without breaking anything, while permitting optional upgrades on our own schedule for other features. There doesn't seem to be a great solution yet, it's either "it never breaks but you're possibly vulnerable to security issues that can't be easily patched", or "things can break at any time due to updates so we have to manually verify this doesn't happen".
      - TeMPOraL 1y ago
        Yeah, though 'jcelerier brought up a case where "insecure" behavior is a feature, and the more "secure" design is directly incompatible with it. These cases of breakage can't easily be solved though better coding, and are not random mistakes - there's a fundamental incompatibility that needs to be resolved.
        naasking 1y ago
        > Yeah, though 'jcelerier brought up a case where "insecure" behavior is a feature, and the more "secure" design is directly incompatible with it I don't think it's fundamentally incompatible with a secure design though, you just need to reify the authority to do those things so you can explicitly grant them to specific programs as appropriate.
        jcelerier 1y ago
        this is how you end up with the living hell that are Android and iOS
        naasking 1y ago
        That seems a little melodramatic, particularly since your only other options are that every untrusted program can access every authority like capturing every keystroke, or all programs are effectively neutered.

theamk 1y ago

I've read about Unison a lot, and while "remote execution" idea sounds extremely cool, all of other properties seem very dubious. For example re "no breaking changes": - Imagine that in my project, I have a "FOO" function, which is called by many others - I've decide to change type of one parameter of FOO function. This would be a breaking change in regular language, but in Unison, nothing breaks - I push the new definition, but every caller is still using old version. - New callers come up, and they use new version. So far so good. - Some times later, I've discovered a critical business-logic bug in FOO function! So I fix it, and I have to update all the callers to use the latest version... except for half of them I can not, because the parameter types do not match. Seems like I cannot ship the fix to the customer until I spend a bunch of time rewriting the existing code to accommodate argument type change. As long as there are functions, there are always some kinds changes to them that require one to fix up the callers. How this is enforced can be different - in strictly typed languages, code may fail to compile; in dynamic languages, you may see runtime failures; and in Unison, things will work until you try to edit the caller, at which case it'll fail to compile (unison docs call that operation, converting from text to internal language's representation, "typecheck"). I am not convinced that the "postpone failure until you edit the caller" is the best approach here. When I refactor, I normally want to see any problems surface right away, while I still have the context for the change.