What don't you like about V / what would you like to be changed?

[medvednikov]

After 0.4, we'll be going for 1.0 right away, freezing the syntax, similar to what Go did.

So if something has to be changed, now is the time to do it.

Please post your criticisms of V, there's a good chance that things you don't like will be fixed/improved.

[danieldaeschle]

What i like:

• Error handling
• sum types and smart casts ;D
• the way how it is developed (community etc)
• all what is not in my changelist

What should be changed imho:

• remove fmt space before ? on my_fun() ? - it's still ugly in my eyes.
• We need better approaches for option types / initialize option types as variables (would be good for empty sum types): x := ?Expr(none) instead of x := Expr{}
• Make option types generic (e.g. generics in builtin). Joe said that works even with cached modules. So i would go for it!
• we need a language specification
• A better name for "option" since it's called both "optional" and "option". i don't like any of them. in haskell it's called "Maybe", but there are other good words as well.
• error codes for our errors (diagnostic information: error codes #7290)
• Error nodes instead of exit on error in parser (poisoning PoC: poisoning #7236)
• test code coverage (Add code coverage functionality #7249)
• custom attributes (Proposal for typed attributes #7014)
  • use them in vweb / http/server
• remove all compiler magic in vweb and make them V features
  • vweb shouldn't require init_once (and the other method) methods. it should be optional. could be fixed using an is check functionality in vweb code
  • I've made a webframework once. So i know some design priciples and can help there
  • finalize the vweb template i've made some time ago
  • replace $vweb.html() with a more generic method (i think we have something there, right?)
  • once i talked with spy about how compile time functions work. he said that it's a really big hack how they work. maybe we can reinvent them?
• we definitely have to change how if and match expressions are generated. (cgen of match expr #4401, result should be true, with autofree result is false #7337)
• println should have an argument of an interface Stringer or something (which has the .str() method). the we can remove compiler magic on print functions.
• we need closures soon

i hope i covered everything. otherwise i will extend this list.

[lammel]

Thinking more about it, I think merging optional results for error handling and trying to reuse that for option types should be separated. This will make it easier to make option types more generic and easy to use.

[crthpl]

we need a language specification

won't that come from freezing the syntax anyway?

[JalonSolov]

It will certainly be easier to write once the syntax is frozen. I shudder to think of the amount of extra work it would have taken to create the document first, then keep it in sync with all the code changes.

[ZargorNET]

I am really agreeing with you on the first two points! I hope they make it into the final language, because the ? with a space before it, seems really off there like a mistype and Expr{} intuitively seems like a struct that is initialized but empty.

And to the error code thing, one could consider making a Rust-like system where the error id is referencing/linking on a webpage, where all codes are listed with some basic examples. See here

[medvednikov]

the space before ? will be removed

[div72]

@danieldaeschle's list is quite well, however I still have a few things to ask for

For V itself:

• Error handling for multiple statements ({ os.read_bytes('a') os.read_bytes('b')} or { panic('!') })
• Ability to drop {} for single statements in or blocks (os.read_bytes('a') or [byte(0)])
• Shortcut for panic (os.read_bytes('a')!)
• Better checks for when reference heavy code is used
• Operator overload for ==, <, >, >=, <=
• sets and the ability to use ranges outside for loops(also step with ranges)
• (if possible) Generators
• Easy binary serialization

For vlib

This portion could be done after 0.3 as no syntax changes are needed. Just wanted to see your opinion.

• os.Path, or something like python's pathlib
• Windows Registry module
• Improvements for the log module(like logger names for example)
• Better support for compression types

[danieldaeschle]

but the syntax has two variants anyway. still against one-way.

[cristian-ilies-vasile]

{} - help detecting begin/end of scope. Are OK.

[JalonSolov]

... and that makes it faster to parse, which is always good.

[spytheman]

What do you mean by compression types ?

[Delta456]

Operator overload for ==, <, >, >=, <= is implement now 😄

[pavi2410]

I would request you to reconsider default function arguments. It has a lot of utility while avoiding code duplication. This will specially help as there is no function overloading. This will also make the standard library less bloated.

[lammel]

Mixing positional and named arguments is never a good idea IMHO. For me it reduces readability of the code and will make tooling a lot harder.

[wanton7]

Related Go info

golang/go#21909 (comment)

This feature was deliberately omitted. See the discussion in talks/golang.org/2012/splash.article about default arguments. They are a bad idea as they make it much easier to build confusing functions that complicate the API.

https://talks.golang.org/2012/splash.article

One feature missing from Go is that it does not support default function arguments. This was a deliberate simplification. Experience tells us that defaulted arguments make it too easy to patch over API design flaws by adding more arguments, resulting in too many arguments with interactions that are difficult to disentangle or even understand. The lack of default arguments requires more functions or methods to be defined, as one function cannot hold the entire interface, but that leads to a clearer API that is easier to understand. Those functions all need separate names, too, which makes it clear which combinations exist, as well as encouraging more thought about naming, a critical aspect of clarity and readability.

One mitigating factor for the lack of default arguments is that Go has easy-to-use, type-safe support for variadic functions.

golang/go#12854 (proposal: spec: type inferred composite literals)

[timbasel]

Maybe using anonymous structs could mitigate this.

fn create_button(text string, { active bool, raised bool = false }) {
     // `text`, `active` and `raised` defined
}

create_button("name", { active: true, raised: true }) 

It would work in exactly the same way as config ButtonConfig does, in that it is just another positional parameter, but it would define the struct fields in function scope.

And if you want to have it as a struct, you could just add a name in front.

fn create_button(text  string, config { active bool, raised bool = false }) {
     // `text` and `config` defined
}

[ken0x0a]

I think, config structs with Editor extension can be a solution for this.
hover action, auto completion, suggestion, e.t.c,

Of course, python like function arguments is super flexible and nice sometime,
but that make multiple ways, and add complexity.

Don't give us preference.
Stick to one way is much easier to read, understand, and write.

I love Vlang's simplicity, so I prefer not to provide another way.

[rempas]

Maybe using anonymous structs could mitigate this.

fn create_button(text string, { active bool, raised bool = false }) {
     // `text`, `active` and `raised` defined
}

create_button("name", { active: true, raised: true }) 

It would work in exactly the same way as config ButtonConfig does, in that it is just another positional parameter, but it would define the struct fields in function scope.

And if you want to have it as a struct, you could just add a name in front.

fn create_button(text  string, config { active bool, raised bool = false }) {
     // `text` and `config` defined
}

Yeah but this will create a struct right? Which will be slower than If we had normal arguments. Also in the name of an anonymous struct, how would we access the fields? Just with their names as if they were variables? You can start to see the weak points of this approach... It's much more complicated to design and implement and it will result in a slower program.

[cristian-ilies-vasile]

My very subjective ideas are:

//A constants declaration
as is

const (
	pi    = 3.14
	e     = 2.718281828459045
)

to be

const {
	pi    = 3.14
        e     = e_init()
}

//B << operator
<< operator does not fit at all in the language philosophy

// C logical operators
as is

!      logical NOT
&&     logical AND
||     logical OR
!=     logical XOR

to be

NOT    logical NOT
AND    logical AND
OR     logical OR
XOR    logical XOR    

[gustavofo]

I love the third point, you guys should rethink. Nobody writing && thinks "double ampersand", just make it readable.

[Cons-Cat]

I love the third point, you guys should rethink. Nobody writing && thinks "double ampersand", just make it readable.

Typescript's sum type syntax (by extension V) uses & and | for "intersection" and "union" which are often named "and" and "or" in other contexts. The symbols make that less confusing because the only words in a sum type definition are type names, but the logic behind that doesn't make sense when & and | do not represent and and or. V doesn't have intersection sums, and maybe it never will, but it does have union sums.

EDIT: Just occurred to me that bitwise operators are another point for consistency.

[gustavofo]

I love the third point, you guys should rethink. Nobody writing && thinks "double ampersand", just make it readable.

Typescript's sum type syntax (by extension V) uses & and | for "intersection" and "union" which are often named "and" and "or" in other contexts. The symbols make that less confusing because the only words in a sum type definition are type names, but the logic behind that doesn't make sense when & and | do not represent and and or. V doesn't have intersection sums, and maybe it never will, but it does have union sums.

EDIT: Just occurred to me that bitwise operators are another point for consistency.

You have a point about consistency, leaving it as a syntactic sugar at least sounds good.

[Wajinn]

This has a point in the context that the & and != are used in various ways in V. So not, and, or, xor could make a greater distinction in usage and clarity. The thing is, maybe ! , &&, ||, != has already taken hold too deeply (in addition as a carry over from C style thinking) .

[Kyllingene]

V really isn't trying to be the next Python, so changing all the boolean operators to be words seems out-of-place. From my experience, V is trying to be more like the good parts of C mixed with the good parts of Go. I use Python regularly, but still prefer the && syntax for languages like this.

[danieldaeschle]

Something like pythons python -m mymod to execute installed modules.

[pavi2410]

A special __main__.py file is executed for python.

I hate this thing. Makes it so complicated.

[div72]

@spytheman That's for running the file normally python script.py vs import script

[Delta456]

I think the function should be init.

[div72]

I am very against making the function init, init is reserved for module imports so it would conflict with that.

[danieldaeschle]

Path to the main module in v.mod like
path: cmd/v

[Ekopalypse]

What are you thinking about chained comparison?
Like x < y < z

[danieldaeschle]

i think we forbid this with a reason.

[Ekopalypse]

Do you know the reason?

[danieldaeschle]

too complex

[Delta456]

It can be unreadable and also goes against one way of philosophy.

[hernaneche]

Why not initialize with simple = automatically at first appearance, instead of requiring := ?

A thing that I find somewhat contradictory is to need types "after varname", except when using mut, which has to be "before varname".

Why not let the types come before or after the var name, as a user choice rather than a required order?

[div72]

Disagree with the second point, makes parsing more complicated and is against the one way rule.

[JalonSolov]

And types are always "after varname". Adding mut in front doesn't change that.

[Kyllingene]

When the compiler can always tell when you should have a := instead of a =, it seems to me that the := operator is redundant.

[Larpon]

When the compiler can always tell when you should have a := instead of a =, it seems to me that the := operator is redundant.

:= is declaration
= is assignment

So they're not the same thing.

I find it extremely useful (especially for your mental context) to be able to tell the difference.
When debugging large code bases it really makes a difference IMO.

By simply looking at a := b or a = b your know instantly if a has been used/referenced before the line you're looking at.

[dedesite]

I understand the need to differentiate declaration and assignment, but in a language like V with multiple assignment possible it is sometimes problematic.
For example, it is not possilbe to do that:

mut a := 10
a, b = 20, 30

or that :

mut a := 10
a, b := 20, 30

Ok I can use a temporary variable... :)

[finomeng]

hello all, really thanks for the excellent language!

I am working on Linux kernel (with real-time extension: Preempt-RT or Xenomai )and driver development for hard real-time control system, so I hope V to be a "modern C", can 100% replace C in low level , the first layer over hardware.

the missing part:

*) Data structure alignment: support enforce data structure padding&packing&align manually. This feature is need due to hardware's register are fixed already, software need follow the hardware spec when define a struct/array for register set. Also need by cache line fits.

https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Common-Type-Attributes.html#Common-Type-Attributes

*) sperate API for creation of real threads and co-routine: real threads are needed by time critical code (e.g. hard realtime OS); co-routines are for non-realtime code.

nice to have if possiable:

*) stack size estimation at compile time:

maybe with certain limits (e.g. don't allow variable logic arrays, disable recursion...), stack size can be estimation at compile time, avoiding stack overflow and gain good performance by avoiding dynamic stack size allocation (as Go's design);

performance is important for hard real-time system (Preempt-RT Linux, Xenomai, Vxworks and other RTOS), latency/jitter is < 10us on a fine tuned x86_64 CPU, so they need avoid dynamic memory allocation in the realtime loop.

various embedded system with small memory may also benefits.

Thanks & best regards,

fino/

[lammel]

The keywords for async operations based on a dedicated threads should be readable and self-explainatory.
Words that may be used are probably async, go, coro, thread and some more.

// For co-routing use go or async
go { println("run in co-routine scheduler") }
// For threads use a dedicated keyword (may require params or attributes)
thread { println("run in dedicated thread') }

But for 0.3 there will be quite some experiments and discussions I guess.

[KeyWeeUsr]

I would rather not see go as a keyword. Seems to resemble a goto keyword with a rather contradictory functionality and async/await is much more used nowadays, so the switch between languages would be way more seamless.

[JalonSolov]

go is used in the Go language to spawn goroutines (co-routines), so similar idea, and it is another statically-typed language. Both Go and V also have goto.

The languages that use async/await are dynamically-typed languages.

It all depends on which type of language you are more used to used, as to which you prefer.

[dedesite]

async/await is not about dynamically or statically type languages. It is just not the same feature as co-routines.
async/await allows you to easily manage asynchronous execution on the same thread, whereas co-routines create a sub thread.

[wanton7]

@JalonSolov

The languages that use async/await are dynamically-typed languages.

First language to have async/await is C# and it's surely not a dynamically-typed language.

@dedesite

async/await allows you to easily manage asynchronous execution on the same thread, whereas co-routines create a sub thread.

That is completely up to the implementation of async (scheduler and runtime). For example with C#'s default scheduler when async yields and returns it can return using a different thread.

[evs-chris]

My personal list from what I've found playing around, beyond what I've seen above:

• Multiple type parameters, preferably with constraints
• A more compact and connected function type syntax

A bit more iffy:

• The ability to use universal call syntax with locally defined or imported functions for imported or built-in types e.g. define map for the option type and call it against an optional.

[penguindark]

'Gated' arrays
I prorose to add the #3008
negative indexes using a tag before the array symbol:
The "new" proposal is to add # before the square bracket in the slice to use the slice with negative index and boud safe as described before.

a:='0123456789'
assert a#[..20]=='0123456789' // true
assert a#[-20..]=='0123456789' // true
assert a#[-4..20]=='6789' // true
assert a#[20..]=='' // true, it never return an error, it return an empty array.

a[-4..20] ==> ERROR
a[20..] ==> ERROR // without gate symbol the behaviour will be the usually

where the # symbol can be the indicator for "safe but slower" operations 😉
The symbol must be decided.

[Delta456]

Or I think we can allow negative indexes inside unsafe:

a:='0123456789'
unsafe {
     assert a[..20]=='0123456789' // true
     assert a[-20..]=='0123456789' // true
     assert a[-4..20]=='6789' // true
     assert a[20..]=='' // true, it never return an error, it return an empty array
}

a[-4..20] ==> ERROR
a[20..] ==> ERROR // without gate symbol the behaviour will be the usually

[abdulbadii]

Excellent!

[ntrel]

@Delta456 unsafe should be kept for memory-safety only, otherwise you will get unchecked memory-safety when using it for other reasons.

[igotfr]

it would better a behaviour like Python for negative numbers in Ranges

[JalonSolov]

No, it wouldn't. At the very least, a lot of extra runtime checks that aren't there now would have to be added.

[penguindark]

Struct Memory Layout
Mantain the memory layout of the structs:

Struct A{
 a int
 b int
}

Struct B{
 a f32
 b int
}

v1 := A{b:1} // A b's displacement  in memory is 4
v2 := B{b:1} // B b's displacement  in memory is 4

This feature is needed to use V for low level in OS and system programming

[danieldaeschle]

i don't get it?

[penguindark]

In simple words: to preserve the order of the vars in a struct like they are written in the declaration.

[Larpon]

Yes to avoid padding memory

[spytheman]

I think V already preserves it 🤔 . Is there something I am missing?

[elimisteve]

Yeah I thought V already worked like this.

[insberr]

It would be nice if you could do something like import './path/to/some/file.v' to import a file as a module.

[spytheman]

In V, you always import whole modules, NOT single files.

[jordan-bonecutter]

As a V noob, how would one import a module in a remote directory?

[KeyWeeUsr]

I'm not quite sure what would be the use-case though except that "Go has it". Relying on Internet to be there so that you can import a remote module isn't the smartest thing to do. Intranet however might kind-of work, but from my experience that's even less stable than Internet (especially with proxies/VPNs), so imo just use curl/wget and import the normal way.

[insberr]

@spytheman

In V, you always import whole modules, NOT single files.

Maybe path to folder where the whole module is located?
So importing a whole module, but being able to specify the directory it’s located at?

Like for a module named example
import './path/to/module/example'

[Cons-Cat]

Maybe an attribute that allows mutable fixed-length arrays? I feel that in some cases, being able to confidently assume that an array is on stack and has a fixed length can make data easier to reason about. So perhaps:

[fixed]
mut arr := []int{ 2, 0 }

arr[0] = 4  // valid
arr << 4    // compile error

[spytheman]

Fixed arrays on the stack can be modified, for example:

mut f := [1,2,3]!!
f[0] = 10
eprintln('f: $f')

[spytheman]

also attributes inside function bodies look weird and will complicate parsing

[Cons-Cat]

Ahh, that's really cool! The !! doesn't seem to be in the docs, but it works in my command prompt. I did get this error:

>>> eprintln('f: $f')
cgen error: could not generate string method void_str for type 'void'

It looks like it does work this way:

>>> println(f)
[10, 2, 3]

And then attempting to push an element gives an unexpected kind of error, but that's okay. I don't usually care about whether I have a correct type of error if I know it shouldn't work either way.

>>> f << 23
error: invalid operation: shift of type `[3]int`
    7 | mut f := [1,2,3]!!
    8 | f[0] = 10
    9 | f << 23
      | ^

Thanks for the info!

[litenite42]

iirc, !! is a shorthand that is supposed to be removed at some point. It was a hack from the very early days of V. Maybe Alex's view on this has changed since last I saw on Discord though.

[fnetX]

I know this might create a heated discussion, but I'd love to be allowed to use

if (a == b) {
  //
}

.

I know this is against the "one way to do things" philosophy and I completely understand that point of view and the reasons for not allowing this, but I think most people are used to doing it this way and probably all or most new V developers will run into this 'feature' of V. We're a team and just checking if V is for us, and all of us are annoyed by this behaviour. In our opinion it also makes sense to wrap a condition in brackets.

By the way, why is this possible:

fn main() {
	a := 3
	b := 3 
	if a == b && b > 2 {
		println("yo")
	}
	if (a == b) && b > 2 {
		println("yep")
	}
}

? The brackets aren't necessary - but they do improve readability. And I know cases where there will be an improvement to readability when you wrap one single condition in brackets as well.

So I propose: Please allow brackets around conditions, even if they are not necessary.

Thank you a lot for that nice language nevertheless!

[medvednikov]

@lammel yes, vfmt will keep the newlines.

@fnetX the new generation of languages uses if x {: Go, Rust, Swift.

if (x) { was used only because one statement blocks could be defined without {}. There's no need in () now, and it's important for gofmt/vfmt to remove the unnecessary parentheses so that people coming from C/C++ adapt to this style. Especially for V, with its obsession over "one way".

Click on "format" in the Go playground:

https://play.golang.org/p/TyiiZyneHbE

Do you mean it can already be allowed right here

I meant to say that I'm ok with removing this error, and shifting this entirely to vfmt, just like how it works in Go.

[fnetX]

if (x) { was used only because one statement blocks could be defined without {}. There's no need in () now, and it's important for gofmt/vfmt to remove the unnecessary parentheses so that people coming from C/C++ adapt to this style. Especially for V, with its obsession over "one way".

Oh, that makes sense now! Well, the discussion I intended was actually more related to whether if c {} or if (c) {} should be the preferred way. I can understand that you went for the first one and if devs like me are requested to adapt to that new style, the current way is probably the better one.

I don't really care if the compiler allows the brackets or not, I think it might be a benefit (at leat to give a warning, so as a new V dev you can see if your logic works and correct the formatting issue later ...), but I'm okay if you leave it as-is.

Thank you for considering this and the fast replies!

[Ben-Fields]

If if (((x))) {} is allowed, it should be because parentheses group boolean expressions, and it's slightly confusing to disable that functionality in a certain scenario. As has been said above, I don't think allowing the outside parentheses should be done specifically to accommodate programming styles from other languages.

vfmt correctly keeps the ordering of the inner expressions and even redundant parenthesis in terms of order of operations (ex. if a && (b && c) {}. This is important as the readability of the expression is context-dependent. The only thing vfmt should do that it does not currently, in my opinion, is remove stacked parenthesis (ex. if a && ((b && c)) {} should format to the former).

[wenq1]

Why not let it happen by a simple '-allow-brackets' compiler flag (or more accurately checker flag)?

[Wertzui123]

Because V programs should normally compile and run without any additional flags (as there should only be one way to do something).

[Jarred-Sumner]

Feature request: Overloadable array indexing

numpy's ndarray library is likely a big part of what made Python the most popular language for machine learning/research. It works by representing n-dimensional arrays as a single array where each column has a stride and (optionally) an offset, so pixels[10,2] is actually pixels[20]. This is much faster for large matrices & grids of data than storing multidimensional arrays as arrays of pointers.

If a struct could overload indexing, that would make great syntax for a version of ndarray for v. This is important for machine learning and games where you need to read, write, and iterate through large matrices/grids of data as quickly as possible.

Example syntax:

voxels := ndarray([1,2,3,4,5,6,7,8,9], [3,3,3])

assert voxels[0,0,0] == 1
assert voxels[0,0,1] == 2
assert voxels[0,0,2] == 3
assert voxels[0,0,0..2] == [1,2,3]

For serialization, you often need to support runtime editable strides/offsets, which limits the amount of compiler magic one can do.

[Jarred-Sumner]

In addition to n-dimensional arrays, this would also enable easier access for compressed data. Say you had a run-length encoded array of values (so [1,1,1,1,1,3,3,3,3] is stored as [1,4,3,4]). You could have a struct that lazily decompresses the data, meaning array[2] would return 1 using the same syntax as a normal array without having to decode the entire array.

[elimisteve]

Clever; I like it 👍

[igotfr]

why?

assert voxels[0,0,0] == 1

and not?

assert voxels[0,0] == 1

[KieranP]

Just spent a few days over the weekend creating a version of Conways Game of Life in V (https://github.com/KieranP/Game-Of-Life-Implementations/tree/master/v). Overall, very good first impression. Couple of things I noted:

• There are still quite a few ways to get compile errors or segfaults that aren't caught by the V syntax checker. Took some trial and error to get the right syntax for what I was trying to do sometimes. Naturally, these compile errors will lessen as the project matures.

• No support for named arguments or default argument values on functions. I understand these have been discussed before and declined, and that the suggested work around is using structs, but first class support would be nice.

pub fn multiply(x int, y int = x) int {
  return x * y
}

multiply(1, 2)
multiply(2)           // suggested
multiply(x: 1, y: 2) // suggested
multiply(x: 1)       // suggested

• Syntax inconsistencies, namely mut something := 0 vs

struct {
pub mut:
 something = 0
mut:
 other = 0
}

Would recommend keeping it the same style as assignments, e.g.

struct {
  pub mut something = 0
  mut other = 0
}

• I quite enjoy Ruby's ability to not have to write "return" in every function at the end. The result of the last line becomes the return value. Would be nice to see a similar pattern in V, e.g.

pub fn multiply(x int, y int) int {
  x * y
}

[JalonSolov]

The other bits have already been discussed, so I'll only mention the one here...

struct {
pub mut:
 something = 0
mut:
 other = 0
}

vs

struct {
  pub mut something = 0
  mut other = 0
}

this has come up on discord discussions before... sure, it does seem like this is a simpler syntax... but only on very simple structs. Take this idea, and then think about what it looks like if you have 50, or 100, or more fields in your struct.

It also isn't inconsistent, if you think about the fact that declaring fields in a struct is a different operation from declaring variables in a function. Field declarations are only declaring the layout of the struct, which doesn't really exist anywhere until you create an instance of the struct.

You also don't use the = 0 on fields - V will complain about it if you do - unless you are setting a non-zero default. You do have to use := 0 on variables, since they don't have a default.

[nmsobri]

I hate it when language dictates me on how to name a variable.. why I cant name variable using camelCase? i don't get it

[nmsobri]

Wait what? go have opinionated formatting, but it doesn't dictate the variable naming casing.. having opinionated formatting is ok, but forcing its user to use certain case for variable name just doesn't make sense..even golang doesn't do that..I didn't said any form of opionated style is bad, just variable casing is ridiculous to say the least.. If you want to avoid the mess, just use linters

In the amount of time spent on this thread, you could have gotten used to the naming, and moved on...

What is that suppose to mean.. @medvednikov open this thread to ask what user don't like.. so I just said what I don't like.. If you don't agree with me, move along then..

[igotfr]

a warning would be enough

[medvednikov]

warnings are errors when using -prod

[igotfr]

warnings are errors when using -prod

the the difference is that it doesn't prevent me from continuing to produce

[JalonSolov]

No, it would just force you to rename everything before you use -prod.

[soldate]

Hello everyone,

in the examples/http_server.v (some parts below)

The struct ExampleHandler is defined empty only to implement the "handle" method

i think its too ugly.. by the way the "h" is not used but needs to be declared: "fn (h ExampleHandler)"

i think 2 possible solutions:

1. ExampleHandler implements handle method
   struct ExampleHandler {
   fn handle(req Request) Response {...} // use this or self if necessary
   }

or

2. do not create ExampleHandler at all

fn handle(req Request) Response {...} // remove (h ExampleHandler)

mut server := Server{
handler: handle // remove ExampleHandler and put method name
}

---

examples/http_server.v

struct ExampleHandler {}

fn (h ExampleHandler) handle(req Request) Response {...}

...
fn main() {
mut server := Server{
handler: ExampleHandler{}
}
server.listen_and_serve()
}

[TenTypekMatus]

Firstly, thanks to everyone who contributed to this project. The simplicity of language and the fact that it's compiled makes it number 1 where applicable.
Adding macros when [translated] flag is enabled, since V doesn't fully understand macros. Also, you should create official packages for Linux distros. V is unofficially packaged on AUR, and I also made a package for Debian-based distros, though the version is 0.3.2, which is EOL.

[JalonSolov]

V isn't ready to be officially packaged. The packages that do exist were created by enthusiasts, but most have not been maintained.

[Wajinn]

Care is needed concerning the large number of accumulated user facing changes that happen over time to the language. Perhaps clarity and emphasis on changes to the language that don't affect or impact code written by the users, versus those that do.

A good example is vrobot, which I like. Each new version of V required updates, and not everyone can keep up. The bigger the project, the harder it is. For myself, I had some significant sized projects for V 0.2 that were hellish to get working in V 0.3 (for all sorts of reasons). But, we are talking going from alpha to beta. And expect much of the same when V 0.4 comes, but who knows, might be pleasantly surprised (with how much easier).

Various people might be waiting for more stability from V. As 0.3.x is beta, hopefully we are getting close. The V community should want enthusiasts to keep coming out with great projects to put up on Awesome-V and VPM.

[alfu32]

Call me crazy but I would like to see variable width integers and uints like they have in zig ( which has i1…i8….i65535). If that’s too complicated maybe at least variable width ints in multiples of 8 bits.

[alfu32]

… and I really feel that I have to say it 👍 you guys have definitely done an awesome job with vlang and it’s ecosystem. Thank you for the tremendous work you’re doing !

[pd-giz-dave]

What I like: nearly everything
What I do not like:

1. auto corecion between float and integer, can be dangerous e.g. a := 5 / 10; if a == 0.5 {never true}, prefer compile time error
2. no corecion or casting from f64 to f32 - its just precision loss, integer division causes worse precision loss
   I'm a V newby, the above is what has tripped me up so far.

[dumblob]

@pd-giz-dave

ad 1) yes, that is a known issue yet solving this one would probably require some messy rules hard to remember with only dubious results (it would cover only certain cases creating even more subtle for mistakes and confusion and surprises)

ad 2) indeed, this is something I was advocating some years ago (see also my related extensive rant about floats in V) - yet as far as I remember, the contra-argument was that it is a too common operation to enforce explicit coercion/casting

[pd-giz-dave]

It would be nice if there was a built-in function similar to the Python breakpoint() function.
I find that useful to catch issues at run-time without having to start the process in debug-mode (e.g. as a 'hack' before and error() call so I can take a look see)

[elimisteve]

Someone wrote a Go debugger that lets you set breakpoints by creating the line _ = "breakpoint". That also seems like a reasonable solution, though theirs was hacked on later and maybe a native breakpoint() function would indeed be better.

[JalonSolov]

V has this now, with the $dbg statement. https://github.com/vlang/v/blob/master/doc/docs.md#debugger

[MarkusSagen]

Starting of, I'm loving the language and have been wishing for a language with the best of golang, rust but simpler and cleaner with a large standard library and one way to do things.

I'm coming from a python background and would like to complement and eventually replace python services with vlang. It fits the need perfectly: simple and easy to learn, similar syntax, sensible default for membership checks, quick scripting, but compiled and type checked.

Some things that I would love to see and make it more viable to introduce to our company is:

1. Structured logging:
   Setting a good default for this early on is something I think hampers a lot of great languages and is vital in production. Golang has recently realised this. When running locally, you want a clear and easy to read log trace, but when deployed, logs should by able to be sent as valid json. This is expected by Grafana and Loki and other monitoring services. I think there is a lot go get inspiration from, and the slog in golang is not ideal, but still a good standard to follow. Some python libraries with good structured logging as examples: structlog, loguru, sentry article of different slog libraries in python
2. Yaml parser:
   Vlang already has support for great json and toml parsers, though far more complex, it would be great to have a good default for all things yaml in language as well.
3. Hierarchical project configuration:
   One of those things that most larger projects inevitably uses. Both for managing complexity, user options, but also for structuring modules and features. From golang, think Viper, or rust config and python has (my favorites) Omegaconf and Hydra. What I find so great about the later is that one can define resolvers, functions that should read and parse values from yaml files at runtime, re-use and override other yaml configs and define functions and methods to execute. With vlang, this could potentially be done at compile time to verify that the setup works.
4. More work on vweb:
   In a ideal world, would like to see it being a bit easier and feature complete and not have to re-use a lot of code between projects. Thinking here something similar to Go's Gin or Gorilla
5. Method for setting manual debug breakpoints:
   Ability to set manual breakpoints in your code, similar to python's pdb
6. Go and Python (and maybe Rust) interopt?:
   (Long shot) One of the biggest hinderance of adopting new frameworks and languages are the packages and lack of echo system around a language. Both Golang, Python have a lot of support behind them when developers are releasing APIs and new libraries. I do not know the complexity and feasibility of this! Having such an option, I think would make it both easier to transition gradually to Vlang and add as a new language in companies

[JalonSolov]

For 2. see https://github.com/prantlf/v-yaml - an attempt at this.

For 6. V has C interop, which means both Python and Rust work, and Go works via cgo. I doubt V will ever implement direct interop with these languages, as they are just too different.

[MarkusSagen]

Thank you for your reply @JalonSolov
I was not aware of https://github.com/prantlf/v-yaml but will check it out

[avram-at-hazel]

I would love to see the match statement become more powerful by offering pattern matching with destructuring, similar to Haskell/Ocaml/Rust.
i.e.

// Array or Slice matching
match some_array {
   [] {
      // matches an empty array
      println("can't have an empty array")
   }
   [x] {
      // matches an array with just one item
      do_something(x) // access to destructed variables
   }
   [x, y] {
      // matches an array with only two items
      do_something_else(x, y)
   }
   [x, _, ...rest] {
      // matches an array with 3 or more items
      // we don't need the 2nd item, just the first item and 3...last (an array)
      some_other_thing(x, rest)
   }
   else {
      whatever(some_array)
   }
}

// Struct matching
struct Point {
   x int
   y int
}

p := Point {
   x: 10
   y: 20
}
match p {
   { x: 0, y: 0 } { println("At the origin") }
   { x, y: 0 } { println("On the x axis at ${x}") }
   { x: 0, y } { println("On the y axis at ${y}") }
   { x, y } { println("On neither axis: (${x}, ${y})") }
}

[toihr]

As i outlined in a previous post here, as a physicist who wants to easily write vectorized code. SIMD intrinsics like Julias . syntax. Would be greatly appreciated.

[TheOnlySilverClaw]

I'm mostly surprised by how many things "just work".
Channels and closures made implementing asynchronous callbacks for C functions such a breeze.
Thanks for that! 😄

But since I'm doing a lot of resource cleanup currently, the sheer verbosity of defer syntax is annoying.
I was expecting it to work like Go or Zig, where you just write
defer resource.free()

Instead there's defer-blocks. Fine, the extra brackets wouldn't have bothered me too much.
But then vftm insist on formatting them over 3 lines.
So about 20% of lines in my renderer code are just those defer blocks:

https://gitlab.com/valdala/valdala/-/blob/6be4385efd7bd3470010355f594345307ace6b8e/application/graphics/renderer.v

And I can't wrap my head around why the syntax is like that.
Nearly all use cases for defer only require a single statement.
And for the few remaining ones, you could still use a block or just several defers.

And one more nitpick about vfmt:
I wish it would stop removing lines between method signature and body. That's a noticable readability issue for me.

[TheOnlySilverClaw]

Sounds both fine to me. 😄

[medvednikov]

@TheOnlySilverClaw done

1b5af1f

[medvednikov]

There's a new vfmt test that shows off new defer behavior:

fn foo() {}
fn bar() {}

fn nested_match() {
	defer { foo() }
	defer {
		foo()
		bar()
	}
	defer {
		foo()
	}
}

[TheOnlySilverClaw]

Nice! Just got rid of 30 lines of whitespace. :)

Now I suppose it's too much to ask for the brackets around defer and or blocks to be removed for single statements?
Are those for consistency or to make life easier for the parser?

[medvednikov]

Yeah it's the same with if ... { }

They're required, unlike in C.

[sprappcom]

1. no large financial backers to take this on like golang to be a real serious enterprise contender in real world serious usage
2. lack of actual production use ecosystem (https speciflcally)
3. need a real life web framework to be developed for optimum speed for real world use. with this, a lot of modules can be developed coz a lot of real serious programmers are looking for a golang replacement that is also zero allocation.

not trolling but frustrated because been following vlang since 2019 and real life example production use is still not happening.

we need 1. and 3. so more serious use can be done on it.

a) e.g. gofiber, gnet, hertz golang, are some of the proj that drives golang dev.
b) at this stage, as long as there's some major "project" (not kubernetes) that can move vlang forward. the adoption for enterprise use will be great.

language wise, once major enterprise serious use-case scenarios are done, i'm sure large corp's "serious" advisor / serious dev / researcher can help bring this language to the next level.

it's 0.4 now but i hope it stays below 1.0 for at least 3 years until someone strong in enterprise area can really help define the steps forward.

i'm a golang dev extremely frustrated with the allocation of golang. hope vlang can be a rust replacement.

[sprappcom]

oh by the way, someone should expand pico to make it https and use sharedhashfile for the memory backing and make this a web framework and that'll be something. stop telling people to use nginx / caddy frontend but integrate with existing c https module and make it a standalone fastest web server framework, which is currently dethroned by gnet golang.

p.s. : pls forgive my harsh attitude but i'm really looking forward to vlang being more widely adopted after 5 years.

[sprappcom]

1. coz vlang adoption is so slow, i guess it's also great if someone can do some gpu examples for AI use since AI is everything now.
2. need a real world use is important. pico on techempower benchmark got me vlang's attention. if not for pico, i wont even notice vlang. how about making vlang a real web framework and not the toy vweb thing? it's really slow. cant anyone develop it with pico? xvweb <- not sure how slow it is too.

[medvednikov]

x.vweb which is now veb is built on top of pico.v

[axetroy]

1. Stop investing time and energy in vlang's peripheral products(UI/editor/Unix/Git and etc...) and focus on vlang's core (parser/formatter/checker/compiler/routine/std/autofree)
2. Select one or two areas for in-depth development as ecological features, eg. web and AI

Vlang seems to be involved in all fields, but it is not perfect in any field. At least for now, it is just a toy.

eg. HTTP currently does not support streaming sending and reading. There is too little support for encryption algorithms in the standard library, etc.

Put the limited energy into important things. Otherwise, it may take another 10 years for vlang 1.0 to be released. Who will remember vlang by then?

Refer to zig, which has not yet released 1.0, but already has a mature community and products.

[louis77]

This. Attention should be on the language and the stdlib, not side projects like yet-another-OS, text editors etc.

Veb is the right direction, we need production-ready TCP/HTTP, database drivers and BSD support.

[JalonSolov]

Well, looked at another way, if you only concentrate on the language and it's libs, how do you show it off?

"Look! I've made this great language! I don't have any examples to show you how great it is, but trust me - it's great!"

[medvednikov]

Vinix is written only by osdev people. They have never touched vlang/v and never will. People in open source work on what they like.

[MarcusMWilliams]

Nothing

…

On Tue, May 21, 2024, 10:51 AM Alexander Medvednikov < ***@***.***> wrote: x.vweb which is now veb is built on top of pico.v — Reply to this email directly, view it on GitHub <#7610 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ASHJW54ZOE765CXXUMDFF7TZDNUORAVCNFSM4VKY2OA2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TSNJRGA2DKNY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>