They seem exactly the same to me: when a variable is assigned a value, it’s equal to that value now.

Yeah it's confusing because in maths they are the same and use the same symbol but they are 100% not the same in programming, yet they confusingly used the same symbol. In fact they even used the mathematical equality symbol (=) for the thing that is least like equality (i.e. assignment).

To be fair not all languages made that mistake. There are a fair few where assignment is like

x := 20

Or

x <- 20

which is probably the most logical option because it really conveys the "store 20 in x" meaning.

Anyway on to your actual question... They definitely aren't the same in programming. Probably the simplest way to think of it is that assignment is a command: make these things equal! and equality is a question: are these things equal?

So for example equality will never mutate it's arguments. x == y will never change x or y because you're just asking "are they equal?". The value of that equality expression is a bool (true or false) so you can do something like:

a = (x == y)

x == y asks if they are equal and becomes a bool with the answer, and then the = stores that answer inside a.

In contrast = always mutates something. You can do this:

a = 3
a = 4
print(a)

And it will print 4. If you do this:

a = 3
a == 4
print(a)

It will (if the language doesn't complain at you for this mistake) print 3 because the == doesn't actually change a.

Kind of worthless video. Just speculates about how it works. They don't ever even show the app working!

These glasses aren't even AR so the idea that they can overlay details as shown in the mockups is impossible.

Yes because you used static type annotations. This thread was about code that doesn't use static types (or static type annotations/hints).

What language are your apps written in? Generally the best options are:

1. Qt (C++) or PyQt (Python wrapper if you hate yourself). Old school desktop GUI. Works extremely well though.
2. Web based, then you can pick from a gazillion frameworks, most popular is React. You generally have a Typescript based frontend and a backend in whatever language you want. The downside is you have to deal with the frontend/backend communication which can be a pain.

There's also Flutter which is pretty nice, but again you have to use Dart for the GUI so if the rest of your app is in another language you'll have some friction.

But yeah, I would say the language you want to write your "business logic" in is the biggest factor to choosing. Also if you care about exposing your app over the web.

That appears to not support comments. How they made that mistake after JSON is a mystery.

Make sense. Firmware is also extra difficult to debug so it's nice to use a language that significantly reduces the amount of debugging you need to do.

I haven't used one, but my guess would be they're fine if you're a "web browsing and email" sort, but most of us here probably aren't, and then you're going to have pain when you need to install some tool that expects to be installed globally, because so many pieces of open source software assume the "spew files all over /usr" installation method.

Feels like you'd be spending a lot of time fighting expectations in the same way that Nix has to.

OMG they finally noticed how bad the REPL is. It's it going to let you paste indented code now?

That's not really true. C# and Java are reference-based, uses GC and can be multithreaded, and are very comparable to Rust/C++/C performance. Certainly no more than twice as bad. Whereas Python is probably 50x as bad.

The real answer is that Python developers have deliberately avoided worrying about performance when designing the language, until maybe 2 years ago. That means it has ended up being extremely dynamic and difficult to optimise, and the CPython implementation itself has also not focused on performance so it isn't fast.

But I agree the aim of offering C/C++ speed is never going to be met with Python syntax.

What would you use instead?

I've been working on some OCaml code recently. It's a quite elegant language but it has two or three big flaws that really make me not want to write it.

1. OPAM is buggy as hell. There's one piece of OCaml software that we use at work and literally everyone that tried to build it had problems due to OPAM. One was that it couldn't find zip if you are in more than 32 groups!? I don't even want to think about the kind of code that could lead to that bug. And this is on Linux! Have you tried installing OCaml on Windows? Yeesh.

2. Global type inference means loads of types are inferred as generics, which means you give up a lot of the utility of static typing. Yes you can add explicit types, but the code I'm working on doesn't have them. Rust was 100% right to require explicit types on functions.

3. The syntax is pretty awful in my opinion. Yeah I guess it looks elegant and I'm sure whoever came up with it was very proud, but honestly maybe 40% of my time fighting OCaml has been spent figuring out where to place the damn brackets and semicolons. It's extremely unforgiving too. E.g. if you put an extra semicolon on a top level let where you weren't meant to it can sometimes be "valid" but it pulls the rest of the file into an inner scope, which means the compiler gives you a valid but wrong fix suggestion. Languages using curly brackets don't have this issue at all.

The lack of brackets for function calls can also make it difficult to work out what's going on because you have another operator precedence to remember. Have trouble remembering which is higher precedence out of & and ==? Well now we've thrown calling functions into the mix for you to forget too!

Finally the functional focus can lead to mega-expressions that are very hard to follow, especially when combined with the lack of brackets it can end up looking like word soup.

OCaml has a ton of really nice ideas but I'm glad it's just inspiration for better languages (e.g. Rust) rather than actually popular. I mean... it's still a million miles better than Python... But that's a low bar.

Even if "isn't that bad" were true, it's hardly a stunning endorsement. I wish Linux aimed higher than "not that bad", but it always seems to hit "only some bits are broken".