This blog post showcases V in a positive light. I suppose it is good that people can have productive experiences with it now, although I don't see from this post why it is a significant improvement on Go.
The problems discussed (performance, compiler fragility) are somewhat worrying though. My impression is still that V is not particularly robust and focuses on flashy things instead of getting the basics right. I must admit that it is however still hard to look at V objectively, given the near-fradulent presentation it had when it was first announced.
"near-fradulent presentation it had when it was first announced"?
It's not just in the past, the lies are still here. A very simple to explain example: https://vlang.io/ proudly says "No null (allowed in unsafe code)", while going to V playground and typing
x := []&int { len: 10, cap: 0 }; println(x[4])
still prints "&nil" (note how there is no unsafe in sight).
The V team are either intentionally misleading people or have only vague idea about how languages are designed. Stay away.
Such code will generate warnings, "arrays of references need to be initialized right away, therefore `len:` cannot be used (unless inside `unsafe`, or if you also use `init:`)". By the way, the other optional parameter, besides `len` and `cap`, is `init` (in the documentation too). The person is being told to use unsafe or do something else.
Warnings are given to allow the programmer to experiment or solve by other methods. Beta means language still in development. Lastly and for V, the warnings mean that in production mode (-prod flag), that kind of code will not compile.
When comparing V and Golang, I feel like V serves as a warning for why the Go maintainers say "No" so often. You can see the author being weirdly confused both by bugs and ambiguity in the language.
> This is a double-edged sword, with Go, you get what you got. With V, I got what I got but I wonder if what I got can be gotten differently.
That looks to be a distorted take and for many reasons: (1) Many Golang programmers have heavily criticized or complained about their language[1][2][3][4]. Various Golang developers have recommended or commended Vlang for its different options. (2) The creator and various main developers of Vlang, were themselves professional Golang programmers, who decided they wanted to have different features based on their experiences. Never seen Vlang developers bash Golang or try to inhibit anybody's options, where the reverse professional courtesy is not given.
Golang programmers wanting different features or have rooted for Vlang (in beta):
[1] My Personal Complaints about Programming in Go
I realize you've replied to every comment in this thread that isn't explicitly praising V, I'd discourage that because a cookie cutter response doesn't fit well in a discussion. I'm well aware that when Go maintainers say "No" to features, that they're not shouting into the void, that there are people asking for those features. My argument was not based on popularity at all.
My comment was specific, backed up by evidence and statements from Golang developers, not a cookie cutter response. HN is arguably best served by fair and balanced views.
Speaking of fairness, Golang and other languages have lots of bugs and issues too. Furthermore, what you stated did not align with the overall sentiment expressed by the author of the article. He liked Vlang.
> "I like V a lot. The abstraction over the syntax is so nice that made me enjoy writing the syntax as a whole. It makes me wish that Go could do more with what they have, but you and I know that Go would never." -- Kris Tun
Your comment is copy pasted from the same comment you’ve posted at least 2 other times in the last 24 hours. Thats very much cookie cutter. It’s also not all that relevant to the parent comment, it’s just trying to turn things into a flame war. The comment only expressed that golang’s simplicity has prevented some of the issues they perceive in V, and you’re trying to turn it into some Go vs V and dredging up a bunch of unrelated criticisms of go.
Not every thread needs to be this us vs them mentality with other languages that you bring to the thread.
> Your comment is copy pasted from the same comment you’ve posted
Please don't twist. The response given here were unique statements. It was not copy and pasted from anywhere else.
> When comparing V and Golang....
The original commentator started the comparison. Was just giving a response about that.
> why the Go maintainers say "No" so often
In the counter, showed that many Golang programmers disagreed with the direction or about the features of their language. In various cases, those programmers agreed with or admired the direction or features of Vlang. Additionally, the sentiment expressed by the writer of the article was not that he was against, but rather and overall, he liked Vlang.
People should be allowed to respectfully disagree and also not be forced to go along with any negative narratives. There should be room for different views about topics.
Since you insist on digging deeper, I'll point out some of your tricks.
> Many Golang programmers have heavily criticized or complained about their language
Meaningless statement, because it's true for every language.
> My comment was specific, backed up by evidence and statements from Golang developers, not a cookie cutter response.
You picked articles that support your point and conveniently omitted aritcles that don't. This is called cherry picking.
> Below are examples of fair and real reviewers:
Let me guess, if they share your opinions they are fair and real, but if they don't, they're "direct competitors of V, engaging in very dirty tactics".
> Speaking of fairness, Golang and other languages have lots of bugs and issues too.
I have issues with my finances and Mr. Bezos does too, therefore our issues are the same and equal. This is the Fallacy of Gray.
---
Nobody here is going to fall for basic tricks like only linking to articles that speak positively of V and attempting to play the victim of "harassment" by "competitors" or whatnot. Step up your game ;)
I have used both Go (extensively) and V (not so much). Go's cross compilation, concurrency support, GC & stability are much better than V's. V compiles much much faster in spite of generating C (unless you use clang), plays better with C, its syntax choices seem better (default to const, less onerous error handling, sum types, option type, not relying on Capitalization for exporting etc.), optional GC (though far from perfect), etc. I can see writing an OS in V (but not in Go). I am in two minds about whether it should try to simulate concurrency like Go does (goroutines are coroutines, mapped to system threads only for blocking syscalls) as that might not be the right choice for kernel level code.
V hasn't had the resources or backing that Go continues getting. Most of its work is done by volunteers. AFAIK it hasn't had the benefit of the experience of multiple world class programmers like Go's designers. Good language design also involves leaving out features and that involves discussing or experimenting with such features. IMHO V can use more of that. But so far I like a lot of what I see in V.
On one hand, I think there needs to be an applications programming language that's both fast, statically typed, and minimalistic (like C). C# and Java are unwieldy and carry too much baggage. I hoped Go would be that language. Unfortunately Go's weird choice to use green threads and channels made it very difficult and slow to interop with native code, especially desktop frameworks, which usually rely on a pumped message loop. V was supposed to be that language, that keeps the excellent syntax, but replaces much of the weirdness with much more convenient stuff, while adding a few extra features.
I first learned of V after reading the hit piece someone wrote on it, which has formed the majority of people's opinion's on the language. Back then I though most of the criticisms were unnecessarily harsh and belligerent, most of it boiling down to the compiler/stdlib having bugs, and one asserting that it's 'autofree' implementation leaked memory, based on an incorrect understanding of how valgrind and C memory management works.
I decided to get the truth for myself, and delve into the V language source code (after all, it's up on github). Oh boy.
- The 'compiler' itself doesn't seem to have a a codegen backend, it just produces C code, with every code generation call essentially becoming a stringbuilder concat pushing C code into a buffer. So it's more of a transpiler than a compiler.
- The compiler's code is very worrying - commented out snippets of code, TODOs like 'TODO: this isn't supposed to be null here' over a stray if statement
- The vaunted 'autofree' which (to be fair never claimed to be 100% effective, relying on GC for cases it can't figure out) is just checking objects allocated in the function scope, and frees them at the end of scope. (to be fair, autofree seems to have been deprioritised)
While it works in some cases (including the original critical post where it claimed to fail), and I don't pretend to understand all the nuances of the compiler, I feel like the engineering behind this project is somewhat unsound.
It's super impressive just how much stuff they managed to do over the past few years, and I think a simple and pragmatic desktop language (that produces small binaries, has few dependencies and is easy to write and read) is still needed, I'm kinda reluctant to give V that role until the engineering behind it becomes more solid.
I don't think it's fine the way V does it. What V's compiler is essentially doing is that it parses the V code into an AST, then it walks the AST and tries to generate an equivalent C code on the fly:
How a proper compiler should work (and how they actually do from what I've seen), is that they first take the AST, try to remove all fancy syntatic sugar by converting it to simpler constructs, and then they generate an intermediate representation that's either stack, or SSA based. It might skip the lowering of syntatic sugar, and generate IR directly. At some point either on the AST, or the IR, you might want to do control or data flow analysis to support some of your features.
From that point on, the backend generates either LLVM IR, C or might even attempt to generate machine code itself.
The problem with targeting C is that you lose access to stuff not accessible in C, like precise variable tracking on the heap/stack (needed for a good GC), or unwinding support needed for exceptions.
While I do like Zig, I would prefer automatic memory management for most application code. My priorities there are spending the least amount of effort and complexity on solving the problem, while ensuring the created code is both bug-free and maintainable, and am willing to give up some performance for that compared to raw C speed.
Zig seems to be a step back in that manner, even compared to C++ which at least has unique_ptr/shared_ptr.
For Pascal variants, way back when I used to enjoy writing Delphi, I think it was a great language, however I haven't been keeping up with the Pascal world.
> The change we're talking about automatically invokes Initialize and Finalize on all types for dynamic allocations / destruction, unless they intentionally circumvent it. Intentional circumvention might include allocating raw memory in a class and treating the class like an array with an index property. In other words, if you declare a raw pointer, allocate untyped memory (e.g. bytes), and handle something back from that memory using a typecast, then you are bypassing automatic allocation and destruction.
> All other ways to make space for complex types (records and classes) as well as types which may hold complex types (arrays and nested fields) will safely and reliably use Initialize and Finalize when needed if they are defined.
This is interesting. It's good to read up-to-date impressions of V, considering its shaky beginnings. This describes a more positive experience from mine about a year ago, which is a good sign. I remember running into similar weird errors and undefined behavior, which really put me off from the language.
The problems that V is trying to solve aren't something I find to be dealbreakers with Go. I'm fine with Go's syntax, error handling, lack of bells and whistles, enums, and so on. In fact, I've learned to appreciate the brutalist simplicity of its design. What I do need is a language that is robust, well defined according to its specification, and performs well at most tasks. Go excels at these, while V fumbles at all of them.
How much longer can we excuse these issues on account of it being a young language? V is 6 years old now, yet these issues still exist. The authors and community seem to prioritize writing text editors, kernels, and operating systems over addressing these core issues. And, frankly, I don't trust that things will improve with the current leadership, so I'll continue to stay away and write boring Go code.
> I'm fine with Go's syntax, error handling, lack of bells and whistles, enums, and so on. In fact, I've learned to appreciate the brutalist simplicity of its design.
Assembly language is going to blow your mind; it lacks even more features than Go.
Actually not, if you look into powerful macro assemblers from Amiga/PC heritage, they might even do stuff, Go's designers keep considering as language fluff.
I had a similar thought. Rust's inline assembler is like "Eh, all this boilerplate for platform specific behaviour is annoying, lets just allow people to write the assembly instructions and we'll handle this administrivia for them".
It's like you go to Super Mario World Central, to recapture that experience with finite lives, you download some tricky mods and find... nope, every modern Mario hack removes the lives, even crazy hard Mario like Grand Pooh World 3 does not have lives, because lives suck - very, very difficult Mario is fun, lives are not.
Well clearly not everyone agrees with that position. Everybody has a preference, with various people also saying terrible things about Golang or whatever language. Possibly the better position is that people have options to choose from versus having viable options forcibly or sneakily removed.
1. Whatever this is "fn (lr []Language) total() int {", why is there an ability to define a special function to an array? How do I know what overload is being used? If I change something from map to vector, how do I know there's nothing else that changes? Member function is just a sugar over regular functions? Great, remove member functions.
2. Why allow this? "racket := Language{98, 'racket'}" ? Why implicitly depend on ordering of parameter?
Just use Language { .score = 98, .name = "racket", } Confusing order of evaluation? Great, just force it to be assigned exactly the same as the definition and force ordering that way.
3. Why remove the parenthesises " if l.score > 0 {"? In fact, I would even reject code that assumes any integer != 0 is True. Nope, you have to do the exact check every time. No more if (x) { }
4. Why allow default parameter? Why needing special syntax for @required?
I just want a very limited C with GC, pattern matching and algebraic data types. I don't even need generics.
The paren for the argument to if in C is just there to be able to omit {}. Which is one of the most stupid things in C. Add two characters for ALL if statements to avoid two characters for >1% of if statements. That is a mathematically certain loss.
Of course Go is "ok". It has a very basic type system and some dubious decisions but it also gets a lot right (especially tooling) and clearly has different design goals to the languages you like.
It's not my favourite language by a long shot but it's definitely ok. At least by the standards of most popular languages (Python, Javascript, C++, etc.)
It sounds like you have a very naive view of the real world and maybe need to get some more experience of life. And I mean that in a very patronising way.
I think Go’s more than OK. The language itself isn’t my favorite, but a good stdlib, good tooling, and a fast compilation step makes me reach for it often. I don’t hate it.
This blog post showcases V in a positive light. I suppose it is good that people can have productive experiences with it now, although I don't see from this post why it is a significant improvement on Go.
The problems discussed (performance, compiler fragility) are somewhat worrying though. My impression is still that V is not particularly robust and focuses on flashy things instead of getting the basics right. I must admit that it is however still hard to look at V objectively, given the near-fradulent presentation it had when it was first announced.
"near-fradulent presentation it had when it was first announced"?
It's not just in the past, the lies are still here. A very simple to explain example: https://vlang.io/ proudly says "No null (allowed in unsafe code)", while going to V playground and typing
still prints "&nil" (note how there is no unsafe in sight).The V team are either intentionally misleading people or have only vague idea about how languages are designed. Stay away.
Such code will generate warnings, "arrays of references need to be initialized right away, therefore `len:` cannot be used (unless inside `unsafe`, or if you also use `init:`)". By the way, the other optional parameter, besides `len` and `cap`, is `init` (in the documentation too). The person is being told to use unsafe or do something else.
Warnings are given to allow the programmer to experiment or solve by other methods. Beta means language still in development. Lastly and for V, the warnings mean that in production mode (-prod flag), that kind of code will not compile.
IIRC, it was intentional false advertising and deception. https://xeiaso.net/blog/vlang-update-2020-06-17/
Last I heard in 2024, the situation has not improved
https://news.ycombinator.com/item?id=39503446
When comparing V and Golang, I feel like V serves as a warning for why the Go maintainers say "No" so often. You can see the author being weirdly confused both by bugs and ambiguity in the language.
> This is a double-edged sword, with Go, you get what you got. With V, I got what I got but I wonder if what I got can be gotten differently.
That looks to be a distorted take and for many reasons: (1) Many Golang programmers have heavily criticized or complained about their language[1][2][3][4]. Various Golang developers have recommended or commended Vlang for its different options. (2) The creator and various main developers of Vlang, were themselves professional Golang programmers, who decided they wanted to have different features based on their experiences. Never seen Vlang developers bash Golang or try to inhibit anybody's options, where the reverse professional courtesy is not given.
Golang programmers wanting different features or have rooted for Vlang (in beta):
[1] My Personal Complaints about Programming in Go
https://boyter.org/posts/my-personal-complaints-about-golang...
[2] Is Vlang better than Golang in error handling?
https://towardsdev.com/is-vlang-better-than-golang-in-error-...
[3] Decoding JSON sum types in Go without panicking
(What Go could have been: V lang?)
https://nicolashery.com/decoding-json-sum-types-in-go/
[4] A Proposition For a Better Future For Go
(Proposed the creation of Goatlang and admires Vlang)
https://itnext.io/a-proposition-for-a-better-future-for-go-a...
I realize you've replied to every comment in this thread that isn't explicitly praising V, I'd discourage that because a cookie cutter response doesn't fit well in a discussion. I'm well aware that when Go maintainers say "No" to features, that they're not shouting into the void, that there are people asking for those features. My argument was not based on popularity at all.
My comment was specific, backed up by evidence and statements from Golang developers, not a cookie cutter response. HN is arguably best served by fair and balanced views.
Speaking of fairness, Golang and other languages have lots of bugs and issues too. Furthermore, what you stated did not align with the overall sentiment expressed by the author of the article. He liked Vlang.
> "I like V a lot. The abstraction over the syntax is so nice that made me enjoy writing the syntax as a whole. It makes me wish that Go could do more with what they have, but you and I know that Go would never." -- Kris Tun
Your comment is copy pasted from the same comment you’ve posted at least 2 other times in the last 24 hours. Thats very much cookie cutter. It’s also not all that relevant to the parent comment, it’s just trying to turn things into a flame war. The comment only expressed that golang’s simplicity has prevented some of the issues they perceive in V, and you’re trying to turn it into some Go vs V and dredging up a bunch of unrelated criticisms of go.
Not every thread needs to be this us vs them mentality with other languages that you bring to the thread.
> Your comment is copy pasted from the same comment you’ve posted
Please don't twist. The response given here were unique statements. It was not copy and pasted from anywhere else.
> When comparing V and Golang....
The original commentator started the comparison. Was just giving a response about that.
> why the Go maintainers say "No" so often
In the counter, showed that many Golang programmers disagreed with the direction or about the features of their language. In various cases, those programmers agreed with or admired the direction or features of Vlang. Additionally, the sentiment expressed by the writer of the article was not that he was against, but rather and overall, he liked Vlang.
People should be allowed to respectfully disagree and also not be forced to go along with any negative narratives. There should be room for different views about topics.
Since you insist on digging deeper, I'll point out some of your tricks.
> Many Golang programmers have heavily criticized or complained about their language
Meaningless statement, because it's true for every language.
> My comment was specific, backed up by evidence and statements from Golang developers, not a cookie cutter response.
You picked articles that support your point and conveniently omitted aritcles that don't. This is called cherry picking.
> Below are examples of fair and real reviewers:
Let me guess, if they share your opinions they are fair and real, but if they don't, they're "direct competitors of V, engaging in very dirty tactics".
> Speaking of fairness, Golang and other languages have lots of bugs and issues too.
I have issues with my finances and Mr. Bezos does too, therefore our issues are the same and equal. This is the Fallacy of Gray.
---
Nobody here is going to fall for basic tricks like only linking to articles that speak positively of V and attempting to play the victim of "harassment" by "competitors" or whatnot. Step up your game ;)
I am actually more interested in removing/reducing even more features from Go than adding more features.
I have used both Go (extensively) and V (not so much). Go's cross compilation, concurrency support, GC & stability are much better than V's. V compiles much much faster in spite of generating C (unless you use clang), plays better with C, its syntax choices seem better (default to const, less onerous error handling, sum types, option type, not relying on Capitalization for exporting etc.), optional GC (though far from perfect), etc. I can see writing an OS in V (but not in Go). I am in two minds about whether it should try to simulate concurrency like Go does (goroutines are coroutines, mapped to system threads only for blocking syscalls) as that might not be the right choice for kernel level code.
V hasn't had the resources or backing that Go continues getting. Most of its work is done by volunteers. AFAIK it hasn't had the benefit of the experience of multiple world class programmers like Go's designers. Good language design also involves leaving out features and that involves discussing or experimenting with such features. IMHO V can use more of that. But so far I like a lot of what I see in V.
The author's github activity shows far fewer contributions compared to previous years, looks like a bad sign, anyone know what's happing?
I am of two minds on V
On one hand, I think there needs to be an applications programming language that's both fast, statically typed, and minimalistic (like C). C# and Java are unwieldy and carry too much baggage. I hoped Go would be that language. Unfortunately Go's weird choice to use green threads and channels made it very difficult and slow to interop with native code, especially desktop frameworks, which usually rely on a pumped message loop. V was supposed to be that language, that keeps the excellent syntax, but replaces much of the weirdness with much more convenient stuff, while adding a few extra features.
I first learned of V after reading the hit piece someone wrote on it, which has formed the majority of people's opinion's on the language. Back then I though most of the criticisms were unnecessarily harsh and belligerent, most of it boiling down to the compiler/stdlib having bugs, and one asserting that it's 'autofree' implementation leaked memory, based on an incorrect understanding of how valgrind and C memory management works.
I decided to get the truth for myself, and delve into the V language source code (after all, it's up on github). Oh boy.
- The 'compiler' itself doesn't seem to have a a codegen backend, it just produces C code, with every code generation call essentially becoming a stringbuilder concat pushing C code into a buffer. So it's more of a transpiler than a compiler.
- The compiler's code is very worrying - commented out snippets of code, TODOs like 'TODO: this isn't supposed to be null here' over a stray if statement
- The vaunted 'autofree' which (to be fair never claimed to be 100% effective, relying on GC for cases it can't figure out) is just checking objects allocated in the function scope, and frees them at the end of scope. (to be fair, autofree seems to have been deprioritised)
https://github.com/vlang/v/blob/master/vlib/v/gen/c/autofree...
While it works in some cases (including the original critical post where it claimed to fail), and I don't pretend to understand all the nuances of the compiler, I feel like the engineering behind this project is somewhat unsound.
It's super impressive just how much stuff they managed to do over the past few years, and I think a simple and pragmatic desktop language (that produces small binaries, has few dependencies and is easy to write and read) is still needed, I'm kinda reluctant to give V that role until the engineering behind it becomes more solid.
Generating C is fine tbh. Lots of respectable language implementations do that, or did that at some point in their life.
V has plenty of other issues, though.
I don't think it's fine the way V does it. What V's compiler is essentially doing is that it parses the V code into an AST, then it walks the AST and tries to generate an equivalent C code on the fly:
https://github.com/vlang/v/blob/master/vlib/v/gen/c/match.v
How a proper compiler should work (and how they actually do from what I've seen), is that they first take the AST, try to remove all fancy syntatic sugar by converting it to simpler constructs, and then they generate an intermediate representation that's either stack, or SSA based. It might skip the lowering of syntatic sugar, and generate IR directly. At some point either on the AST, or the IR, you might want to do control or data flow analysis to support some of your features.
From that point on, the backend generates either LLVM IR, C or might even attempt to generate machine code itself.
The problem with targeting C is that you lose access to stuff not accessible in C, like precise variable tracking on the heap/stack (needed for a good GC), or unwinding support needed for exceptions.
> an applications programming language that's both fast, statically typed, and minimalistic
While at it, does Zig fit this bill? (Or, haha, Free Pascal / Lazarus, if we talk about desktop software.)
While I do like Zig, I would prefer automatic memory management for most application code. My priorities there are spending the least amount of effort and complexity on solving the problem, while ensuring the created code is both bug-free and maintainable, and am willing to give up some performance for that compared to raw C speed.
Zig seems to be a step back in that manner, even compared to C++ which at least has unique_ptr/shared_ptr.
For Pascal variants, way back when I used to enjoy writing Delphi, I think it was a great language, however I haven't been keeping up with the Pascal world.
Far too complex, Odin (my favorite language for writing apps in) would align more with minimalistic values.
Lazarus always looked good, so there's probably value there if having a GC isn't an issue.
Lazarus does not have a GC AFAIK, it's manual-free.
It does seem like they somewhat do now, as of the last several years https://wiki.lazarus.freepascal.org/management_operators
From https://news.ycombinator.com/item?id=19100760 since I'm not a Pascal user:
> The change we're talking about automatically invokes Initialize and Finalize on all types for dynamic allocations / destruction, unless they intentionally circumvent it. Intentional circumvention might include allocating raw memory in a class and treating the class like an array with an index property. In other words, if you declare a raw pointer, allocate untyped memory (e.g. bytes), and handle something back from that memory using a typecast, then you are bypassing automatic allocation and destruction.
> All other ways to make space for complex types (records and classes) as well as types which may hold complex types (arrays and nested fields) will safely and reliably use Initialize and Finalize when needed if they are defined.
This is interesting. It's good to read up-to-date impressions of V, considering its shaky beginnings. This describes a more positive experience from mine about a year ago, which is a good sign. I remember running into similar weird errors and undefined behavior, which really put me off from the language.
The problems that V is trying to solve aren't something I find to be dealbreakers with Go. I'm fine with Go's syntax, error handling, lack of bells and whistles, enums, and so on. In fact, I've learned to appreciate the brutalist simplicity of its design. What I do need is a language that is robust, well defined according to its specification, and performs well at most tasks. Go excels at these, while V fumbles at all of them.
How much longer can we excuse these issues on account of it being a young language? V is 6 years old now, yet these issues still exist. The authors and community seem to prioritize writing text editors, kernels, and operating systems over addressing these core issues. And, frankly, I don't trust that things will improve with the current leadership, so I'll continue to stay away and write boring Go code.
> I'm fine with Go's syntax, error handling, lack of bells and whistles, enums, and so on. In fact, I've learned to appreciate the brutalist simplicity of its design.
Assembly language is going to blow your mind; it lacks even more features than Go.
Actually not, if you look into powerful macro assemblers from Amiga/PC heritage, they might even do stuff, Go's designers keep considering as language fluff.
I had a similar thought. Rust's inline assembler is like "Eh, all this boilerplate for platform specific behaviour is annoying, lets just allow people to write the assembly instructions and we'll handle this administrivia for them".
It's like you go to Super Mario World Central, to recapture that experience with finite lives, you download some tricky mods and find... nope, every modern Mario hack removes the lives, even crazy hard Mario like Grand Pooh World 3 does not have lives, because lives suck - very, very difficult Mario is fun, lives are not.
In my opinion (!) vlang is one of the most terrible language experiments ever. Everyone, and definitely the Go team, should say ; yeah let's not.
(!) it is my opinion, I am going from robust principles and foundations; that's not everyone
Well clearly not everyone agrees with that position. Everybody has a preference, with various people also saying terrible things about Golang or whatever language. Possibly the better position is that people have options to choose from versus having viable options forcibly or sneakily removed.
Of course. Hence the EXPLICIT opinion thing.
Another disclaimer: I like Go but i'm not a diehard fan; I will always be common lisp until I die. We all have taste/opinion.
I fail to understand why every single new language tries to be "funny". Lets take a look at this example:
module main
struct Language { pub mut: score int = -1 name string @[required] }
fn (lr []Language) total() int { mut total := 0 for l in lr { if l.score > 0 { total += l.score } }
return total }
fn (lr []Language) average() int { return lr.total() / lr.len }
fn main() { racket := Language{98, 'racket'} // Simple arrays too! langs_arr := [racket, Language{102, 'ocaml'}] println(langs_arr) println(langs_arr.total()) println(langs_arr.average()) }
Remove
1. Whatever this is "fn (lr []Language) total() int {", why is there an ability to define a special function to an array? How do I know what overload is being used? If I change something from map to vector, how do I know there's nothing else that changes? Member function is just a sugar over regular functions? Great, remove member functions.
2. Why allow this? "racket := Language{98, 'racket'}" ? Why implicitly depend on ordering of parameter? Just use Language { .score = 98, .name = "racket", } Confusing order of evaluation? Great, just force it to be assigned exactly the same as the definition and force ordering that way.
3. Why remove the parenthesises " if l.score > 0 {"? In fact, I would even reject code that assumes any integer != 0 is True. Nope, you have to do the exact check every time. No more if (x) { }
4. Why allow default parameter? Why needing special syntax for @required?
I just want a very limited C with GC, pattern matching and algebraic data types. I don't even need generics.
Just because you have reverence for C and C syntax, doesn't mean others have to. What is "funny" is subjective.
Everything you complain about here is straight-up Go syntax.
Mind you, that doesn't prevent Go's syntax from being terribly stupid. They just happen to line up on stupid choices.
The paren for the argument to if in C is just there to be able to omit {}. Which is one of the most stupid things in C. Add two characters for ALL if statements to avoid two characters for >1% of if statements. That is a mathematically certain loss.
[flagged]
Please don't reply to a bad comment with another bad comment.
[flagged]
Please avoid swipes like this when commenting on HN.
Of course Go is "ok". It has a very basic type system and some dubious decisions but it also gets a lot right (especially tooling) and clearly has different design goals to the languages you like.
It's not my favourite language by a long shot but it's definitely ok. At least by the standards of most popular languages (Python, Javascript, C++, etc.)
It sounds like you have a very naive view of the real world and maybe need to get some more experience of life. And I mean that in a very patronising way.
I think Go’s more than OK. The language itself isn’t my favorite, but a good stdlib, good tooling, and a fast compilation step makes me reach for it often. I don’t hate it.