> With a reference counting GC, you're essentially emulating "perfect" use of C++ unique_ptr.
Did you mean shared_ptr? With unique_ptr there's no reference-counting overhead at all. When the reference count is atomic (as it must be in the general case), it can have a significant and measurable impact on performance.
You might be right. Though with the way I design software, I'm rarely passing managed objects via moves to unrelated scopes. So usually the scope that calls the destructor is my original initializing scope. It's a very functional, pyramidal program style.
> With respect to the income tax, it is possible for higher earning (not by US standards) employees to receive a bonus and actually take home less money than before they received the bonus.
What are you referring to here? Higher rates of income tax are only taken on the money earned over the band. So If you earn £50,271, you pay 20% on £50,270 and 40% on £1.
As well as the childcare benefit removal others have mentioned, you also begin losing your "tax free allowance".
The marginal tax rate for 100k -> 125k is 60% (due to losing the ~£12k tax free allowance)
"Your personal allowance goes down by £1 for every £2 that your adjusted net income is above £100,000. This means your allowance is zero if your income is £125,140 or above."
there are benefits such as child tax credits which are not tapered. You either get the full benefit if earning £99,999 a year, or nothing at £100,000. This benefit if you have children can be worth tens of thousands of pounds, thus resulting in a net loss. If you look at income data after tax this causes a weird drop in take home pay in the roughly 100-130k range, where people just salary sacrifice all their extra pay to make sure they are under 100k. This is not productive to the economy.
I think if this were the case, we would have quickly moved on from storing source code as text, and begun storing it as ASTs which could be 'viewed' in any localised version of the programming language. This may have had wider benefits than just reading source code in your preferred language.
You can serialize ASTs very easily as S-expressions, or slightly fancier versions thereof. That's still "text" and quite easily readable by humans, but somewhat less oriented to direct editing.
There's a talk from Lustre's developer about doing LiveView-type things with Gleam/Lustre. The promise is that you can easily pick and choose which parts of your app run on the client, and which run on the server.
> The inspector is menu driven, and you can always see the available options by typing "?." For the most part, the options are self-explanatory.
I've enjoyed using Chez Scheme a lot, but I never could get my head around its built-in debugger. I never remember where to go to just view a stack trace, and if I do find it, I end up confused when I try to navigate around it.
I suspect all the information I could possibly want is in there, but I don't find the interface at all intuitive.
The OTP package is not built-in because that would prevent Gleam being compiled to other targets, namely Javascript. This is a big draw for the language, and it's worth pulling out BEAM-specific stuff into packages for this reason.
I think Louis and the Gleam community are very serious about supporting OTP, but there are still open research questions around typing parts of OTP.
The parts of OTP that Gleam supports are still very useful, compatible with Erlang/Elixir, and very much used. And they have the benefit of being statically typed [1].
There's no embarrasement about Gleam's primary runtime being the BEAM, it's right there on the front page, above the fold! [2]
Yeah, but at that point is the company that developed the superintellegence really relevant any more? Doesn't the superintellegence take over and capture all the value for itself? If the concept of 'value' even has the same meaning any more. In truth at that point the foundations of our economic system have been profoundly reconfigured. Your VC investments may be completely irrelevant.
Depends on whether it's a fast or slow takeoff and the control problem. Both are open questions.
Personally I think we're in the midst of a slow take-off because AI researchers and IT support for them are all using AI. That gives companies plenty of time to get a wild valuation from having a baby superintelligence.
Testing something is the best way to prove that it behaves correctly in all the cases you can think of. Relying on your own (fallible) understanding is dangerous.
Of course, there may be cases you didn't think of where it behaves incorrectly. But if that's true, you're just as likely to forget those cases when studying the expression to see "what it actually says". If you have tests, fixing a broken case (once you discover it) is easy to do without breaking the existing cases you care about.
So for me, getting an AI to write a regex, and writing some tests for it (possibly with AI help) is a reasonable way to work.
I don’t believe this is true. That’s why we do mathematical proofs, instead of only testing all the cases one can think of. It’s important to sanity-check one’s understanding with tests, but mere black-box testing is no substitute for the understanding.
in theory theory and practice are the same, in practice not really
in the context of regex, you have to know which dialect and programming language version of regex you’re targeting for example. its not really universal how all libs/languages works
> It's fun to nerd out about memory allocators, but that's not contributing to overall improvements of software engineering as a craft which is still too much ad hoc hacking and hoping for the best.
I'm sorry, but it is. Understanding memory layout and (sometimes) using custom allocators can improve performance in ways that no compiler cannot do automatically. And when used correctly they contribute to code correctness too. This is the reason they are used in projects like Chromium.
Regarding your car analogy, you have to remember that developers here are not driving the car: they're building the car. Understanding the differences between and ICE engine and an electric motor are very salient to designing a good car.
> But what do those functions return? Oh look, it's DOM nodes, which are described by and implemented with inheritance.
Well of course. React builds on what the browser provides. And the DOM has been defined as a class hierarchy since forever. But react components don’t inherit from one another. If the react devs could reinvent the DOM, I think it would look very different than it looks today.
Did you mean shared_ptr? With unique_ptr there's no reference-counting overhead at all. When the reference count is atomic (as it must be in the general case), it can have a significant and measurable impact on performance.