This looks really promising! I just tried it out. A few pieces of feedback!
1. It seems like the save delay is a bit too long. If you reload the page within like 1s of writing, what you just wrote disappears. Maybe make that faster and/or include a confirmation that there's unsaved changes if you try to close so you don't lose changes.
2. I was expecting some of the other languages to evaluate too (specifically JS). Maybe I missed something, but it seems like just the Math blocks are evaluable? Does it work with JS too?
Some things I love:
1. Block concept!
2. It's a scratchpad, there's no files to save. I'd love to use this as a dev journal.
This is now fixed by making sure the buffer is flushed on reload / exit. Should be released in a beta version in a couple of minutes. Turn on the beta channel in Heynote's settings if you want to update to it right away.
2. Only Match blocks evaluate, and it's likely to stay that way.
Go is a surprisingly pleasant language for building websites, especially for indie hackers, yet the tooling is not quite there. I'm trying to get the developer productivity for building websites in Go to be on par with building web applications in Node.
With ESBuild and Goja maturing, we're pretty close. Go is still just missing a few important connections needed to the frontend ecosystems (e.g. React, Tailwind, etc.)
Let me know if you're also interested in this space!
Mostly the frontend story. Server-rendered React pages that work with layouts and error pages. You can cobble something together, but it's not as seamless as Next.js or Remix.
Yeah I don't think it's so much "we explicitly rely on this behavior, how dare you change this" as "somewhere in our mountains of maintenance-mode code that haven't seen the sun shine through an editor window in years, this behavior cancels out another bug that we never noticed". Tooling should be able to detect when code relies on this, but it's still gonna cost some non-zero amount of developer effort to touch ancient code and safely roll out a new version if it needs to be actively addressed.
If you have tests and they break with GOEXPERIMENT=loopvar, then there is a new tool that will tell you exactly which loop is causing the breakage. That's a post for a few weeks from now.
Neither can I, but there may be cases of code accidentally relying on it - there's an adage that I forgot the name of that says just that, and I think compiler manufacturers are the most aware of that adage.
Most commonly no impact. It can require an additional heap allocation per iteration if taking the address or capturing in a closure, but even in those cases escape analysis may be able to determine that the value can remain on the stack because it will not remain referenced longer than the current loop iteration. If that happens then this change has no impact.
I'm not sure how thorough Go's escape analysis is, but nearly all programs that capture the loop variable in a closure and are not buggy right now could be shown to have that closure not escape by a sufficient thorough escape analysis. On the other hand for existing buggy programs, then perf hit is the same as assigning a variable and capturing that (the normal fix for the bug).
Google saw no statistically significant change in their benchmarks or internal applications.
The main thing that summary is missing is that the one who resigned was one of the most popular contributors and a member of the core team, and that it was some unidentified member of the core team who pulled the strings to revoke the invitation without a vote.
Most recent drama is thePhD was invited to give a keynote speech and then it was demoted to regular talk at the last minute. Both the invite and the demotion were by "rust leadership".
> Both the invite and the demotion were by "rust leadership".
That is bit overly reductive imho. As far as I can tell there wasn't really a singular leadership group making decisions collectively, which was the crux of the issue.
1. It seems like the save delay is a bit too long. If you reload the page within like 1s of writing, what you just wrote disappears. Maybe make that faster and/or include a confirmation that there's unsaved changes if you try to close so you don't lose changes.
2. I was expecting some of the other languages to evaluate too (specifically JS). Maybe I missed something, but it seems like just the Math blocks are evaluable? Does it work with JS too?
Some things I love: 1. Block concept! 2. It's a scratchpad, there's no files to save. I'd love to use this as a dev journal.