Short-run programs are even easier. You just never deallocate and then exit(0).

Doesn't this techically happen with most of the modern allocators? They do a lot of work to avoid having to request new memory from the kernel as much as possible.

Like, every ~thousand malloc calls invoked (s)brk and that was it.

> Short-run programs are even easier. You just never deallocate and then exit(0).

What's special about "short-run"? If you deallocate only once, presumably just before you exit, then why do it at all?

Pretending that identifying stakeholders' needs, communicating the solutions, and delivering them are the keys to succeeding in corporate politics is a joke. It's our parent's telling us that we need to be good for Santa Claus. Human politics is an enormously deep subject, and a newbie will get trampled every single time. If you are sitting at a poker table and don't know who the sucker is within five minutes, congratulations, you are that sucker.

I don't think that's actually true. Identifying the stakeholders' needs is absolutely something that will lead to success in corporate politics. Just don't expect their needs to be about building decent products.

The majority of marriages end in divorce. This doesn't mean that I should treat all prospective partners as someone I will eventually divorce. That is not healthy for me, the people I interact with, or my future.

This unhappiness that your wife has will not go away and you will deal with situation at some point. These hard conversations have a way of finding you.

I won't tell you to tear up the pre-nup, but I highly recommend coming up with a compromise (over time) that meets both of your needs.

My man, all of us would. I talk to my wife often about this. We are just built differently and that is what makes the opposite sex so attractive tbh. That irrationality comes out in different positive ways I'm sure (or you wouldn't have married), you can't just turn it on and off (unfortunately)

Did you tell here beforehand (earlier in relationship) you wanted a prenup, or only after proposal?

You should be aware that it's a possibility and act accordingly. Pretending divorce is impossible is what's unhealthy; preparing for the possibility will make for a healthier marriage and a better future, whether you ultimately divorce or not.

This is pedantic, but if I understand correctly, this is not true anymore. Moreover, this number is inflated by a set of people getting divorced multiple times.

I work at a big company. There are parts that are nepotistic and there are parts less so. I just utilize the parts that work.

It’s like a restaurant that has bad food. Do I avoid the restaurant? No I still go and get the 1 good dish.

Why would I deprive myself because the restaurant doesn’t tick every box? On the other hand, why would I go in ever thinking it’s a good restaurant?

In this case that means being in that golf game or figuring out a way how you can use corruption to get good outcomes done.

Or, more likely if your moral compass is sound, quit and find an organisation that isn’t like this.

While I agree with you that random corporate world does behave this way, companies where founders are still around - don’t - because they’re mission driven.

The social will for having real accountability and professional ethics just isn't there. If you license software, large companies will just outsource the stamps to small contractors who will legally assume responsibility while nothing else changes. All real accountability will be so sparse and random that all ethical complaints will be ignored. If this liability becomes large enough to effect anything, all tech companies will band together to bribe politicians to limit legal remedies in the laws themselves.

In the end, the only thing that will happen is that large companies will use these regulations to bludgeon smaller competition like they already do.

The really cool optimizations come from compiling TypeScript, or something close to it. You could use types to get enormous gains. Anything without typing gets the default slow JS calls. Interfaces can get reduced to vtables or maybe even straight calls, possibly on structs instead of maps. You could have an Int and Float type that degrade into Number that just sit inside registers.

The main problem is that both TS and V8 are fast-moving, non-standard targets. You could only really do such a project with a big team. Maintaining compatibility would be a job by itself.

As a simple example - TypeScript doesn’t distinguish between integers and floats; they’re all just numbers. So all array accesses need casting. A TypeScript designed to aid static compilation likely would have that distinction.

But the big elephant in the room is TypeScript’s structural subtyping. The nature of this makes it effectively impossible for the compiler to statically determine the physical structure of any non-primitive argument passed into a function. This gives you worse-than-JIT performance on all field access, since JITs can perform dynamic shape analysis.

AssemblyScript (https://www.assemblyscript.org/) is a TypeScript dialect with that distinction

https://makecode.com/language

Microsoft's AOT compiler for MakeCode, via C++.

[1]: https://www.microsoft.com/en-us/research/publication/static-...

This isn't because of `any` either. The type system itself deliberately has holes in it. So any language that uses TypeScript type annotations to generate faster/smaller code is opening itself to miscompiling code and segfaults, etc.

Do you have any examples off the top of your head?

It yields no warnings or errors at compile stage but gives runtime error based on a wrong flow-based type inference. The crux of it is that something can be a Bird (with "fly" function) but can also have any other members, like "swim" because of structural typing (flying is the minimum expected of a Bird). The presence of a spurious "swim" member in the bird causes tsc to infer in a conditional that checks for a "swim" member that the animal must be a Fish or Human, when it is not (it's just a Bird with an unrelated, non-function "swim" member).

    type Fish = { swim: () => void };
    type Bird = { fly: () => void };
    type Human = { swim?: () => void; fly?: () => void };

    function move(animal: Fish | Bird | Human) {
      if ("swim" in animal) {
        // TSC infers wrongly here the presence of "swim" implies animal must be a Fish or Human
        onlyForFishAndHumans(animal); 
      } else {
        animal;
      }
    }

    function onlyForFishAndHumans(animal: Fish | Human) {
      if (animal.swim) {
        animal.swim(); // Error: attempt to call "not-callable".
      }
      // (receives bird which is not a Fish or Human)
    }

    const someObj = { fly: () => {}, swim: "not-callable" };
    const bird: Bird = someObj;

    move(bird);

    // runtime error: [ERR]: animal.swim is not a function

    type Bird = { id: number };
    type Human = { swim?: () => void; id: number };

    function move(animal: Bird | Human) {
        onlyForHumans(animal); 
    }

    function onlyForHumans(swimmer: Human) {
      if (swimmer.swim) {
        swimmer.swim();
      }
    }

    const someObj = { id: 1, swim: "not-callable" };
    move(someObj);

As as workaround you could add a property `type` (either `"bird"` or `"human"`) to both `Bird` and `Human`, then TypeScript would be able to catch it.

For TypeScript, they list an example with `instanceof`:

https://counterexamples.org/polymorphic-union-refinement.htm...

In the playground:

https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABA...

  const foo: string[] = ['foo']
  
  // inferred as string
  // though it is undefined
  const bar = foo[1]

Can you name a single language that is used for high-performance software and whose type system is sound? To speed up the process, note that none of the obvious candidates have sound type systems.

Soundness in all of those languages involves a mixture of compile-time and runtime checks. Most of the safety comes from the static checking, but there are a few places where the compiler defers checking to runtime and inserts checks to ensure that it's not possible to have an expression of type T successfully evaluate to a value that isn't an T.

TypeScript doesn't insert any runtime checks in the places where there are holes in the static checker, so it isn't sound. If it wasn't running on top of a JavaScript VM which is dynamically typed and inserts checks everywhere, it would be entirely possible to segfault, violate memory safety, etc.

    class A {}
    class B1 extends A {}
    class B2 extends A {}
    
    A[] arr = new B1[1];
    arr[0] = new B2();

The dynamic checks in the Java case are are a well-defined and narrowly-targeted part of the language semantics- you get an exception on mismatched array writes, out-of-bounds access, etc., but when an expression produces a value it always matches its type.

TypeScript defers these kinds of type system violations to the underlying JavaScript engine, which makes things work out (sometimes with an exception, but sometimes just proceeding with a value that doesn't match the expression's type) using precisely the dynamism we wanted to get rid of. And this can leak out and cause arbitrarily-far-away parts of the program not to match their types, either.

It's more specific than that; the discussion is about writing an ahead-of-time compiler, which necessarily wouldn't be running on a JavaScript engine. The compiler could just as easily emit code that always throws a runtime exception instead of emitting an equivalent to whatever the JavaScript would do.

Yup. Milner's "can't go wrong", progress and preservation, etc.

> You cannot just reply "well there are a few runtime checks so it's all good."

Sure I can. I really like how Shriram Krishnamurthi describes soundness in Programs and Programming Languages [1]. I can't think of a better definition for soundness than:

"The central result we wish to have for a given type-system is called soundness. It says this. Suppose we are given an expression (or program) e. We type-check it and conclude that its type is t. When we run e, let us say we obtain the value v. Then v will also have type t."

The "we obtain the value v" part is critical. If an expression of type e doesn't produce a value at all (it terminates or throws an exception), then we have also satisfied soundness.

Indeed, note that he also says:

"Any rich enough language has properties that cannot be decided statically (and others that perhaps could be, but the language designer chose to put off until run-time to reduce the burden on the programmer to make programs pass the type-checker). When one of these properties fails—e.g., the array index being within bounds—there is no meaningful type for the program. Thus, implicit in every type soundness theorem is some set of published, permitted exceptions or error conditions that may occur. The developer who uses a type system implicitly signs on to accepting this set."

A term like "soundness" for a programming language should be useful. We could, for example, define "evenality" as a property of programming languages where we say that a language whose built-in atomic types have names that are all an even number of letters has evenality and other languages don't. That's a well-defined concept and we could neatly partition extant languages into whether they have evenality or not. But who cares?

When it comes to soundness, the above definition from PAPL is useful for (at least) two concrete reasons:

1. When a user is reading code, if they see an expression has some type T, they can safely reason that any value the expression evaluates to will have type T and when they are reasoning about code surrounding that expression, they can rely on that fact.

2. Likewise, when a compiler is compiling code, it can safely assume that if an expression has type T, then all subsequent code that depends on the value of that expression can assume it has type T. The compiler can optimize safely and correctly based on that assumption.

Neither of these properties require that all type checks are performed at compile time. If the runtime throws an exception on out of bounds array indices, that still correctly preserves the soundness invariant that the type of an array element access is the type of the array element. The reader might have to think about the fact that the expression could throw. But they don't have to think about it evaluating to the wrong type.

If that's not your definition of soundness and you require a sound language to have zero runtime checks, then I'm not aware of any widely-used language that meets that requirement, nor do I see how it's a particularly useful term.

Note that it's not the case that every language is sound according to the above definition. C, C++, TypeScript, and Dart 1.0 (but not 2.0 and later) are all unsound. In the first two, it's possible to completely reinterpret memory as another type which leads to the majority of software security issues in the world. In the latter two, the only reason that doesn't happen is because the underlying execution environment doesn't rely on the static types of expressions at all.

[1] https://papl.cs.brown.edu/2020/safety-soundness.html#%28part...

Also, I'm not too familiar with JVM bytecode, but if I load i64 in two registers and then perform floating point addition on these registers, does the type system prevent me from compiling/executing the program?

Can you say more about "proven to be sound"? Are you talking about a sound type system?

https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-2.h...

JVM is a stack not register machine and yes the type system will prevent that from running. It will fail verification.

    instructionIsTypeSafe(fadd, Environment, _Offset, NextStackFrame, ExceptionStackFrame) :- 
        validTypeTransition(Environment, [float, float], float, StackFrame, NextStackFrame),
        exceptionStackFrame(StackFrame, ExceptionStackFrame).

https://www.scala-lang.org/api/3.x/docs/blog/2016/02/17/scal...

Suppose you have some interface with fields a and c. If your function takes in an object with that interface and operates on the c field, what you want is to be able to do is compile that function to access c at “the address pointed to by the pointer to the object, plus 8” (assuming 64-bit fields). Your CPU supports such addressing directly.

Because of structural subtyping, you can’t do that. It’s not unrecognized member. But your caller might pass in an object with fields a, b, and c. This is entirely idiomatic. Now c is at offset 16, not 8. Because the physical layout of the object is different, you no longer have a statically known offset to the known field.

Outside of this, you can unify the types. You would take every interface used to access the object and create a new type that has all of the members of both. You can then either create vtables or monomorphize where it is used in calls.

At any point that analysis cannot determine the actual underlying shape, you drop to the default any.

> This gives you worse-than-JIT performance on all field access, since JITs can perform dynamic shape analysis.

We're talking about using types to guide static compilation. Dynamic recompilation is moot.

A compiler might be able to wring some things out of it (I'm skeptical about obviouslynotme's suggestions in a cousin comment, but they seem insistent) or suppress some checks if you're happy with a segfault when someone did a cast...but it's just not a type system like, say, C's, which is more rigid and thus gives the compiler more to work with.

I wonder how much performance gain you expect to achieve. For simple CPU-bounded tasks, C/Rust/etc is roughly three times as fast as v8 and Julia, which compiles full scripts and has good type analysis, is about twice as fast. There is not much room left. C/Rust/etc can be much faster with SIMD, multi-threading and fine control of memory layout but an AOT JS compiler might not gain much from these.

It'd be nice of TS at least allowed for specifying types like integer, allowing some of the newer TS aware runtimes could take advantage of the additional info, even if the main TS->JS compilation just treated `const val: int` the same as `const val: number`.

I wonder if a syntax like

    const counter: Number<int>

    const Integer = {
      [Symbol.customMatcher]: (value) => [Number.parseInt(value)]
    }

    const Integer(counter) = 42.56;
    // counter === 42

    const counter = UInt64(42);

    const counter = BigInt.asUintN(64, 42);

Because JS code can arbitrarily modify a type, any language trying to specify what the outputs of a function can be also has to be Turing complete.

There are of course still plenty of types that TS doesn't bother trying to model, but it does try to cover even funny cases like field names going from kebab-case to camelCase.

Did the site change? Or am I missing something? :)

This will keep happening because people like you will just flippantly continue saying, "It's not my problem." It will become your problem soon. As companies continue ignoring completely screwing a slowly growing percentage of people, that demographic will do what he will likely do next, call his local congressional representative to grab your company by the metaphorical ear.

Internet companies have incredible legal privilege right now. As expected, they are now abusing it as they have grown large enough. I'm glad these companies are filled with people like you because you don't even mask yourself. That is what will make the boot come down faster and harder.

Google still has the content of all of my email. Well, I guess except for the transactional stuff that comes from automated sources.

A startup starts at the bottom. It begs investors, customers, and employees from a position of optimism and humility. The organization enthusiastically changes itself to find a good balance between those three or it dies. As the organization grows, it starts demanding everyone else change for them instead. Google's interviews are an example. Its famous customer service is an example.

Then we get to size and complexity. Thanks to Dunbar's numbers, we know that there are numerical limits to a human's ability to know people. This makes sense. I can know everything about 6 people, most things about 50, and keep track of about 250 well enough. As the organization grows, your ability to know it disappears. You begin making abstractions. Instead of knowing exactly what Susan does, you say she works in X Department, for Y Initiative, doing Z position.

Google is so big that one person can't understand it anymore. The inevitable reduction to a corporate abstraction occurs and then people treat it like the X Company, which is just like Y Company but makes X instead of Y. Short term revenue and expenses are the only measures at the end.

And in this faceless abstraction, the professional parasite class infests and extracts resources and morale. Eventually the C-suite stops fighting it and joins in on it until only the sheer size and momentum of the company keeps it going. Maybe an investor group will come and force a rework of the company, but not before the company is just a shadow of the shadow of its former self.

What makes it impossible?

You might suggest refactoring, which is what companies do too. They create departments, promotion ladders, org charts, and mission statements. The problem is that abstractions leak by design. As your abstractions accumulate and change outside your view, your ability to understand the entirety reduces.

If you have such a code base and you hire people that are not equipped, either through inexperience or capability, of managing that code base that is a resourcing issue.

If your executives cannot understand and control the organization they are tasked with controlling and cultivating, then they should be fired.

Which is basically what this dude is getting at.

And most importantly, humans are more complicated than code. With enough time and knowledge, I can accurately tell you what any piece of code does on a single expression or statement. Humans regularly do things they don't even know for purposes they don't understand.

The same thing regularly happens with smaller companies or code bases. The size exacerbates the issue, but it's not the cause of it.

Which is largely this OP's point regarding the subject of calling out culture rot and a particular executive.

So controls and processes are put in place to ensure no bad outcomes are possible, but this also prevents good, innovative outcomes from sprouting.

Fundamentally, it's a loss of trust that can exist in a smaller organization.

That dude just made the number up.

Everyone demands victims be kind and normal, but that is rarely the case. Kind and normal people stay far away from the boundaries by nature, but the boundaries always shrink when there is no push-back. We need the kooks out there getting tazed so we don't have to.