floitsch

Maybe give Toit (toitlang.org) a try.

We have been working on it for a few years now, and it gets more and more complete. Recently Espressif started contributing as well (and added Toit to their esp-idf installer).

Some selling points of Toit:

* modern language

* very fast execution for a dynamic language. (more than 10x faster than micropython)

* consistent libraries.

Google's business model is absolutely not built around privacy invasion, and their model is built around data collection of public data. If, for some reason, they couldn't use personalized ads anymore, they would simply earn less, but their business model would be the exact same as before.

Mozilla business model is entirely built around their market share. As such, they are in a much more difficult situation than Google's Chrome team. If Mozilla has a difficult time (financially), they are more likely to do shady things than the Chrome team which has no such pressure. For example, the Chrome team would never accept any cryptocurrency deal; something that I have no difficulties imaging Mozilla to do.

Obviously, Chrome will not actively hurt Google's other businesses (specifically ads), but Chrome's primary goal is to make the web a better place. The worst case scenario for Google is that the web (and thus their revenue stream) disappears.

Machine shop work - Blondihacks: https://www.youtube.com/@Blondihacks

I'm not the author, but I know him personally. I will make sure he reads this message.

That's probably on me...

If I had to do it again, I would make it stable now.

I have worked at Google (although in a different department). From what I could see there was never intentional hurting of other browsers. However, given a list of (always too long) TODOs, improving a non-critical feature for 10% of users often just doesn't make it to the top.

And yes, Google is a huge company with a ton of developers, but teams are not. In my experience, these kind of fixes are sometimes even done by individuals in their "spare" time, to contribute a bit back (even if it's for a competing browser).

It's on our (my) Todo list.

The next best thing is currently probably this tutorial: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

If I remember correctly we were supposed to have our personal projects there.

Since Google owns the copyright it almost makes sense.

Also, being in the Google organization doesn't mean that Google is involved in it. I'm maintaining a project there (`google/double-conversion`), despite not having worked for Google for years. Nobody at Google has any influence or reviews on that project.

That's not true for many people.

When working at Google, developers generally open-source their private projects (which are legally owned by Google) under a Google umbrella, with a Google copyright. This rarely stops developers. When I worked there, my incentive was to make my work more useful and give something back. I'm pretty sure many other Googlers feel the same way.

If Github found another way of making my work more useful to others, all the better. I would prefer if Copilot wasn't the only option, and if there was a good open-source alternative, but that's completely independent of the fact that my code was used to teach a neural network how to complete code snippets.

Shell scripting also inspired some choices (especially syntax) of the Toit language (toitlang.org).

Clearly, it's for a different purpose, and there are some things that wouldn't work in a general-purpose language that isn't as focused on line-based string processing, but we are really happy with the things we took from bash.

The European Union looked into unifying Europe's plugs. They decided that the cost was not worth it.

I would have been happy to switch to a unified European plug. Iirc, the proposal was actually quite decent.

https://www.europarl.europa.eu/doceo/document/E-6-2005-1731-...

I use it for Toit (toitlang.org).

It's not perfect, but still incredible useful (and sometimes scary; in a good way).

I particularly like it for writing tests, but it's useful in normal code too.

Interesting fact: the Anglo-Scottish border is significantly shorter than the one separating Northern Ireland from Ireland: 154km vs 499km.

We use it for some of our tools, so it's possible (and works nicely). Our LSP server was initially written in Toit: https://github.com/toitlang/toit/tree/master/tools/lsp/serve... (To be fair, it uses the compiler underneath for analyzing the sources).

Main restriction is, that we haven't finished the Windows implementation yet. Specifically networking and spawning processes only works on Linux/macOS so far. (The main reason we ported the LSP server to Go).

The `host` package (https://pkg.toit.io/package/github.com%2Ftoitlang%2Fpkg-host...) provides some functionality for running things on the desktop.

We rely heavily on the ESP32 peripherals for strict timings.

For example the 1-wire protocol is implemented using the RMT (remote control) peripheral. The pixel strips driver uses the UART or i2s.

If really necessary, we could drop down to C, but the hardware is usually better (more precise and leaves us to do other things in the meantime).

We couldn't use `:` as that one is already used for too many things.

We then experimented with different tokens, and `/` felt best.

The `:` are actually doing the same thing, introducing a block (think of it like a limited function).

The `/` are also the same (division), but it's true that we also use `/` to introduce types. For example `x/int`.

I think Toit is relatively easy to learn, but there are definitely a few things that need explaining in the beginning.

For those interested in a comparison to MicroPython: I recently wrote a Toit version of the MakePython ESP32 Dev Kit lessons.

Here is the Toit version of it: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

And here the MicroPython: https://www.makerfabs.com/desfile/files/Get-Started-MicroPyt...

In big parts that's true, but there are some good arguments in favor of a GC for these small devices:

- the GC is a sliding compacting GC. As such there is no fragmentation for heap-allocated memory.

- the memory on these devices is tiny. The GC thus doesn't take long time.

- the ESP32 has really good peripherals, making timing sensitive operations very rare. In most cases there is a hardware module that does the job for you. The timing requirements then usually become significant less important.

Jaguar is the tooling to enable rapid development. It consists of two parts: one that runs on the ESP32 and another one that runs on your computer.

Whenever a new program is ready, it gets pushed (over WiFi) to the device. The whole process only updates the actual program (not the whole OS), thus making the development cycle really fast.

Compared to MicroPython, Toit is significantly faster. In my (obviously biased) opinion, it's also more robust.

You can't link C drivers directly without modifying the Toit code base, but there is a bridge to talk between C and Toit code. Generally, we prefer to reimplement the drivers in Toit. However, for some bigger ones it clearly makes sense to keep the C version.

Another alternative is Toit: https://toitlang.org

I recently wrote a Toit version of the lessons for the MakePython ESP32 starter kit. That makes it easier to start with Toit, but it also gives a nice comparison between the two.

MicroPython: https://www.makerfabs.com/desfile/files/Get-Started-MicroPyt...

Toit: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

I'm a fan of the MakePython ESP32 dev kit. It's reasonably priced and the ESP32 makes it possible to do nice things. https://www.makerfabs.com/makepython-esp32-starter-kit.html

I used it for our Toit tutorial: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...

Occam's razor states: "entities should not be multiplied beyond necessity".

Given that viruses have multiple times spread from animals to humans this would be the simplest explanation, favored by Occam's razor.

That said, the scientific community has not ruled out a lab leak.

The Atlantic generally has very good articles on where the investigation stand, and how different people interpret the probabilities/coincidences.

For example https://www.theatlantic.com/science/archive/2021/09/lab-leak...

Given that China is not really interested in any conclusion on this topic (except if the virus was imported from a different country) we will probably never know.

I know of at least one start-up that is using video and AI to give feedback on training sessions: http://formfirst.app

In some way the program should be much better at detecting faults than a human, but I'm not sure if the population is ready to trust applications yet.

However the potential of combining training feedback with gamified sessions that are geared towards a specific individual has huge potential imho.

This is an add-on to write code in Google docs and presentations.

When I worked at Google there was an add-on go/kodify which allowed to write code segments inside Google docs and then use it to syntax highlight all code.

When I left Google I decided to recreate such an add-on. I added a few tweaks here and there and made it work for presentations as well.

The code is open-source at https://github.com/floitsch/syntax-addon

Perfect time to explore Toit (http://github.com/toitlang/toit) :)

We get a lot out of having static classes and methods that can't change dynamically. This allows us to use the selector-based row displacement technique for building a compact method dispatch table. (See https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.29...)

Many small decisions help keeping the system fast. The memory layout, the bytecodes, the FFI interface, ...

Separating the compilation process from the running process obviously also helps. It gives us the option to do slower optimizations before-hand, and not pay for them at runtime. (Independent of the fact that the ESP32 wouldn't be able to do big optimizations anyway).

This is actually an area we haven't really spent too much time on yet: optimizations. The current compiler doesn't even do inlining yet. The speed of Toit was never really a problem, and we preferred to spend time elsewhere. Eventually, we will definitely do more there again.

Toit doesn't have generic types yet. This limitation means that the dynamic checks are very fast.

Since these checks also allow some optimizations, the cost of the dynamic checks is maybe 10-15%. And that's before doing a global type-inference, which should remove many of the checks.

I compiled the VM to WASM and ran the bytecode in it.

Toit is optionally typed, and supports type annotations.

Type annotations for locals, fields, and globals are written with a trailing `/Type`. Return types are written with `-> ReturnType`.

See https://github.com/toitware/toit-lsm303dlhc/blob/main/src/ac... for a file I recently edited.

When a type annotation is written, the compiler enforces it. It uses it for static optimizations, and dynamically checks that the type is correct.

When a type can be null, it has to be suffixed by `?`.