#Go Project Feedback

54 messages · Page 1 of 1 (latest)

hazy river
#

Hi guys, so for background, i have been programming for only ~2 years, im still very much a beginner in process of learning

I started learning go around like around 2 weeks ago maybe? i made phytagoras calculator as my first project to get the feel of Go

And now, i just made a Task Management CLI with Go, called Taski, and here i want to share my project to the public, it’s overall finished (imo), and i would be happy to get feedbacks, critics, suggestions, or absolutely anything!

here is the link to my repo: https://github.com/tristnaja/taski

appreciate you guys! thanks!

Note: I do use AI but specifically only for Tests and Documentations because i want to focus more to learn the development process for now, so maybe there’s so much things that i didn’t do well and isn’t best practice yet on the source code, that’s why i want feedback!

GitHub
GitHub - tristnaja/taski: Task Manager CLI written in Go

Task Manager CLI written in Go. Contribute to tristnaja/taski development by creating an account on GitHub.

stone ridge
#

I would get rid of internal/

#

and app/ too

lunar imp
#

Feels really weird that main.go isn't in cmd too

#

Just as convention

#

Also, AI constantly creates an internal directory.

#

I swear for every project

stone ridge
#

main.go should be at the top when what you produce is … a single binary

lunar imp
#

I don't think the code quality is poor though

#

it's mostly just directory/project structure that feels off

hazy river
# stone ridge and app/ too

i seeee, so making that internal/ and app/ is unnecessary then?

yeahh, im still exploring and seeing as to what the convention for the project structure is

lunar imp
#

it is unnecessary in this case, yes. The system is so simple. it add mores complexity with the directory structure you have

stone ridge
hazy river
#

any, like, guidelines for like how to structure a project?

stone ridge
#

re the code, you assume the data is next to the binary, that’s not great

hazy river
hazy river
#

you are referring to the data.json right?

i made it like that because i needed the path as a filename variable that get passed on to functions

maybe there’s a way to refactor this?

lunar imp
#

put it all in taski

#

it feels boring, but boring is good in go

stone ridge
hazy river
lunar imp
#

i'm serious though

#

when you reach the point that you need to start decoupling you'll know

#

right now you're unsure because you're not in that problem space

#

so put it all in one directory and then when you reach that problem start thinking of how you'll architect the system

#

that signals to me that it's a simple program. keep it simple

#

when you can take a complex project and make it simple that is a good developer

#

(and why go is so special gopherhappy )

hazy river
hazy river
hazy river
lunar imp
#

Note: This README and tests are AI generated because im lazy.

#

appreciate the honesty lol

hazy river
#

HAHAHAHAHA, i mean, gotta be transparent

#

thanks guys!

#

any other suggestions, advices, and recommendations is welcomed if there are others who wants to give it to me!

sage canyon
hazy river
dry cradle
#

@hazy river

Just tried out to review some code.
Specially on "io" file we need idiomatic.
As some task run at once and overwrite each other or Go style for returning , or nameing the function and files there and variable there . ( specially the name of module you are using ).

Overall well done buddy Pogher

hazy river
dry cradle
#

In my opinion, it would help to review some well maintained public repositories for example AST related projects which involve with many std patterns or run the code through an AI tool to evaluate it from a clean-code and idiomatic Go perspective.

As a suggestion you may also want to review and profile the concurrency behavior, especially by covering it with proper test cases. this part of the code seems to require more careful handling and may add additional complexity of features if you think so 🙂 @hazy river

hazy river
#

Okayy! Thanks for the advices and insights, i appreciate it!

Yeah, i wasn’t doing proper testing for this one hahahaha

and i will see further on what you just mentioned!

stone ridge
#

what concurrency is there in a cli?

dry cradle
#

@stone ridge
There is no,

As this task should be called on several process reading and writing file and modifies in memory would be negative point and race will happen . as we don't except to working with single writer and reader in this codebase

stone ridge
#

that would be if they had a server or daemon. what you say makes little sense

#

they do need some equivalent of flock but that has nothing to do with what people use « concurrency » for in go (go routines, channels, mutexes etc)

dry cradle
#

@stone ridge
I think we’re talking about different layers.

This isn’t about Go’s in-process concurrency primitives (goroutines, channels, mutexes). It’s about concurrent access by multiple OS processes to the same persistence file. Two CLI commands running at the same time are concurrent writers, even without a server/daemon.

In that situation, a read–modify–write cycle without an inter-process lock or an atomic write strategy (e.g., write temp file + rename) can lose updates or produce corrupted/partial reads. That’s true in any language, not just Go.

flock (or an equivalent mechanism) is exactly how you coordinate this kind of filesystem-level concurrency.

Goroutines are one form of concurrency; multiple OS processes touching the same file is another. Same idea (coordination), different layer.

stone ridge
#

sure edit and use ai to make it sound slightly less off topic 🙂 still irrelevant word salad. if you don't have something useful or specific to contribute, don't. AI answers are NOT welcome (but even worse when off topic)

dry cradle
#

@stone ridge
I think you have a problem here: what I described is inter-process concurrency. it
With AI or without AI, it doesn't change the fact.
Just try mentioning the name of the persistence file we're dealing with, and avoid replying to points that aren't on your side or related to the technical issue.
This guy will figure it out himself eventually and understand what I'm saying — and you'll probably end up writing something unrelated again, old man.

muted sage
#

+1 on _dl

#

concurrency over file writes is handled by the OS anyway, and you have no good reason to run multiple instances of a todolist

dry cradle
#

@tight comet
wasn’t trying to argue here — just sharing a general tip for a newer dev.
we don’t know how this tool will be used, so it was more of an FYI than a requirement.

hazy river
#

oh my, i look over my shoulder and you guys debated here, hahaha

i took every advices and insights from here, and will absolutely learn from what you guys said

from project structure conventions, naming conventions, idiomatic, and will absolutely take my time to understand it

im happyy that you guys really put your thoughts about this simple program of mine, im flattered! thank you guys!

I understand where both @dry cradle and @stone ridge are coming from

and you both are correct guys, and im so happy you guys actually took it to another level by discussing it

I do understand what @stone ridge is trying to tell me, that there’s no concurrency in this CLI with context that it’s something such as go routines, channels, or mutexes

and i do understand that @dry cradle is trying to tell me a new information that might be beneficial for me to know about these simple program of mine, that i should be aware of this thing called “flock” and that my program actually may have a concurrency problem when multiple OS is trying process the same persistence file

you were both trying to give me advices and information that can make me be a better dev

So thank you everyone for joining and sharing your thoughts here! it was very insightful and everything is appreciated!