Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Move to Rust or Go for more advanced features #54

Open
imide opened this issue May 14, 2024 · 9 comments
Open

Suggestion: Move to Rust or Go for more advanced features #54

imide opened this issue May 14, 2024 · 9 comments
Labels
enhancement New feature or request

Comments

@imide
Copy link

imide commented May 14, 2024

I think the project is a really good idea! I would like to contribute, but I do not know shell (and not really interested in it as it looks like a hernia).

I think migrating/porting this project to another language with incredible TUI/GUI potential (go which I prefer or rust) would benefit the project greatly.

just a thought!

@imide imide changed the title Suggestion: Move to Rust or Go for more advanced feature Suggestion: Move to Rust or Go for more advanced features May 14, 2024
@kRHYME7
Copy link
Collaborator

kRHYME7 commented May 14, 2024

😂 At last someone opened an issue about it.

The mindset for this CLI is to have lesser or no dependencies at all. This way it is lightweight, no need to be compiled etc.(yes we can package binaries, but I don't think I gained enough trust yet.)

However, it is true that we need to migrate to a lower level for optimization plus more capabilities. Especially if planning to use some toolkit for GUI, Daemon and excessive text manipulation.

I am planning to make a submodule for this CLI, It should be 'Hyde-shell' , initially a welcome app, but it's in CPP. My experience for cpp is barely enough for robotics and automation, and I suck!

Therefore, I'm planning to try a fresh start of rust soon if some features are needed.

So for the CLI, would it be fair if we stick to Shell for now? It's lightweight and easier to deal with.

At the time, I'm planning to find/write a parser that we can use for hyprland configuration, it would be useful in the long run. Issues are Hyprlang do not have bindings yet for other languages. We can read the active hyprland vars though.

Sorry for the long reply 😁

@imide
Copy link
Author

imide commented May 14, 2024

no problem! would rather have a long reply than a lgtm lmao
I understand! whatever you feel comfortable with, this is your project after all!
upon better support for config parsers and irc stuff, we can revisit this!

@kRHYME7 kRHYME7 added the enhancement New feature or request label May 14, 2024
@Oskar-Idland
Copy link

I believe Go/Python would be the best lang for the job. Rust/C++ would be a bit overkill.

  • Packaging binaries would be ok, as long as the source code is open.
  • Go has a simple syntax, and a TUI community already like bubbletea.
  • Python is popular for larger scripts with more logic, even simpler syntax, and is fast enough for the task we are doing here. Python will also most likely have the largest pool of users that can help code, as if you know C++, python is easy, but not vice versa. It is also an interpreted language so it is easy to debug at run-time (which hyde often demands), making it easier to fix bugs for the user as they do not need to compile, just run.

Python also yields as fast of a development cycle as bash would anyway, so I do not think the shift over would be that hard. We could make another branch, where we tried to port every script over gradually, and see where it goes? Would love to help.

@imide
Copy link
Author

imide commented May 21, 2024

I believe Go/Python would be the best lang for the job. Rust/C++ would be a bit overkill.

  • Packaging binaries would be ok, as long as the source code is open.
  • Go has a simple syntax, and a TUI community already like bubbletea.
  • Python is popular for larger scripts with more logic, even simpler syntax, and is fast enough for the task we are doing here. Python will also most likely have the largest pool of users that can help code, as if you know C++, python is easy, but not vice versa. It is also an interpreted language so it is easy to debug at run-time (which hyde often demands), making it easier to fix bugs for the user as they do not need to compile, just run.

Python also yields as fast of a development cycle as bash would anyway, so I do not think the shift over would be that hard. We could make another branch, where we tried to port every script over gradually, and see where it goes? Would love to help.

I agree on the branch part. However, I only know/comfortable with Go and willing to learn Rust. Python doesn't really make sense for a CLI/TUI program. (also handling python fucking blows)

@kRHYME7
Copy link
Collaborator

kRHYME7 commented May 22, 2024

All points are valid here. However, IMO, the easiest way to 'deliver' the CLI into to everyone's doorstep is to use bash as the main interface/laying ground. This might not be the convention(some distro is doing this actually), but this is the only lightweight most way I could think of. For things like TUI, we can move forward to something TUI-friendly soon.

We can pick some functions here that requires a rewrite or seen to be better optimized. And absolutely, we can add another feature.
image

As you can see, the CLI is not doing a very specific thing, it acts as a wrapper to everything HyDE related. For now, I can't see a rewrite for the main layer, as function calls are just fine and well integrated with Linux even at vanilla installation.

image

So this is just a bash function calls, so let me know if you got some features in mind, will definitely talk about integrating it.
image

@rubiin
Copy link
Contributor

rubiin commented May 22, 2024

Shell scripts just work in most unix systems without needing to add anything extra. Also since we are not doing anything cpu intensive , I dont see any performance gains using rust for the core scripts . If its for the aesthetics , then yes perhaps adding a tui layer is another option which can be made in any language.

TUI can serve as a lazy way of using the scripts without needing to write cli commands manually.
For example, LazyGit is the tui version of git which complements it well

@rubiin
Copy link
Contributor

rubiin commented May 23, 2024

https://www.youtube.com/watch?v=jw5J0rhLQyA&t=322s inspiration for TUI

@Radrahil
Copy link

I think this should be a discussion, and yes, please do this. Hyde is currently the single worst part of Hyprdots (No offense) and it's also kinda hard to give bug reports because you often have to find out yourself what went wrong, and it doesn't throw errors seemingly at all.

@kRHYME7
Copy link
Collaborator

kRHYME7 commented May 27, 2024

and it doesn't throw errors seemingly at all.

It tries to, and you missed it 😉 also, please change your branch to main. My bad making you stuck in the hyde branch. You need to change back to main. And hope the updates won't be too rough from now on.🤞

Hyde branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants