←back to thread

517 points bkolobara | 2 comments | | HN request time: 0.427s | source
Show context
merdaverse ◴[] No.45043051[source]
Code written below your line gets executed if you don't return early. More breaking news at 8.

Seriously, why would you think that assigning a value would stop your script from executing? Maybe the Typescript example is missing some context, but it seems like such a weird case to present as a "data race".

replies(8): >>45043245 #>>45043339 #>>45043398 #>>45043537 #>>45043876 #>>45046033 #>>45046975 #>>45049155 #
lights0123 ◴[] No.45043339[source]
exit(), execve(), and friends do immediately stop execution—I could understand why you'd think a redirect would as well.
replies(4): >>45043409 #>>45043410 #>>45049020 #>>45049406 #
dvt ◴[] No.45043410[source]
The redirect is an assignment. In no language has a variable assignment ever stopped execution.
replies(6): >>45043422 #>>45043544 #>>45043663 #>>45043805 #>>45047504 #>>45047601 #
JoshTriplett ◴[] No.45043544[source]

    $ python3
    Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class MagicRedirect:
    ...     def __setattr__(self, name, value):
    ...         if name == "href":
    ...             print(f"Redirecting to {value}")
    ...             exit()
    ... 
    >>> location = MagicRedirect()
    >>> location.href = "https://example.org/"
    Redirecting to https://example.org/
    $
replies(1): >>45045418 #
dvt ◴[] No.45045418[source]
You're overloading a setter here. It's cute, I did it in JS as well, but I don't really think it's a counterexample. It would be odd to consider this the norm (per the thought process of the original blog post).
replies(2): >>45045557 #>>45045946 #
rowanG077 ◴[] No.45045557[source]
This is not some weird thing. Here is a run of the mill example where python can have properties settting do anything at all. And it's designed like that.

    import sys
    
    class Foo:
        @property
        def bar(self):
            return 10
            
        @bar.setter
        def bar(self, value):
            print("bye")
            sys.exit()
    
    foo = Foo()
    foo.bar = 10
Or in C# if you disqualify dynamic languages:

    using System;

    class Foo
    {
        public int Bar
        {
            get { return 10; }
            set
            {
                Console.WriteLine("bye.");
                Environment.Exit(0);
            }
        }
    }

    class Program
    {
        static void Main()
        {
            Foo obj = new Foo();
            obj.Bar = 10;
        }
    }

This is not some esoteric thing in a lot of programming languages.
replies(1): >>45046687 #
dvt ◴[] No.45046687[source]
You're also overriding a setter. Maybe I'm going against the grain here, but it's absolutely esoteric. The assignment operator is not supposed to have side-effects, and maybe this is the logician in me, but the implication that we should be aware that weird stuff might be happening when we do `x = 5` is fundamentally bonkers.
replies(4): >>45046718 #>>45047382 #>>45048993 #>>45050028 #
JoshTriplett ◴[] No.45046718[source]
You started with "In no language has a variable assignment ever stopped execution", and now you're saying "The assignment operator is not supposed to have side-effects". location.href is a counterexample, and there are many counterexamples throughout various tools and languages and libraries. Deciding how you think things should work does not affect how things do work, and it's important to understand the latter. (I do agree it's bad practice, but it happens and people do not always fully control the environments they must work with.)

And given that location.href does have a side effect, it's not unreasonable for someone to have assumed that that side effect was immediate rather than asynchronous.

That said, if you don't like working with such languages, that's all the more reason to select languages where that doesn't happen, which comes back to the point made in the article.

replies(1): >>45046819 #
dvt ◴[] No.45046819[source]
> You started with "In no language has a variable assignment ever stopped execution",

The irony is that I'm still technically correct, as literally every example (from C++, to C#, to Python, to JS) have been object property assignments abusing getters and setters—decidedly not variable assignments (except for the UB example).

replies(2): >>45046918 #>>45047457 #
rowanG077 ◴[] No.45046918[source]
The entire discussion is about a property assignment. Which in colloquial usage is also called variable assignment. Which is obvious since nobody corrected you on that. You now trying to do a switcheroo is honestly ridiculous.
replies(1): >>45047059 #
dvt ◴[] No.45047059[source]
The entire discussion is about “=“ doing weird stuff, which in 99.9% of cases it does not do. And my point was that no language, without doing weird stuff (like overloading), does not let “=“ do weird stuff (and thus is pure). The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default.
replies(2): >>45047506 #>>45048333 #
1. scheme271 ◴[] No.45048333[source]
So, with anything that isn't a primitive type (e.g. int, bool, etc), there's a chance that assignment is going to require memory allocation or something similar. If that's the case then there's a chance of bad things happening (e.g. a out of memory error and the program being killed).

More commonly, if you look at things like c++'s unique_ptr, assignment will do a lot of things in the background in order to keep the unique_ptr properties consistent. Rust and other languages probably do similar things with certain types due to semantic guarantees.

replies(1): >>45048505 #
2. eru ◴[] No.45048505[source]
In languages like JavaScript (or Python etc) you can get memory allocation etc even when 'primitives' like int and bool are involved.

Haskell is the same, but for different reasons.