back

by wiradikusuma·4y ago·view on hn ↗
We use Space due to GitLab's recent pricing changes.

We like:

- free git hosting

- free slack-like with sub-thread

- generous CI/CD

- built-in issue tracker

- built-in wiki

- very snappy

- has mobile app

We don't like:

- CI/CD script uses Kotlin DSL, feels "heavy".

- Issue tracker very basic, we end up using YouTrack. Still don't know how to integrate it lol.

- One project can have multiple repos, but they all share same permission. So we end up creating multiple projects e.g. mobile app, web, backend.

- Regarding multiple projects.. we end up creating another project just to contain wiki.

- Cannot trigger based on tag. We end up creating branch for different environment.

- Difficulty in writing CI/CD script due to limited documentation/knowledge on the net and unfriendly keyword ("space"? Lol. You have to type "Jetbrains space automation (keyword here)"

- At certain times VERY slow.

- Notifications in Mobile App sometimes not working.

We find confusing:

- Calendar

- Video call

Confusing because why add more features that's already best served by other services?

5 comments
Feels like there's a big race to be the all-in-one everything tool for everything. It's Gitlabs whole schtick, GitHub is moving in that direction, now "also Jetbrains".

IMO I think something like Jetbrains should be leaning into integration, not all-in-one. Connective tissue last longer than walled garden.

There's no money in integration. It's very easy to get approval for some big shiny tool with a frontend and 19 different features. It's very difficult to get corporate approval for a tiny integration thing that makes 5 of those features work with some others in a different tool. "Can't you just type it in manually?"
Is that true? A large part of the value add of Asana is that it integrates with everything.

They’re probably the most expensive issue tracking tool (many times the amount we’d pay for Jira), but it’s extremely worthwhile for us so we pay it.

The pain of getting finance to approve recurring charges is quite real.
The race is to go back into the timesharing development workflows, under the guise of cloud development.

Instead of telnet, ssh and X display, we get to use the browser.

Sure. The cloud is the new mainframe.

Mainframes were ever since the best option to milk locked-in customers, so the story continues.

The tech is different, the strategy the same: Be the all emphasizing platform so nobody can leave without needing to rebuild substantial parts of their business form the ground up.

Replacing the mainframe after been invested in it constitutes for many a mayor headache to this day. So one can conclude that the said strategy works well since decades.

But that's no news, is it?

Apparently it is, for those that haven't had the pleasure to work during those days, which I might add was still quite common around 2005 (when I moved away from HP-UX to Red-Hat Linux at Nokia).
IMO it’s also about choosing the right things to integrate vs. build. I agree that with Space in particular, the choice of what they integrate vs. build does not make sense for maximizing developer experience and value. At Coherence (withcoherence.com // I’m a cofounder) we are also building a more integrated set of tools for building software, but we don’t feel that GitHub and Slack or JIRA/Asana/linear are the tools to bite off, or that the world needs yet another CI syntax and hosting platform. Those are all great places to choose integration with existing popular tools. We do agree with the Space product thesis in that the Cloud IDE is a central piece of the next generation platform - we just think that tying it deeply to the deployment and cloud infrastructure workflows provides the most developer value.

Of course, we’re huge fans of JetBrains products, and them and the other companies mentioned above have so much credibility and such vast resources that they are going to deliver widely-used and powerful products. We hope to integrate with them where it makes sense!

If you are curious to learn about about Coherence, please check out our free beta at the link above or feel free to reach out to hn@withcoherence.com… We appreciate any and all feedback from the HN community.

I'm unsure why the ability to tie the IDEs with the 'space' issue system is not in place. I've gotten very used to using IntelliJ and PHPStorm contexts relating to issues tied to an issue tracker. There's no connector for 'space', and hasn't been for... over a year? If they're wanting to offer all these items and tie you in to an ecosystem... then tie them together. I'm probably in a minority in using it, but it was the first big WTF I saw when trying to start some new projects with 'space', and just gave up for now. If it's not that important to them after a year... it makes me question their priorities (have been a paying IDE customer for... over 10 years at this point).
> - CI/CD script uses Kotlin DSL, feels "heavy".

But hopefully the IDE completion is second to none? My experience with editing .gitlab-ci.yml is that different versions support different features/structures, but GL didn't annotate their file with any such version specifier making it hard on the tooling. I haven't used Space in anger in order to know what that editing experience is like, but I have used the Kotlin version of gradle and it's night and day different having actual, you know, types for things

As much as I detest Jenkins, the one thing I thought it did well with Jenkinsfile was the ability to declare shared modules (GL offers this too with "includes:" but it can be some mindfuck trying to reason about the hierarchy, extends, and now !reference usage to get composition correct). I hope Space has something similar if they're going down that (literal) pipeline-as-code route

That's what I thought initially (it's just code! autocomplete! using Jetbrains' own tools!

But, unless you already know what you're looking for, it's useless. The documentation is very short and lacking examples. So the completion is, well, just for completion. Not good for exploration.

That's incredibly sad to hear; did you open a YouTrack about it? I've had mixed results with their bug triage process, but in my mind if I don't bitch, it's for sure not going to get any attention: https://youtrack.jetbrains.com/issues/SPACE
> - CI/CD script uses Kotlin DSL, feels "heavy".

That's a PRO!

Every CI/CD tool that uses yaml or any other non-programming-language should burn in hell.

Let the developer write the code that creates the datastructure that describes the CICD process. That is flexible, reusable and can even be made typesafe.

Personally I’d take the Kotlin setup over writing Groovy for Jenkins. God I hate configuring Jenkins for CI.