[1]: https://lune-org.github.io/docs/

[2]: https://lune-org.github.io/docs/the-book/5-networking/#runni...

I am hoping this will be the way in which I write most of my future scripts and projects.

[1]: https://luau.org/

[2]: https://lune-org.github.io/docs

If you join the Discord and search for "this week", "this month", "next week" and "next month" with Alex Medvednikov as the author, you'll see 80+ (yes, that many) missed deadlines, some that go all the way back to 2019.

Version 0.3 promised autofree and a syntax freeze, it got none of those. I remember discussing this with Alex, saying that it would be ideal, to publicly mention that autofree wouldn't be included in the release, and it is as if he just couldn't see why that type of communication was important.

There were also instances of moderators publicly being mean to other chatters, _especially_ when asking about valid concerns in the language, like the criticism mentioned in other blog posts (specifically the "V is for Vaporware" posts). When talking to one of the other moderators, this was defended as "cultural differences".

I left the team (and was blocked by Alex) the same day that another developer left.

The V syntax has also changed quite a bit, and is significantly more complex than it was in 0.3.

One thing I wish would have happened with V, would be having a narrow focus, instead of working on Gitly, vbrowser, ved, vinix, Volt, native backend, autofree, c-to-v converter, go-to-v converter and all the other things. Alex is very ambitious to the point that very little seems finished.

https://github.com/benstigsen/include.js

> Making use of sql.DB from multiple goroutines is safe, since Go manages its own internal mutex.

Then I quote the database/sql documentation [2]:

> DB is a database handle representing a pool of zero or more underlying connections. It's safe for concurrent use by multiple goroutines.

[1]: https://stigsen.dev/notes/go-database-thread-safety/ [2]: https://pkg.go.dev/database/sql@go1.23.3#DB

Found a minor mention of it on the Wayback Machine: http://web.archive.org/web/20221114163056/https://100r.co/si...

Thank you for correcting me.

I loved the idea of simplicity, autofree, the UI framework, the browser, Volt app, GitHub alternative, operating system and so much more. But it just didn't seem to go anywhere. The syntax however was simple, I really admired it and by 0.3 they would have a syntax freeze, but I do see that some major syntax has changed after 0.3 multiple times. I left the same day another developer did, and having talked with multiple V developers shortly after, four of them said they agreed to my criticism about moderation and broken promises. Alex (the creator) wrote to me personally, but denied all the criticism which was mentioned in the "V for Vaporware" articles.

In the moderator channel Alex mentioned that autofree wouldn't be delivered in 0.3 and this became my main criticism in the DMs. He could not see why I found it important to notify the community about this, while also telling me to "grow up" for not supporting offensive language, referencing some of the ways Linus Torvalds has written responses.

Shortly thereafter he blocked me privately. It wasn't clear to me if I was blocked though, as Discord just told me I couldn't reach him. So I contacted one of the moderators, who told me that it's due to culture differences.

At one point I even searched in the Discord for messages by Alex that contained "this week", "this month" and "this year", also using "next" instead of "this". It came out to 50+ times that deadlines had been missed (closer to 80+ probably). Even with some major projects such as Gitly from 2019 if I remember correctly, which still isn't done.

[1] https://xeiaso.net/blog/v-vaporware-2019-06-23/

A lot of what could be static sites use JavaScript.

CSS may be tricky to some (I'm still lost with flexbox), but what I've found particularly helpful is using some already finished CSS stylesheets, then just modify them to my needs. Like PicoCSS, MVP.css and more.

Like the post says:

Sometimes, people get angry at React or other FrontEnd frameworks just because they look scary or too complex. But the reality is, FrontEnd is complex.

I have been avoiding React and similar frameworks with a belief that they introduce complexity, but also that they make the site perform slower, produces less traffic either due to hardware restrictions or download speeds. These are valid concerns to consider. Vanilla JavaScript and so on is already pretty simple, I wouldn't be too opposed to the use of jQuery as it can make some things simpler. But in the same way a few of us avoid front-end frameworks like the plague, a lot of front-end developers choose frameworks due to a lack of familiarity with standard / vanilla technologies.

I think what's even more interesting to note is the support for modals with regular HTML and other such features, so that one can depend less and less on JavaScript. (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...)

Did like the write-up on HTMJS though.