Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
arraysstartat11187347d1. Use PHP, finish project. Maybe less popular because "PHP garbage". Requires dependencies to be installed.
2. Use not PHP, do not finish project. No one uses it because it is never done. Maybe does not require additional dependencies.
I would go with option 1.
ajit5552036347dWith Go you can easily provide a single static binary (excellent for simple app distribution) that contains your whole application or CLI for your chosen platform. To target a different CPU or OS you just pass in an environmental override when building.
Here's a binary for Windows, 64-bit Linux and Raspberry Pi:
GOOS=windows go build -o cli.exe
GOOS=linux go build -o cli
GOARCH=armv7 GOOS=linux go build -o cli-rpi
I use minikube, kubectl cli apps for Kubernetes, which do tons of functionality with a single, simple executable.
@arraysstartat1 haha, very good point
@ajit555 yes, one of the features I love about golang, anyway, for the project I need a scripting language, and while there is some implementations in golang, none are stable. So it makes most sense to use dynamic language like python or php, that can be used themselves as scripting languages.
netikras19189347dIf the tool will only be useful in php projects - use php. If it can be handy in non-php projects too - use a more generic language, like py
Voxera6868347dIf you think it will be useful make sure to finish it first. Use php if that is what you are comfortable with.
Once its done and people start using it you can make version 2 using another language now that you know exactly how it should work
And having users is in my case a very strong motivator :)
I have also built a cli tool in php once.
An email sorter where I used a php library from a webmail project for parsing.
It simply was the easiest way to get it done then as I at that time did not know of any other email parser outside of perl, and I did not want to that way ;)
Do it in PHP if you feel like doing it in PHP, once it's out there and there's a demand to port it, either start porting it or get the community involved.
No serious, choose something you're familiar with, if possible. Otherwise you might run into problems sooner or later and may need to start all over again.
Well, I guess I will go with PHP after all and like you guys say, if it’s actually going to be that good, then I can always port it to other language. Thanks for helping me to realize that.
@gintko can you give some more informations, about what the tool will do? (:
It’s code generator that’s based on templates (similar like intellij smart templates). There’s hygen.io which is very close to what I am trying to achieve. But I am going to implement some additional features:
1. Storing templates in cloud (git), so they could be accessed from anywhere.
2. Make templates completely flexible by introducing option to script them and process input. Later on, perhaps even implement some plugin system.
In the end, idea is to be able write flexible code templates (say crud), that could adapt to every different situation.
@gintko have you had a look at Symfonys maker bundle? It has allready a commandline interface and some of your desired functionality (not that much to be honest though). How about forking that and extending it?
@gintko keep us updated (:
SevenDeadlyBugs4001343dDuring weekend, found out that someone behind the google a few months ago started implementing new scripting language for go (https://github.com/google/...), which is perfect for my case, so perhaps I will go with golang after all, and I love that language even more than php. Plus it will solve my sandboxing issue (that in php turned out to be really complex one).
XanderCage66324dI think you need a "win". That is feeling of accomplishment, recognition from someone, and similar. So you need to release asap, no matter the language, perfection, level of completion, etc. You'll get more motivated and your mood should improve.
Do it the scrum way: release a little but often. Think if there is something you can release now, even if it doesn't have everything you ever wanted/planned. Then take it from there, see how the community would react, see if you'd still have interest in continuing this, etc.
If you feel like changing the stack, perhaps you can do that in v2 or smth.