I'm a bit impressed by vlang, despite some earlier controversy from years ago. Of all the new languages, I have been keeping track of this one the most. They have also been maintaining a strong development pace. Something else that I like that many don't know or notice is their connection to Oberon (a kind of successor language to Pascal). It's a nice merge between various ideas and useful qualities among Pascal/Oberon, C, and Go.

Having used Native Oberon, and followed up on most of its derived languages, I fail to see the relation with Oberon in any of those languages.

Go being the exception as it uses Oberon-2 method syntax, an unsafe package similar to SYSTEM, and Robert Griesemer designed Oberon-V for his PhD.

I'm referring to a more superficial and subtle influence, and V also has other influences (like C) and Go, but if you are working with it then you will notice them. Some are: 1) Uses modules 2) Declarations made at the top (no headers, so more like the Pascal family) 3) Types are indicated after, not before like in the Pascal family as oppose to C (fn foo(a int, b string)). 4) ":=" uses the walrus (visitor := ['Tom', 'Jake', 'Harry']) 5) Use of .. for subrange, etc...

It's debatably enough for those that know Oberon/Pascal to feel more comfortable. You can see the purposeful blending of various qualities of the languages.

Been keeping an eye on vlang since its initial post here (and the subsequent flame war) on HN. The initial language feature list was pretty ambitious.

Seems like they're taking a batteries included approach in trying to bring in as many use cases as possible using libraries written in V.

How are they progressing towards their promises for vlang in terms of base language features as a systems language ? I remember reading they still had some unsafe stuff going on that needed fixing

Pretty cool to see Vinix running Doom now: https://www.youtube.com/watch?v=PDzw3M6Qj9Y

Wow, native (somewhat) GUI already.

>> V UI is licensed under GPL3. A commercial license will be available. Open-source projects will have access to the commercial license for free. Every single feature will be open-sourced right away and available under both licenses. At some point in the future the library will be relicensed under MIT.

It'd be nice to see a commercial license.

Would like to add that I do like the V UI.

We are talking about a cross platform UI with no dependencies, that was made to integrate from its early stages. This is partly why V is distinguishing itself from the pack.

Yeah, I find the initial choice of license on V UI to be a bit weird. Not understanding the logic behind it, when the main and other parts are MIT, as a GPL UI is a definite way to go down the road of massive headaches, drama, and confusion. GPL can give an unfriendly impression to those they probably could use help or support from.

It's still the early stages of the library and the language, so maybe it won't turn into some kind of mess. Possibly, they may have to do some rewrites of existing libraries. Still, it is a curious choice not to at least go LGPL, like many other projects have done who went down that GNU path. Seems like LGPL would have been the right balance to prevent sending mixed or "warning" signals.

There is also VIUP (https://github.com/kjlaw89/viup), which is a port of IUP. So, it's not like more adventurous types can't go play with that. That's under the friendlier MIT license.

I'm a bit torn between these as none is suiting all of my needs:

http://ecere.org/ https://haxe.org/ https://dlang.org/ and ofc ... https://vlang.io/

All can compile to C and I find it somewhat important as would be very happy to share same code base with microcontrollers (SDCC), Android, Linux, Windows and web wasm. Unfortunately (to my knowledge) not all offer optional or selective garbage collection, some look immature and so on :-(

Sounds like nim is the perfect fit for your usecase. https://nim-lang.org

It can also compiles to c, c++, obj-c and js...plus it has an official jetbrains plugin.

Nim works great on microcontrollers. I'm using it with a goal of sharing codebases on embedded and not. It's awesome to be able to write some POSIX network code test it on Linux and get it running on an MCU.

The new ARC garbage collector fits the domain well. The non-atomic reference counting makes it predictable and deterministic. Though, it's possible to write Nim without using the GC or turn it off completely.

NIM looks really amazing, and I mean it. Only thing that stops me from using it is that indentation hell. Can't understand regime enforced on devs to format code in only small number of predefined ways.

Enforcing a certain format is the best way to avoid bikeshedding and focus on writing code.

True, but this can be achieved with more flexibility using formatting tools and a config file as opposed to being enforced at the language level.

I see you've never had to work on a project with other people who don't use the same formatter as you.

V does have an optional garbage collected mode. Just compile your program with: v -gc boehm file.v

Take a look at Nelua: https://nelua.io

You might like it.

Maybe nim then? Compiles to C and has a sort of optional GC in that you can configure it to do plain reference counting.

Mentioned earlier, NIM looks very mature and I like it in sense of what you can already do with it. Unfortunately indentation based scopes is something that I can't stand in programming language

Put me also in the group of those not feeling nim. Sad they decided to go the Python route of white space insanity.

Have you actually worked with an indentation-based language?

I did and hated every minute of it. Automatic formatting is fine but if you don't indent while working it can get ambiguous and format your code wrongly. Also it's harder to visually parse.

So yes I did and no, your subjective tastes aren't an objective reality. What's your point?

> if you don't indent while working it can get ambiguous

And if you don't write braces in a language that uses braces, it will also get ambiguous. What's your point?

> Also it's harder to visually parse.

I know that ease of reading is subjective, but I still find it weird that a human finds this:

    a { b { c; d { e } } f }

easier to parse than this:

    a:
      b:
        c
        d:
          e
      f

> your subjective tastes aren't an objective reality

I'm not the one who used the word "insanity" for the block delimiting system I don't like.

> What's your point?

You shouldn't disregard a language just for superficial syntax features.

> And if you don't write braces in a language that uses braces, it will also get ambiguous. What's your point?

Not when they are mandatory, which they are in a number of languages (also the "do" / "end" blocks). You have no choice but to write valid code. I prefer it that way. Zero ambiguity.

> a { b { c; d { e } } f }

Whoever writes such code should be shot. There are newlines for a reason. And I am glad we have format-on-save these days. Less bikeshedding, exactly of the kind we're doing right now.

> easier to parse than this:

It's not for me, and not for one big chunk of the programmers. ¯\_(ツ)_/¯

> You shouldn't disregard a language just for superficial syntax features.

Daily productivity that is taking a nose dive due to constant fight with a system my brain doesn't want to work with is not superficial. That's like trying to tighten screws with two sticks -- it can likely be made to work, but it can take a long time and will be unproductive.

You've inspired me to create this: https://github.com/xigoi/nimdenter/

>Whoever writes such code should be shot. There are newlines for a reason. And I am glad we have format-on-save these days. Less bikeshedding, exactly of the kind we're doing right now.

So do you use indentation or braces to read code? If the former, what are you complaining about? If the latter, why would you use a tool that adds indentation when you already have braces?

I am not "complaining" about anything. I am expressing preferences.

There were online examples where people don't indent Python code as they go and then saving the file invokes LSP's auto-format which severely botched the code logic (and it was hard to spot). Seeing one such occurrence immediately triggers my alarms: I want to write code and be productive and not squint at whether I am at the right indentation level all the time.

I understand and respect that you may like that style, but also understand and respect that others don't. It's partially about preference. "Different strokes, for different folks".

> It's not for me, and not for one big chunk of the programmers. ¯\_(ツ)_/¯

Agreed.

> Daily productivity that is taking a nose dive due to constant fight with a system my brain doesn't want to work with is not superficial.

Truth. That's just the reality of how a lot of folks feel about it.

No optional GC:

https://ziglang.org/

no C backend unfortunately

Anything that can target Wasm can target C.

https://webassembly.github.io/wabt/doc/wasm2c.1.html

I thought of that solution, but the problem is that when you have 8bit microcontroller and all your operations from webassembly are translated to 32 bit operations then you gonna end up doing 8 bit math on 32 bit emulated math operations aligned back to 8 bit. :(

You should see how it works in practice.

Not try to discount your goals, but chasing 8 bits is anachronistic, an ESP32-C3 is a single core 160Mhz risc-v chip with 400KB of on chip ram for $1 qty 1.

Rust can target AVR directly, https://www.avr-rust.com/

Wasm runtimes also available for embedded platforms, https://github.com/wasm3/wasm3

once it will get to 0.05$ - 0.10$ will stop chasing 8 bit :-) Right next to me have 130 boards with 8bit :-)

Speaking from Timex 2068 experience point of view, I doubt C is much better than just using a proper macro assembler.

under development actually. The language devs are planing to use the c backend for bootstraping the self compling zig compiler which is in works

I think it was me asking for it like a year ago onzig github issuees :)

D can make use of -DbetterC, -v to track allocations, call GC.disable(), or just place a @nogc on the modules you don't want a GC running.

Rust had compile to C. It does wasm. No GC. Much safer than most everything except Pony and arguably Idris.

Edit: IIRC, there is a wasm2c program that might work.

This is what spooks me out most for now: https://github.com/vlang/v/issues It looks like a lot of non trivial issues. Other than that I like the concept of V. Maybe except one small thing ":=" ;-)

D does not compile to c, and has garbage collection.

Looks like it does, sort of... https://forum.dlang.org/thread/cweufizceawykuglbara@forum.dl...

D has a BetterC mode without garbage collection

https://dlang.org/spec/betterc.html

It had optional GC.

I have been playing with it, and it is fine.

I run into particular issues with some things, but they are usually easy to figure out or seek help on.

I do like the syntax and installing packages, e.g.:

  v install ui

Is there a version of the language spec of this? It seems to me that to ensure continued evolution and development of the language, it would be good to get some of the basics set up ..

What is the cross platform GUI like? Its amazing to me these guys have one but .NET doesn't. Maybe I can wrap my .NET libraries in V?