Congrats on releasing V v0.2! It's a great language and the compile times are amazing. My only issue is keeping up with the constantly changing vlib.
Do you have any plans to resume working on Volt (the original V app)? I thought the idea behind it was great, but there hasn't been an update in 1.5 years.
Yes, it has been blocked by the memory management work and the 0.2 release, both of which took a while, especially since most of the compiler had to be re-written from scratch (using an AST). The UI library was also re-written several times as we tried different approaches (native vs custom rendering).
The good news is that Volt was always being updated and made compilable, and a public beta is also coming this month.
I'm already using Volt as my primary Discord client (and my 8 GB RAM laptop thanks me for that, since I've freed 2 GB of RAM).
Have you given any thought to choosing a longer name for the lang? I really hate single letter identifiers. By going to 2 symbols you reduce term overloading by ~35x on average, ~3 you get 1,000x less namespace conflicts.
V avoids doing unnecessary allocations in the first place by using value types, string buffers, promoting a simple abstraction-free code style.
Most objects (~90-100%) are freed by V's autofree engine: the compiler inserts necessary free calls automatically during compilation. Remaining small percentage of objects is freed via reference counting.
The developer doesn't need to change anything in their code. "It just works", like in Python, Go, or Java, except there's no heavy GC tracing everything or expensive RC for each object.
For developers willing to have more low level control, autofree can be disabled with -noautofree.
Note: right now autofree is hidden behind the -autofree flag. It will be enabled by default in V 0.3.
---
So yes, for the ~0-10% of objects not freed by V's autofree, ARC will be used. We will implement weak references and probably have a simple cycle detector, so pretty much a minimal GC.
Unlike in Go or Swift, it won't be used on all objects, but only on the small percentage that couldn't be handled by autofree.
In the YouTube demo I posted, 100% of all allocations in the text editor is handled by autofree.
Sorry but again this is one of those "V can do X (except when it doesn't and i get to define what that means)".
I don't want to be a hater and I'm genuinely impressed by the project. But it's honestly very hard to trust anything about this when all kinds of claims pop up, always with a big caveat at the end, usually after being questioned in forums and not in the official documentation.
What happens today if i don't pass in -autofree? If it was working it would be enabled right? And if it's not working, then how do i code without it? Sure, the language has a 0.x-version number but it's not exactly being advertised as something that is incomplete unless i dig very deep into documentation or twitter-threads. Some kind of roadmap of promised/planned/delivered features would greatly improve the confidence in this being not vaporware.
Congratulations on the release! It looks very interesting. Does the GUI library embed a web-view, or does it use native controls? What's you estimate of when it will be available for Android and iOS?
We are going to support native widgets, for example TextBox will be native due to accessibility and support for Chinese/Japanese/Korean/R2L input.
However things like text rendering will always be handled by the V graphics library, since GDI+ is just way too slow (calculating text bounds is ~10 times slower than in V), and Apple's drawing API is not very nice to use, and it's also 2-3 times slower at rendering text.
> GDI+ is just way too slow (calculating text bounds is ~10 times slower than in V), and Apple's drawing API is not very nice to use, and it's also 2-3 times slower at rendering text.
Does V's text library support the kinds of shaping and nested bidirectional layout needed to render Arabic text? I've heard that's a cause of a lot of complexity and slowness in text rendering, so stripping it out would be an easy performance win for people like me who can't read Arabic anyway.
It's great to see accessibility/compatibility taken into account here, but are you only doing that for the text input or going further? E.g. can I copy text or use a screen reader?
It definitely looks like good progress. You mentioned that DirectX and Metal support have been added; I'm curious why platform-specific APIs were prioritized over Vulkan. Were they actively prioritized for some reason, or did contributors just work on those first?
Makes sense, though I'd dispute that Vulkan is "too complex". It's definitely not simple, but that's because it's a complex problem. The driver guesswork that something like OpenGL uses comes with costs, too.
The way I'd describe what I see from V's author from his two projects (V and Volt/eul) is a continual over-promising and underdelivering - as well as misleading statements (for example, a claim that V is the "fastest on Tech Empower's web framework", which is actually fastest in only plain text (it does not do enough to be qualified on the full leaderboards) on an unofficial run (it is currently 2nd I believe), where it is simply a wrapper around a C server [1][2][3] - which I believe is misleading, even if the C interop is neat). That is not to say he cannot eventually deliver on his promises, but they frequently take years beyond his initial predictions, and sometimes come watered down.
My personal conclusion from my reading was - if you wish to go use V, go ahead, but I'd exercise caution when relying on anything about it.
Just for reference in Techemppwer Benchmark, the same guy who utilizes H2O HTTP source code for benchmarking, wrote h2o.cr for Crystal language and pico.v for V language. It’s isn’t mean for general use in any projects.
This is a set of very biased articles, I mean just look at this for example:
> Git is a dependency, which means perl is a dependency, which means a shell is a dependency, which means glibc is a dependency, which means that a lot of other things (including posix threads) are also dependencies. Pedantically, you could even go as far as saying that you could count the Linux kernel, the processor being used and the like as dependencies, but that's a bit out of scope for this.
What's the point of such nitpicking? You don't need git to use V, and the point of the no dependency claim is that bootstrapping V is as simple as `cc v.c` and the V compiler produces single file binaries, that are easy to deploy, without any dependencies on an interpreter/environment/libs etc.
I'm actually going to write a post debunking all of the claims in these articles, since I see them mentioned quite often (including measuring the compilation speed by using an unoptimized debug build + running vfmt + rebuilding the standard library with each compilation + using a 2x slower backend).
Diving straight in to attack the critic (again) rather than discussing things usefully made it pretty obvious it must be the original developer. You don't generally see two people who behave like that managing to co-exist in the same project.
> without any dependencies on an interpreter/environment/libs etc.
no stake on either side, but the post specifically mentions this (though that was on vlang 0.1)
> I claim that the V compiler has dependencies because it requires other libraries or programs in order to function. For an example, see the output of ldd (a program that lists the dynamically linked dependencies of other programs) on the V compiler and a hello world program:
"I don't view this dependency as a dependency" is ... ok, you can redefine things if you're clear about that, but given you've also argued that "printing to stdout doesn't make a function impure" I think perhaps a glossary of terms that V uses differently would be helpful to understand your claims.
I'd also note that given you then banned her from the issue tracker after that post went up rather than discussing it, your claims of bias on her part seem a trifle strange.
That’s true for Linux and why Go thought they could do this everywhere. It turns out that libc is the only stable interface for a lot of platforms (notably MacOS and many other BSDs if not all).
Correct, on Windows there is no stable syscall interface, same for BSD. Hence you're supposed to link things. But Linux syscall interface is stable and libc is definitely not stable.
didn't mean to argue, just providing context for people scrolling through the comments :) i agree that it's a bit nitpicky. (but "depends only on libc" would probably be a better phrasing)
Sure is nitpicky. When I see some open source software I certainly never see libc mentioned as a dependency. It's just assumed that it is there as part of the OS which it basically is.
How about refuting the memory leaks claim? Or the others in previous posts as well, that were calling out impossible features of the lang (that sounded like some ad)
Well, I will believe it when I see it, as well as the other hard to believe claims like I don’t know how many lines of code/second compilation speed, perfect C-to-V compiler, etc. I’m not sure how many of it is still up on the website, because some were called out and were taken down.
The nearly 1 second compilation is impressive, but why claim it has 0.2 second compile time when using a cache? It doesn’t represent the real-world time it would take to compile v or another program from fresh in order to install it.
I liked the design of V and gave it a try. I quit paying attention when I realized almost nothing worked like it was supposed to. Even hello world was difficult due to needing to configure all sorts of stuff to get tcc and configure it to compile correctly.
Ok, V creator may have an huge ego. Evan Czaplicki (Elm creator) may have an even larger ego. The list goes on. Does it worth to do everything to castrate their ambition? They like to put the bar high. Higher than they can jump most likely but in the meanwhile they build something. Probably not exactly what they proposed to but way more than the ones that criticise them. Criticise with work not with nitpicking, from the outside it resembles envy. Time will certainly judge them and us also.
Disclaimer: I don't know V authors nor I'm part of V community.
There is no controversy but the one you are trying to build up. This language is obvious quite young in development, isn't backed by mega corp Z with billions of $ at its disposal, yet it is trying to manage to find a solution to multiple issues Go couldn't even resolve in 10+ years. cut it some slacks.
It’s fair to try to solve issues. But these are hard issues, and it is at best overconfident to outright say they will do X, when they didn’t even started working on it, and at worse it may be a scam making money from donations, but I am hoping that it is the first case.
> at worse it may be a scam making money from donations
Before making such a rude conjecture, at least check the dev's github page [1] first. Most of his git commits are related to V and he has been actively working on it for a couple of years, even over weekends. V may fail like many new languages, but at least the dev has paid the efforts. He has my respect.
At the start of the project, the source code was not available and I deliberately wrote that I really hope and want to believe that the first option is the correct. Nonetheless, this project did start controversially with absolutely bold claims, other, similarly small languages like zig interestingly doesn’t have bad connotations associated with it.
Hopefully V will be able to shed these and will grow successful.
I mean this without snideness, but I’m constantly amazed at the demand for C-like languages that continue to arrive with every possible combination of features. When I look at V code, it looks barely different than the plethora of options syntactically and semantically. To be sure, it is different, and I get that a lot of programmers find the “no BS minimalism” aspect appealing. (A lot if programmers in fact start a rewrite project with “no BS minimalism”, only to asymptotically recreate the ‘BS’ and destroy the ‘minimalism’.) But I can’t imagine anything being vastly different than any of the other C-likes once your project is big enough, except that V is currently nascent and changing.
I remember eC [1, 2] from Ecere being one such example of an “exciting new C”: it had traditional class-based OO, no header files (!), cross platform, reflection, etc etc etc. It came with a huge runtime library with tons of demos. It started 16 years ago (!!). There’s of course D as well (which is more often pitched as a C++ replacement), and its own Walter Bright frequently seen around here, and some companies use it, but it hasn’t truly exploded into mainstream use.
Can interested folks (or the author) comment? Are you bored and want a fun new take on programming? Or are you truly, in practice, extremely dissatisfied with the current marketplace of C alternatives and V actually is a take that “gets things right”?
> Are you bored and want a fun new take on programming? Or are you truly, in practice, extremely dissatisfied with the current marketplace of C alternatives
I think the reason is something else: It's not the demand that's amazing, it's the supply.
A lot of people like making languages, and full working environments to go with them. It's fun! If you're into that sort of thing, it might be the most attractive kind of project, with a kind of geek gravity that draws you in when you've got the bug.
A new language and its environment is an interesting exercise, even if it takes years. It's something to do to hone your craft. It's not particularly difficult, if you go for it, it just takes time. You can add all those ideas you wish other languages had but never do. Probably if you're into making languages you have a lot of ideas like that.
There's lots of interesting things to learn, lots of puzzles to solve, and then you have an artifact at the end which other people can appreciate. They might even find it useful, which is another reward, another bit of satisfaction.
If that's a major reason for new languages, why C-like?
I think C-like hits a design sweet-spot that is easy to understand and easy to branch out from. But it's also something you know other people are likely to understand and appreciate. It's not too exotic, at least at first glance. With so much supply and a lot less demand, you want your language to be noticed, to be useful and seen as useful. Being C-like boosts chances of acceptance as a language to take that bit more seriously.
I company I worked for a very long time ago wrote a hardware compiler, with a front-end language for hardware called Handel which was a DSL in Standard ML (great language. ML. by the way).
It was used, but it got more popular when they wrote a C-like front end and called it Handel-C. There was no real difference to the language, and Handel-C was in many ways less powerful (because there was no ML with which to manipulate the syntax tree), but the C-like syntax made it a look familiar, and therefore marketable.
I currently work with Zig, which is one of the C-like languages. C has a ton of footguns, and is not easy to parse (due to a lexical macro system). Because of these (and other) properties, I made Zigler (https://www.youtube.com/watch?v=fIxNEILcNGM), which is an automatically recompiling inline FFI system for the Elixir language, it's arguably easier to write correct C FFI functions with Zig as an intermediate than in C itself.
Whenever I hear a new language announced here I ask "what does it offer over OCaml?" Disappointingly often the answer seems to be nothing. At least in the post-Rust world most of the ML featureset is now part of the baseline for people who think they need non-GC or "as fast as possible".
It's normal, people want C like performances, with zero cost abstractions, with memory safety, without the ugliness, unsafe behavior of C. C is a language thought out for 1970 constraints and developers can do better.
Developers won't stop creating languages until something that really succeed in replacing C is created.
Absolutely not! Programming doesn’t need to be stuffy with only “old timer” languages. Maybe 8 years into programming I myself got very much into language and compiler design. I started as most would by making languages which just had different keywords. Then at some point truly ventured off the deep end with languages that include (for example) built-in abstract algebra and symbolic computation. None of my creations would have ever been passed off as being “practical” for any sort of industrial use. The point was that it was fun, and I learned an enormous amount from my own and others’ languages.
And here I thought that I had all of these languages already bookmarked but I never heard of eC before. Thanks for mentioning. It looks very interesting.
There are actually quite a lot of languages that do something in the realm of owning/borrowing, see my link above for a partial list (which includes Nim).
Nim's views (and also their ORC system) is closer to Rust/Swift/C++ than it is to Lobster, in the sense that it is all very explicitly programmer driven with explicit type annotations.
Lobster's system is fully automatic and almost entirely transparent to the user.
Not sure what the "considered harmful" implies here. It's clear what Djikstra meant, and it's not about removing goto altogether. Goto is still used as a best practice in many situations (e.g. error cleanup in the Linux kernel), and is very useful in other domains too (e.g. generated code for parsing, state machines, etc).
As for the vulnerability, while it is real, it's not related to the language.
And not even sure what "I’m staying away from any language with vulnerabilities like these" even means. As if other languages/compilers/etc, even established ones like C/Clang-GCC, Java, Javascript, etc don't have any?
The vulnerability was acknowledged and fixed in 1 day. If that's indicative of the type of response the project's authors have, color me impressed. Also, this post is for version 0.2. I ain't scurred for personal projects.
Author of that secvuln report here. It was fixed by the playground server being decommissioned. I do not know the exact timeframe of any fix that was made to that playground service. Pedantically, I guess the server being permanently decommissioned could count as a fix. However it does not bode well.
It came from the same developer. The mere fact that he was that sloppy in securing a publicly-facing service to leave a vulnerability so severe and so easily discovered should have you asking: why should I believe that anything else in this project is any more robust and secure (and will be in the future)?
Would disagree with "nothing to show for them" though.
The V compiler was written in V from the start at the time of the release, which already shows the maturity of the language, and it did compile itself in less than a second. Bootstrapping it has always been as simple as `cc v.c`. It had a graphics library from the start with a working Tetris game example, hot code reloading, etc
It was definitely rough around the edges due to being a one man project, so it's good that it received help from hundreds of contributors. It's much more stable now.
Bootstrapping the compiler isn't a sign of language maturity. V has changed pretty significantly both in terms of syntax as well as semantics since that release.
Regarding compile times, why do you claim less than one second when your own tracking shows 2.5 seconds and trending upwards? (fast.vlang.io) Aren't you concerned that as the compiler and language are actually implemented, compile times will continue to worsen? Have you considered that perhaps that's why there are so few languages that claim that kind of bootstrap time?
I wonder if vlang may be the No Man's Sky of languages: initial launch over-committed and under-delivered, but steady progress helped build it into a good product. V definitely isn't there yet, and every time I go try it again it seems janky, but I'm glad to see it's making progress.
I'd say Jai is a bit different. No plans to release soon, but will probably be fairly mature when it is, since Jon is writing a real game in it first. I'm seriously excited for it after watching some of his streams.
I saw a quote recently along the lines of "a scientist is someone working on something they know nothing about; an engineer is someone working on something they know everything about." I think the project started out as a science project and is moving the direction of an engineering project. A totally outside perspective—I haven't checked it out in a while.
> an engineer is someone working on something they know everything about.
That seems completely contrary to my engineering training. The engineer motto is about "be prepared for the unexpected" i.e. escape hatches, manual override, overprovisioning, assume that your temporary "train", "power plant", "airplane" will be in service for 40 years instead of 20, make it serviceable even without infrastructure.
I think we're saying the same thing and I just butchered the original quote. having checklists of everything that could go wrong, real and imagined, with senses of probabilities, I would consider "knowing everything about". Or maybe its "knowing what you dont know".
The author made lots of unsubstantiated and even nonsensical promises such as green threads with no runtime or the supposed C++ to V translator which would be a HUGE breakthrough in compiler technology because such a tool would be (as was exactly shown in an example) able to understand programmer's intent.
He just stringed together attractive looking words and phrases without really understanding what they mean.
And of course, none of the promises actually materialized, so either Medvednikov is grossly incompetent or a pathological liar. You decide which is the case.
The language is a fantastic one. I can understand the author putting every library/language/package-manager/examples in V together and trying to bring out a wonderful experience out of a language, but wouldn't it be better if the memory manager is fixed first and foremost.
At the moment its still incomplete. And this is the most interesting part of the whole language. ARC, weak refs, autofree also working together needs to be done, only then will this language be of weight. Garbage collection is a difficult problem to be fair and it definitely determines the performance of many languages. Not to mention multi-threaded GC is difficult. I am excited to see how the author pulls this one through. See you again with V 0.3. Till then best of luck!
Thank you for creating V, you're amazing. There's not many people that could do what you did - both from a technical perspective and from a mental perspective. I feel like you get a lot of hate from jealous haters that can't even fathom having the required mental energy to keep going at such a hard problem, for such a long time, keeping the flame alive. Fuck'em, keep rocking!
Very interesting release. The autorelease is especially noteworthy... also I worry how hard it would be to have more finegrained control over allocations, releasing the memory instantly is not always the most perfomant way. In games for example big (temporary) allocations are often performed in some kind of arena buffer that gets cleared at the end of a frame (NativeArray in Unity does this) and thereby circumvents alot of unnecessary deallocating. How feasible would it be to implement such an allocator in V without losing the autorelease for the other cases?
This language looks very nice, I have been keeping an eye on it. From what I remember there were some issues around memory management without gc, specifically because there were mutable, reference types and multithreading. How does it manage memory? Does it use something like ref counting? Is there any documentation around it?
Be sure to pop into Discord to chat further (https://discord.gg/vlang). You can bring up questions around this with Alex in #v-development and I'm sure others will also chime in.
You can say what you want about this project, but reality is that this is an active open source project. Look at those GitHub stats ... more than 300 contributors, 4000 pull requests.
Maybe this project had a rough start, but right now anyone claiming this is not real should probably re-evaluate those feelings.
You're right but at the same time people also need to evaluate the state of the language with respect to the claims made on the home page.
- autofree not only leaks memory but in some cases causes double frees or use after free resulting in UB. Look at issues tagged autofree on their repo.
- No UB is claimed but the compiler does nothing to stop you from doing it and V is a very thin layer on top of C so it's trivial to cause UB. Signed integer overflow in V: instant UB.
- hot code reloading literally just overwrites the library in memory as the application is running. Better hope your compiler laid everything out exactly the same way or it will segfault and it usually does.
- Generics. Only one type argument is supported. The built in std types don't even use them because the implementation is so broken.
- option types: why have Some(T) | None when you can mix error handling in too and have Some(T) | None | Error(E)? That's right, option types three values. (Tri-state booleans anyone?)
- Compilation speed: V translates to C and then runs a C compiler. V isn't going to compile any faster than your C will. The only reasons that it's pretty fast right now are because most programs are very small and so is the std library and because they use tcc which performs no optimizations at all. If you want your C code to compile as fast as V does, just use tcc.
- Runtime speed: No rigorous benchmarks have been done. The claim of within 3% is a goal they have no idea how to achieve. Given their memory system relies on ref counting and optimizing out increments and decrements, they won't be able to hit that only taking memory management into account. Other design aspects have serious implications in terms of performance such as array copying being implicit. (b = a) copies all of a into a new array.
This is fine for a learning experience and I hope everyone involved is learning a lot but pitching this as some kind of project that people should learn and write real code in is crazy.
It sounds like you know a lot about language design, so why not file a few issues or make a contribution?
Why was it necessary to create a temporary account to write your post? I can probably guess who you are since there are only a few folks really vocal and on some kind of personal mission to shoot this down at every opportunity. What a waste of time. What a sad thing to do to an open source project.
I have tried this before and generally the response to my issues has been "this will be fixed" with no further explanation that would allow having a discussion and thinking through the soundness of the idea of even letting someone other than the author take a stab at implementing it.
Even for critical things like the memory management strategy, no one other than Alex has any idea how it is supposed to work (beyond some references to Lobster). Even when it's pointed out that Lobster makes some concessions that V does not so that the memory management system can work, there is still no discussion.
The V community and team seem far more interested in generating hype and publicity than actually doing the hard parts of language design.
I don't actually think the community is trying to be malicious. If you hang out in their discord, they're generally quite friendly. What they lack is focus.
The language and canonical backends aren't anywhere close to complete and there's already attention bring split to build an x86_64 backend and a wasm backend. Neither of these are anything more than toys even in comparison to the C one. At the same time, std is lacking critical things like a map type that doesn't require your keys to be strings. And yet they're working on a discord client and a websocket implementation. V-os and v-browser are seriously discussed with promises like "we'll start on that after 0.3".
V is sort of the ultimate yack shave. The author wanted to make a thin discord client but first they needed a new text editor so then they needed a language to write it in. It's really only a matter of time before the next project comes up and the author leaves V in the same state as his other projects.
Indeed, we now use tcc for dev builds. Our own version of tcc is prebuilt and distributed, so you don't even need a C compiler to start developing in V.
overpromising and underdelivering != con artist, though I do understand where you're coming from as the very initial (postponed) release and asking for donation gave a scam feel.
1. Will they be as heavy as Go's ? Go has 2 mutexes and some other fluff
2. Are they "close-safe" like, if I send something to the channel, and it is nil or closed, will it panic crash or stuck forever like Go does, or V is trying to be "panic-free"? Will "prohibited" operation return an error or panic/stuck?
3. If channels are closeable, will I be able to close them twice without panic (closing closed door might creak, but IMHO should not burn the house down...)
(At some point in the past I did suggest adding an error to channel operations so it will not panic if I am ready to intercept an error, but that was rejected)
Hello, I'm the one who has implemented channels for V, so I'll try to answer these questions:
1. "Heavy" is a vague term and I think that it is even used polemically here. Every channel implementation needs methods to avoid race conditions and I think Go uses what is needed for reliable operation, but not more (even when there is a "mutex" in their code it's not a real OS-mutex - Go's channel implementation is actually very efficient). V's implementation uses mostly atomics and sometimes spin-locks.
2. There are no "nil-channels" in V, but a channel can be closed. As in Go, just sending to a closed channel causes a panic - that's a design decision. The point is: not to panic requires some kind of error handling. In a language like C++ this can be done by throwing an exception (which has to be caught elsewhere). But neither Go nor V have exception (that is also a design decision). In V a failure due to a closed channel can be trapped using `or` (https://github.com/vlang/v/blob/master/doc/docs.md#syntax-an...) on the receiving side or by using `select` (https://github.com/vlang/v/blob/master/doc/docs.md#channel-s...) on the sending side or the receiving side.
3. Closing an already closed channel should not cause any panic.
1. I would politely disagree with Go channels are efficient. If they would be efficient, they would be actively used internally as a synchronization primitive. I don't remember seeing external libraries using it past notification mechanism of "it is done" kind either. There would be some nifty tricks possible if cost of channels is much lower, or compiler would be able to use some "very light" channels if it sees it is possible (not sure if it even theoretically possible, but I am not an CS theory guru...)
2. That's kind of unfortunate, I would prefer if error is requested, just return an error
err := ch <- data_to_send
vs
ch <- data_to_send
which might panic. But looks like neither of languages allow this. I proposed the syntax above to Go, but it was rejected.
3. That's nice. Is there an error to catch if needed?
1. There are some principle limits to take into account:
Channel operations involve task switches - especially on unbuffered channels. How expensive these are depends on the scheduler, but basically they are expensive on all operating systems.
Other synchronization primitives (like mutexes, semaphores, atomics) can be implemented in a way that the scheduler is not involved when no (long) blocking is needed (futex, spin-locks, ...).
The Go people took the path to implement their own scheduler, which is highly optimized for channel operations, on top of the OS (similar to a virtual machine). So, they don't use OS-threads or OS-mutexes. This does result in better channel performance, but still there are task switches. And this approach has other drawbacks concerning C interoperability.
V sticks to OS-threads and the OS-scheduler (and not re-implementing these could be called "lightweight"). This means better C interoperability but channel operations are even more expensive.
shared x := ...
go f(shared x)
lock x {
// modify x
}
rlock x {
// read x
}
2./3. Syntax considerations should be consistent within the whole language. As @illuminate has already pointed out we discuss these things on discord (https://discord.gg/vlang). There's also a channel #syntax.
I need to find it, but I remember it was "we discussed it, and no, we decided not to" sort of answer there. There is also earlier explanations (from Rob Pike I think?) that was "we did not like how it looks like, couldn't find a nice looking syntax". The whole discussion left me with a bit of eery feeling, and left me with a bit of a sour taste (together with "error handling" one that I kind of tried to participate in). I pretty much stopped actively following golang-nuts after that, and now only look at proposals through meeting notes that Russ posts on github [1], where you can see accepted/not accepted status immediately.
Btw, there is another saga (drama?) unfolding on github proposal discussions over sum types [2], and judging by the past experience I don't have high hopes for it to get into the language.
Cool, I thought earlier versions were partially closed source and I was curious. This is really high level work. Nice job. How many languages have you designed/implemented?
One thing V gets right is not requiring a keyword (e.g. “let”) for initializing an immutable variable. This is such a common operation that it should be as compact and non-visual-noisy as possible (Huffman coding). (Personally I’d go for “=“ instead of “:=“ though, for ease of typing.)
I’m aware of the trade-offs. :) I’d rather use a digraph operator for mutating assignment, again with the Huffman coding argument. One design I’m thinking of is using “@” as the mutable qualifier (e.g. “@int” is a mutable int), and correspondingly use “@=” for mutating assignment. (The swirl in the “@” glyph is meant to allude to mutation, and it’s a character that visually stands out in code, as mutation should.)
Very excited about this release.
This is the first major release after 0.1.
The focus has been on stability and compile-time memory management. The demo of that was posted here recently [0].
7600 commits, 4110 handled pull requests, 340 contributors, 20k GitHub stars. What a journey!
[0]: https://www.youtube.com/watch?v=gmB8ea8uLsM