Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

V Language Review

mawfig.github.io

Post reply on HN
Print view View original

261–270 of 336 posts

Re: V Language Review

#261

Post by lifthrasiir »

amedvednikov wrote: post #254
lifthrasiir wrote: post #248

Earlier quoted context omitted.

> There's no way it takes 15s to compile 1m_helloworld.v. You're probably using a debug build of V. You don't have to guess because I can give you my log. I have exactly followed what the OP did, except for more recent revision because I couldn't get it compiled in my environment. $ git clone https://github.com/vlang/v/ $ cd v $ git checkout 0e4198f23b2b9a52d72f61dd40d019412b809791 $ VFLAGS="-prod" make make fresh_vc…

You're not using the tcc backend. It says Note: `tcc` was not used, so unless you install it yourself, your backend C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`. Also you have "gcc" in your error: See And on the website the claim is made for tcc and x64 backends. Like I said, no way it'd take 15 seconds :)

If I was not using the tcc backend for the first execution, then why would the second execution without tcc.exe be timed out? (I have also checked strace just like the OP.) It seems unlikely that the first execution and the second execution use the same gcc and still behave in such diverging ways. And if my reasoning is incorrect, please do not instinctively reply to me (I had enough) and put a proper diagnostic to tell whether TCC is being used, since it looks like a genuine confusion.

Re: V Language Review

#262

Post by gompertz »

super_flanker wrote: post #260
gompertz wrote: post #255

Earlier quoted context omitted.

Financial supporter of V here. I don't feel scammed or misled in the slightest; so speak for yourself with the imaginary money you did not donate.

I don't take responsibility of others. You don't feel scammed, good for you. May your investment come to fruition. I feel that this project is scam and as a good citizen it's my responsibility to make as many people aware about it as I can.

> I don't take responsibility

> it's my responsibility

Keep fighting whatever ghost you are fighting.

Re: V Language Review

#263

Post by amedvednikov »

lifthrasiir wrote: post #261
amedvednikov wrote: post #254

Earlier quoted context omitted.

You're not using the tcc backend. It says Note: `tcc` was not used, so unless you install it yourself, your backend C compiler will be `cc`, which is usually either `clang`, `gcc` or `msvc`. Also you have "gcc" in your error: See And on the website the claim is made for tcc and x64 backends. Like I said, no way it'd take 15 seconds :)

If I was not using the tcc backend for the first execution, then why would the second execution without tcc.exe be timed out? (I have also checked strace just like the OP.) It seems unlikely that the first execution and the second execution use the same gcc and still behave in such diverging ways. And if my reasoning is incorrect, please do not instinctively reply to me (I had enough) and put a proper diagnostic to t…

You're not using tcc, because the language literally tells you so, you get a GCC error, and you get 10x slower compilation time.

I think it's pretty clear.

Anyway, now that we are clear on the compilation speed claim, can you please list a couple of those extraordinary claims?

Re: V Language Review

#264

Post by amedvednikov »

tene wrote: post #257
amedvednikov wrote: post #244

Earlier quoted context omitted.

No, you would look at the version of the language, realize it's 0.2 and not production ready yet.

No, I really wouldn't, and don't. This is the kind of thing that reads to me as honest for a new in-development language: https://github.com/cruxlang/crux#status Features are explicitly listed as working, partially done, and not yet implemented. You're really truly allowed to say "This doesn't work yet, but we're working on...", and it is legitimate to criticize people for choosing to lie instead.

Well that's what it literally says on the website:

> V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.

> Right now allocations are handled by a minimal and well performing GC until V's autofree engine is production ready.

Re: V Language Review

#265

Post by amedvednikov »

rurban wrote: post #250
thayne wrote: post #219

Earlier quoted context omitted.

If you know of a case where rust code violates memory safety without the use of an unsafe block, file a bug and it will probably be fixed within a release or two. "Fearless concurrency" is more subjective, but rust code (again with the caveat that there isn't unsafe code, or unsafe cose upholds all unvariants) dows eliminate certain classes of concurrency bugs. Although, dreadlocks are definitely possible, and certai…

do you your self a favor and search their ticket system for stack overflow. the list gets longer, not smaller. and looking at their compiler it's clear why. stack-allocation of vars is fine and dandy, but comparable to vlang's famous unbounded autofree system. alloca() is dangerous for a reason. unsafe vec, really?? mutexes in threads, really?? concurrent blocking IO in this decade?? also read their docs about their…

3 issues mentioning stack overflow:

https://github.com/vlang/v/issues?q=is%3Aissue+is%3Aopen+sta...

I've never had one in 3 years.

edit: ah, you meant Rust

Re: V Language Review

#266

Post by amedvednikov »

super_flanker wrote: post #258
amedvednikov wrote: post #245

Earlier quoted context omitted.

Because surprise it's 0.2, and autofree has bugs, can you imagine?

Nowhere from homepage you get the clue that it's 0.2, do you?

It says 0.2 right there in the center of the home page, under the big "The V Programming Language"

Re: V Language Review

#267

Post by amedvednikov »

tene wrote: post #141
sergiotapia wrote: post #48

Earlier quoted context omitted.

Nah that article is old as hell - time for new information. Things change. I also despise how many people want to shit on this new language before it even takes off. Why are so many people frothing at the chance to disparage this language and it's author? Never seen something like this.

> Why are so many people frothing at the chance to disparage this language and it's author? It's because of all the lying. The author keeps claiming that their language has features that it definitely does not have. Why do so many people consider "I checked several notable claims, and most of them are false" to be some kind of hateful disparaging attack?

Can you list the false claims here? 1. 2. 3.

Shouldn't be hard, if "most claims" are false according to you.

Re: V Language Review

#268

Post by amedvednikov »

klyrs wrote: post #28
pwdisswordfish9 wrote: post #6

At this point, why do people even spend time on debunking the marketing claims of this language at all? It's been done to death, whoever was going to be convinced the V developer is a charlatan has already been convinced. For better or for worse.

For what it's worth, there has been some progress on the language and the author has responded to past criticism. I've been following developments of the language for a few years now, and I'd love it if all the claims came to fruition. Since it's a work in progress, past criticism doesn't necessarily apply -- leaving me to wonder "is it not bullshit yet?" Since the author has a habit of overpromising and even declari…

> Since the author has a habit of overpromising and even declaring things finished before even starting on them

Do you have any examples?

Re: V Language Review

#269

Post by klyrs »

amedvednikov wrote: post #268
klyrs wrote: post #28

Earlier quoted context omitted.

For what it's worth, there has been some progress on the language and the author has responded to past criticism. I've been following developments of the language for a few years now, and I'd love it if all the claims came to fruition. Since it's a work in progress, past criticism doesn't necessarily apply -- leaving me to wonder "is it not bullshit yet?" Since the author has a habit of overpromising and even declari…

> Since the author has a habit of overpromising and even declaring things finished before even starting on them Do you have any examples?

TFA has plenty. Don't let yourself get mired in fights on the orange site. Instead, spend the energy fixing bugs and you'll meet less criticism in the future.

Re: V Language Review

#270

Post by vlang1dot0 »

amedvednikov wrote: post #199
ptx wrote: post #197

Earlier quoted context omitted.

Maybe I misunderstood then. I was saying that it seems to behave basically like Java. Is that a bug?

V has global consts, they are immutable, but can be initialized with complex expressions, for example `const x = foo()` There's a bug that allows to trick the compiler and modify the const via another variable, it's a one line fix, and will be fixed today. Global mutable variables are only allowed with `-enable-globals` and are supposed to be used only in low level code, like drivers and kernels.

How's that "one line" fix in the type checker coming? Looks like it wasn't fixed yesterday.
Post reply on HN