So I think memory safety does matter in that case.

Algebra

Geometry

Probability

Analysis

Dynamics

I loved this talk, but these concepts are like an attempt at dimensional reduction of math research, science, the academics knowledge.

I would have loved to have his thoughts on the mathematical mind, the process, how to reason, infer vs deduct, abstract, prove..

I don’t really know, what are the primitives, essential concepts of math reasoning?

If you are interested in Terence Tao's personal mathematical inner world, he touches on that during his interview with Lex Friedman, which I think you might find interesting. Interviews with Kevin Buzzard sometimes touch on these themes too.

Disclaimer: I built this tool a couple of weeks back.

Making it about numbers is like making it about cans when it's more about grasping adding one can to a bag of cans, adding 100 cans (multiplication), or the inverse with subtraction and division

Which is why I never liked numbers before algebra which then chucks numbers in the bin more or less.

Numbers are just syntax meant to represent $anything; 1.5 can be half a pill and a whole pill or T or A; numbers are euphemism.

That they can be infinitely big and yadda yadda isn't that meaningful in and of itself and that little bigness is all due to additive qualities of physical space

Geometry is addition or subtraction of shape

It's all built on 4 operations we see in daily life all the time

Numerals are syntax; numbers are mathematical objects. “5”, “V”, “101₂”, and “|||||” are different representations of the same number. A variable such as x is closer to what the statement means by something that can stand for arbitrary things.

> It’s all built on four operations

Elementary arithmetic emphasizes +,-,×,÷, but mathematics isn’t reducible to them. Mathematics studies operations and relations such as composition, exponentiation, differentiation, integration, limits, logical implication, set membership, mappings, probability, topology, symmetry, transformations, equivalence relations, and many others.

From a previous HN discussion of Terence Tao's Six Math essentials book (to be published) my comments pointing to a similar book by John Stillwell (covers Arithmetic, Computation, Algebra, Geometry, Calculus, Combinatorics, Probability, Logic) - https://news.ycombinator.com/item?id=47116399

Broadly yes, but summarization can simultaneously be compression of data and revelation of structure, hence increasing understanding.

i'm sure you could come up with another breakdown, but these also have the benefit of tracking roughly with history. numbers and geometry (euclid), then eventually algebra. probability was a fundamentally new way of looking at the world. analysis comes via newton/leibniz and then dynamics tries to tackle complex systems (kinda where newton left off, e.g., 3-body problem type stuff).

also: dimension reduction is not a bad thing. this is like a decomposition: we can decompose so much of what research mathematics is doing into 6 different basis elements. that's pretty darn neat.

(edit: liebnitz -> leibniz)

I personally think that a lot of the words used around AI, harness, SKILLS, agents, RAG.. are make up words or close to it, words that do not have profound semantics, even though people are trying to, often after the fact, make sense of them.

It’s just popular words that are different enough that people like to use them to claim a new knowledge, or to market a product.

But we could use AI tooling instead of harness in the abstract, and it would be better to use more precise terms for more concrete use cases, agent loop, CLI, IDE..

It was a fun game at a time where papers were competing for attention, but now that it has become a proven technology, I hope we can find more precise and meaningful words.

If you’re program has entered an unknown, failed state, just restart it from a known state.

Even better if you can divide a complex system in sub modules that can recover independently without bringing down the entire system.

Something like Erlang supervision tree. Or at least a systemd Restart=always service.

if your program is mostly stateless, and « restartable », it becomes fault tolerant, and you can use assertions liberally and easily avoid unknown/bad states.

Invariants can be enforced, and correctness preserved. But an important question remains when an assertion is triggered, why invariants were violated?

We need to preserve context, and decide to handle or not this case. That is easy to forget in code that is assertions oriented.

The old solution to that, which worked very well, was coredumps. The assertion fires and your program is taken down, but just before that we save out the entire memory area of your program. That way you can come in with a debugger later and poke around.

People would often leave some memory areas (typically circular buffers) with debug values that would be useful in debugging. They'd never be used anywhere in the program, unless the programmer had to poke around manually.

I've often wished this workflow was still considered high priority on modern runtimes.

> People would often leave some memory areas (typically circular buffers) with debug values that would be useful in debugging. They'd never be used anywhere in the program, unless the programmer had to poke around manually.

In one Linux-based system i worked on, they had an area of memory between the heap and the stack where shared libraries are typically mapped in, sectioned off as a circular buffer via linker scripts for each module which was then used for all sorts of logging. A separate process would also map this memory area to provide a UI and also to write to disk. It was pretty neat and worked great.

I would not have clicked on “How My Images Are Dithered” but this truncated version made it sound more like an interesting bug story.

Bit hard to explain though.

However, the only time where I’m missing code/data reuse through inheritance is with GUI. Some mostly flat hierarchies of widgets are really powerful ways to declare and compose UI components with shared behaviors.

In rust, the DX for GUI components is always lacking compared to web, C#. With maybe the exception of Slint which is really not Rust anymore.

Is there a way to have good DX for GUI components in Rust?

But essentially it comes down to traits, newtypes/enum variants, and macros.

But it’s still really fresh, they are conscious of the issues and I hope bevy maintainers came up with an elegant design

Yes. Rust is not a general purpose language. It's a systems language. Don't use it for GUIs and games and such until somebody has figured out how to do it properly.

To do this in Rust, the closure needs a mutable reference to the button. However, the GUI event loop also needs a reference to the button to draw it on the screen. In Rust, you can have many immutable references, __or__ exactly one mutable reference, but never both at the same time. Since the GUI framework holds the button, it won't let your closure mutably borrow it at the same time.

    use std::rc::Rc;
    use std::cell::RefCell;
    
    struct Button {
        text: String,
        on_click: Option<Rc<dyn Fn()>>,
    }
    
    impl Button {
        fn new(text: &str) -> Self {
            Button { text: text.to_string(), on_click: None }
        }
        fn draw(&self) { println!("[Button: \"{}\"]", self.text); }
        fn fire_click(button: &Rc<RefCell<Button>>) {
            let cb = button.borrow().on_click.clone();
            if let Some(cb) = cb {
                cb();
            }
        }
    }
    
    fn main() {
        let button = Rc::new(RefCell::new(Button::new("Click me")));
        let cb_handle = Rc::clone(&button);
    
        button.borrow_mut().on_click = Some(Rc::new(move || {
            cb_handle.borrow_mut().text = "Clicked!".to_string();
        }));
    
        button.borrow().draw();
        Button::fire_click(&button);
        button.borrow().draw();
    }

  [Button: "Click me"]
  [Button: "Clicked!"]

Many interactive programs can be GetInput(); ChangeState(); DrawState();

Why wouldn't their lifetimes be isolated?

Also the drawing doesn't need a mutable reference.

Usually when people say to prefer composition over inheritance, that does not apply to the inheritance found in GUI, but as an alternative way to share behaviors as a property, « has a » instead of « is a », like has a role instead of being a user, admin..

That do not work well with GUI, where hundreds of of components are reusing common containers, widget behavior, it would be very verbose and painful to always declare common behaviors, data.

I think, React is cheating because it’s based on the web which already provide DOM node components and JavaScript, a GC language where most rust issues do not apply, there is already an underlying composition framework, the problem is that it is not easy to reproduce in rust.

See VB 5 and 6 (when VBX got replaced by COM), and anything WinRT, UWP, WinUI.

The work Microsoft has been doing on windows-rs translates quite good into Rust, unfortunately the team doesn't like using designers.

And there are plenty of ways to manipulate the price, such as issuing a low float to a hyper hyped stock..

Check a config, bdd value, env var to dynamically go one path or the other.

That’s all, you must either have a small feature or refactor the code to easily switch at a high level.

If you are not able to do so easily, then yes, complex feature flags implementations might help you, to coordinate feature activation between micro services.

Or if you have many features then a dashboard might be useful.

But I would argue that both are serious indicators that you should avoid feature flags, they are better for local and temporary changes, otherwise the complexity compounds and it become hard to manage and maintain.

Ofcourse you don't want users to lose the feature once they exceeded your revenue threshold or cross the border so you'll need to implement some kind of tracking. Your analytics and error tracking also needs to communicate with the feature flag service.

Definitely not rocket science but more complex than a environment variable.

That is, features are contractual and when you've only got 50 customers but they're all paying high 6 figures does anyone really care about feature flag complexity?

Not just an argument, it's the entire point of feature flags for ui experiments which is an essential practice. Dynamic adjustment of the cohorts (or even just an immediate kill switch if it's a disaster) is required.

Electron ultimiately sits on native APIs, and has its own performance costs on top of them.

Native GUI dev, tho, can enable low-resource performant apps just by sticking the rudimentary OS is a way no higher app really can, and with capabilities that’d choke a web app. Load up a listbox with a few tens of thousands of items with custom rendering… as a fat client dev you’re only in a little trouble, on the web googlers making google apps force pagination a whole lot.

As a point of comparison: WPF was Microsoft’s attempt to nail the ‘best of the desktop & best of the web’ [And I would argue they effectively nailed it, as a specification.]. But, as a brown belt WPF dev and a blue/orange belt with Win32/MFC, the extra overhead related to WPF broke common scenarios we’d never think twice about on the true native side. The web was made for sharing Robotech technical manuals, OS GUI’s to pump all the rectangles as fast as hardware allows. Apples and oranges.

I was agreeing and providing more context to the costs of building at a higher level, like Electron, and the limits even when applied by a unified vendor with incentives for high performance.