I use iced, the idea behind is great - elm architecture. However, the attitude of maintainer that doesn’t bother to be involved in discussions in their discord and merge behemoth size changes with no review makes me think more and more if it’s a good choice.

I recently started looking at the xilem which is also elm architecture inspired abd being developed openly and with proper engineering practices, however it is at very early stages just yet.

This reminds me of dokku which is a great drop-in replacement of heroku for non-mission-critical web projects.

I don’t use it anymore since I use NixOS to have it all in infra-as-code paradigm but dokku triggers nostalgia of good old time when completely was at manageable levels.

We definitely were dokku fans as well - the missing abilities to scale horizontally, not having to manage ssh access, etc. led us to develop Disco but yeah. Great parallel.

Do you use a particular stack "around" NixOS that handles deployment/github integration (or editing environment variables)? Curious what your process looks like. Thanks!

As a person with russian background I am laughing on the name of the project. With all the respect to the effort, I can’t take it seriously.

The «хули» (direct transliteration to huly) means “what a hell” or actually a bit spicier “what a f@ck”. This phrase is common for russian tradies who don’t bather to know anything but where is the nearest bottle shop and how much time left til the end of work shift.

The name reminded me PizData project from the russian speakers.

What. A. Joke.

Huly is being built by Andrey Platov, who was previously infamously known for Xored from Novosibirsk. It is clearly intentional.

Right, then I am not surprised at all. I am looking at his github account now, his status is « твой софт — гавно» (direct translation: « your software — shit»).

To me it's a clear message that the author doesn't respect anybody. Also, it seems applicable to potential projects people will build using that Huly tool?

I guess my question would be -- how on earth it's possible people trust authors like this and commit into using product built by them?

A potential knave then. I know I won't use them.

It is a fucking great name, now that I know that etymology

Yes!

C.f. 'git', which you probably do use and etymologically is obviously a bit rude and humorous too.

Merriam-Webster says:

> as in lunatic a person who lacks good sense or judgment

Not marked as rude or profane.

It's a British English word, so don't use Merriam-Webster [0]:

> a person, especially a man, who is stupid or unpleasant

Or [1]:

> If you refer to another person as a git, you mean you dislike them and find them annoying. [British, offensive, disapproval]

[0] https://dictionary.cambridge.org/us/dictionary/english/git

[1] https://www.collinsdictionary.com/us/dictionary/english/git

This is pretty clearly built by Russians (look at the Github contributors).

This reminds me of something called Kontool from Germany (IIRC). Hahaha, I already laugh thinking about it. I think it's an accounting tool, but the name has an unfortunate meaning in Indonesian... it means "dick"

I guess this kind of things are inevitable...

Also, if you see their Twitter account, they clearly are aware of this naming clash and actually embracing it hahaha

While it may have connotations in specific languages, it doesn't signify quality of the project. Hope we agree on it.

Yes, cut them some Slack.

No, we are not.

why not?

Hooli?

I thought about Huli from Silicon Valley TV show, and couldn't but think "Gentlemen, and lady, of the board"

I knew contributor @aplatoff personally, and project name is consistent with his rough and witty character.

Hi, this looks awesome, thank you for exploring Nix capabilities, that is a great piece of software.

I am curious, what drives you using docker if images can be broken down into Nix packages?

Don’t get me wrong, the project looks really cool, and it’s a bit of a hassle to write orchestration using NixOS configuration utilising systemd.

The focus here is on Docker Compose projects rather than container images. If Compose works for you, why go through the hassle of packaging the app natively?

Reminds me of aussue++[1] from a few years ago.

[1] https://github.com/zackradisic/aussieplusplus/

Here we go again! I have been using it 15 years ago.

I am a user of Hey and what I can say is the UX is dreadful. I am seeing spinner way more than I can handle, really.

I assume this proposal is to moving backwards.

Instead we would need to sort of data on client and full-body client app, doesn’t matter if it’s for web, ios, android. And the data should be given back to us - users.

The problem with that is that services like Hey become a true commodity and doesn’t lock users by keep exclusive access to their data anymore. So it’s to be figured out what is the new business model.

If you dislike it so much why do you still use it? Just curious.

It’s too much of a hassle to move from it now, since I have alot on my plate and they don’t support any other GUIs (a classic vendor lock).

I have planned it for the second half of this year though.

Everything is setup with free plans and almost everything is automated via GitHub Actions.

Also, it recognises you as an owner and allows you modify the site.

> Running a migrations on a server is far, far different to running it on every users' device. The sheer scale of it is different.

Well, it’s not only just that. Among the other things, some of the application instances would be outdated but still need to work, so you would need to support _all_ the DB schemes you have ever had for your app.

I think we will end up with something like permissions grants (including granular JS APIs available for the website, as we do for the location, camera APIs etc, at the moment) per website and convenient tools built-in browser that allow you create/re-use patterns so you don't actually interrupted by this strictness too much.

> per website and convenient tools built-in browser

Per-website, for dozens (if not hundreds) of APIs and convenient? These are contradictory :)

Yeah, sounds a bit overwhelming for users, but my point here us that we would need appropriate tooling to be offered to end users so they are not get lost (quickly lol).

In this article I would like to show how you can organize your golang web project with live code reloading. It scheme can be easily extended and will allowed to write couple of line in bash to get what you want.