Live data from Hacker News

Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

gitly.org

111–120 of 136 posts

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#111

Earlier quoted context omitted.

Could someone explain to me why, after seeing how many exaggerated claims the author has made, they have invested their time into building up a community around it? I'd be straight up terrified to trust anything serious with this guy's work. In this instance, the demo won't even load for me and the documentation page can't be bothered to put the most basic of padding in it. Why even release publicly? Promises, promis…

You create a new account to spam the thread with accusations, and links to biased articles (see my comment above). Any actual valid examples of exaggerated claims? > and the documentation page can't be bothered to put the most basic of padding in it. Why even release publicly? Well it hasn't been released. It's pre-alpha software, like the GitHub page says. Why would I not have it up for testing?

> Any actual valid examples of exaggerated claims?

How about this one:

> It will be launched this month. We're actually going to switch to Gitly CI, since Github Actions has been really slow for us.

I setup a reminder for 1 month.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#112
post #91

Earlier quoted context omitted.

Those that lie often either don't respect other people or they don't have the ability to know when they are lying. Which is scarier? Go, Nim, and Zig have similar focuses and their devs have put in years of public, good work. Some of the take downs at the time he was making his initial claims are absolutely brutal and make it clear that he not only couldn't back up his crazy claims, he wasn't getting the small stuff…

I'm the author of that post if anyone has any questions.

Yeah let’s bash on V again instead of celebrating what this post is about: a really great web app.

Maybe it is time to move on to more productive discussions. People are obviously building pretty interesting things with V.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#113

Earlier quoted context omitted.

No, this file is no longer used. We have a fully working net module: https://github.com/vlang/v/tree/master/vlib/net/http

In that case, you ought to be mocked for making a mess of the repository by keeping unused files in it.

Why should anyone be mocked for anything? How is that conducive to the conversation?

You should rethink how you convey your ideas, IMO.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#114
post #112
post #91

Earlier quoted context omitted.

I'm the author of that post if anyone has any questions.

Yeah let’s bash on V again instead of celebrating what this post is about: a really great web app. Maybe it is time to move on to more productive discussions. People are obviously building pretty interesting things with V.

Calling this "a really great"web app is a significant stretch. It's an extremely bare bones clone of GitHub. Another case of over promising and under delivering from the V team.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#115

Earlier quoted context omitted.

> if the guy and his friends pour out solid code then there's nothing else to say :) Unfortunately, they don't.

is gitly yet another imaginary revolution ? (honest question)

Is gitly supposed to be solid code?

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#116
post #31

Earlier quoted context omitted.

Can you perhaps link to some of said criticism? I'd be interested to read it.

Here is a nice mini series of blog posts about V https://christine.website/blog/series/v

Meh. I have some issues with the criticisms there, but they make some okay points too.

I don't see this as a reason to dismiss the entire language though. I've seen more damning arguments against Go, Rust, Zig, etc.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#117
post #74
post #58

Earlier quoted context omitted.

The best bit is this excerpt from the standard library (2019): fn download_file(url, out string) { // println('\nDOWNLOAD FILE $out url=$url') // -L follow redirects // println('curl -L -o "$out" "$url"') os.system2('curl -s -L -o "$out" "$url"') // res := os.system('curl -s -L -o "$out" "$url"') // println(res) } Here's what that file looks like today: https://github.com/vlang/v/blob/master/vlib/net/http/downloa...

I really don't understand why everyone is making fun of what is clearly a stub implementation. Have we not all written code like this so we can go work on some other part of the code that depends on this?

Most of us also don't splash it all over hn/reddit like it's the second coming of Christ.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#118
post #35

Looks like V author/community is on the track to rewrite the world. Expect operating system stuff next? I'm shocked by how quickly it goes along, though. Gitly is quite usable already, and I appreciate the swiftness. I'd think that Rust community is rewriting the world, but it's happening at much slower pace. Is V's basis strong enough to do this? Seeing the issues like [1] (about the basic memory management stuff) o…

Could someone explain to me why, after seeing how many exaggerated claims the author has made, they have invested their time into building up a community around it? I'd be straight up terrified to trust anything serious with this guy's work. In this instance, the demo won't even load for me and the documentation page can't be bothered to put the most basic of padding in it. Why even release publicly? Promises, promis…

Yeah, it's absolutely wild. Even the main contributors don't really know what they're talking about, they just regurgitate the party line.

http://imgur.com/a/hUXR6s3

For instance, when asked how the memory management system works, here you see a team member give the standard response: the compiler inserts calls to free when it detects the variable is no longer used. This seems reasonable to anyone who hasn't thought much about PL/compilers before. But when pressed further, you see Alex admit "most stuff is simply cloned ATM" which is in stark contrast to the "autofree handles 90-100% of objects for you" on their homepage.

Or this where Alex shows he has no idea what UB is?

http://imgur.com/a/mbLtASH

UB is a property of the language's abstract machine. Common C UB like dereferencing a null pointer or signed integer overflow has well defined semantics on basically any commodity hardware manufactured in three decades and yet it is still UB not because of the runtime properties but because the C abstract machine says it can't happen and compilers are free to optimize based on that assumption. For a language that compiles to C and claims no UB, the author should have a much better understanding of this.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#119
post #116

Earlier quoted context omitted.

Here is a nice mini series of blog posts about V https://christine.website/blog/series/v

Meh. I have some issues with the criticisms there, but they make some okay points too. I don't see this as a reason to dismiss the entire language though. I've seen more damning arguments against Go, Rust, Zig, etc.

The languages you've listed generally work as advertised and while you might dislike some of the design decisions or tradeoffs inherent in those decisions, ultimately, they do what they claim to.

The same cannot be said of V.

Re: Gitly: A light and fast GitHub/GitLab alternative written in V lang (pre-alpha)

#120
post #82

Earlier quoted context omitted.

Hardly an unbiased article: > V can be bootstrapped in under a second by compiling its code translated to C with a simple cc v.c No libraries or dependencies needed. Git is a dependency, which means perl is a dependency, which means a shell is a dependency, which means glibc is a dependency, which means that a lot of other things (including posix threads) are also dependencies. Pedantically, you could even go as far…

So if it was a release build from the time, there wouldn't have been massive memory leaks, she would have been able to compile 1.2 million LoC per core per second, V would have only used 400kb of space to compile itself, and the curl binary wouldn't have been used for the download_file function? I agree that there's a cutoff where Linux dependencies don't really count as dependencies in this case.

This is great. I try to have an objective discussion about whether or not Christine's critique is fair, get no response, and am downvoted by who I assume are V lang fanboys. Not improving my impression of the language.

It's important to sort out these lies (and apologize for them if they were, in fact, lies) because no company will use a product they can't trust to do what it says. Though it's all at V lang's own peril I suppose.

Post reply on HN