Has Vala seen much activity recently? The last time I remember hearing about it was reading a blog post from one of the main GNOME developers (https://www.bassi.io/articles/2017/02/13/on-vala/) saying that Vala was basically being maintained by a single developer and he didn't recommend using it for new development.
Vala is very much used among other things by Frida.
I have been involved with Vala in it’s early day and some hardcore GObject/C users never quite liked the C code that Vala generated although it was perfectly valid and exposed a very clean C header to interface with it.
I think that Vala is a really great tool for building applications that make use of Glib/GObject. For example Gtk applications, but also GStreamer and DBus applications.
To be fair, how many developers are even writing GTK applications anymore? How many GUI apps are even using these native GUI frameworks?
If you aren't developing a DAW, a browser, or some other performance critical GUI app, you're moving to Electron and other layout engine solutions. And who should blame you, people don't want to fiddle with GTK_Window_Context_Handler* gtk_wdw_ctx_hdlr_ptr = Init_GTK_Window_Context_Handler(Window_Context* w_ctx); just to make a damn app.
Even if Vala drops in to save us all from noodling with Window Context Rocket Ship Handlers, layout engines are more portable solutions. The decline of WPF and Winforms is proof of this.
the answer could possibly anyone who cares about the footprint of their software (disk, egress, image running size...), not wanting to deal with an entire browser engine (in every aspect)
wpf is still heavily used in industry so that isnt very convincing to me
Also heavily used in the industry are toolkits like sciter, which give you HTML/CSS UIs without an entire browser engine underneath. I suspect those will be eating the remaining market share for 'traditional' toolkits, simply because it's the dominant UI paradigm.
a) being able to deploy same codebase on web and desktop
b) reusing the vast selection of libraries for web
c) tapping the large amount of trained developers.
Sciter fails on a) and b), because it doesn't support even such a basic and widely used feature as CSS flex (they have something similar, but incompatible).
I'm currently working on a Sciter-like solution that does support widely used CSS features such as Flexbox, CSS Grid, Media Queries, CSS Variables, etc. Although we're not planning to ship a JS engine: scripting will be with Rust that compiles to WASM when running on web.
Binary sizes are currently around ~12mb which isn't as good as Sciter but is quite a bit better than Electron.
> being able to deploy same codebase on web and desktop
Desktop UI and Web UI models are so different that in reality you cannot use the same codebase on 100% in both targets.
Web UI uses traditional Web's "endless tape" model where only width is known. This does not really work on desktop where width and height are finite. See this Sciter based app https://notes.sciter.com/ as an example.
> reusing the vast selection of libraries for web
If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
If you set the height of your body element to 100vh (100dvh in the case of iPhones), then the web acts like the desktop in this regard. They’re different since the tooling is different but not because they’re essentially different.
> If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
iframes are very constrained in what you can do, if you’re targeting the web from the start you get the full power of using those libraries beyond the bounds of a single frame.
> Desktop UI and Web UI models are so different that in reality you cannot use the same codebase on 100% in both targets.
I develop an Electron app and the CSS is 100% same on both web and desktop. It's not a "web page", it's an app, which doesn't use the "endless tape" model.
> If you do need this then you can use Sciter's WebView that is a <frame> backed by system browser:
At that point it seems easier to just use something like Tauri which uses the system browser for all rendering.
Regarding CSS and layout in general, there is a concept of sizers and spacers in wxWidgets that makes layout far easier to grok for the average dev. That being said, it does (sadly) add to code bloat which is where CSS excels, IMO.
Thanks for that! That sounds very sane. I agree that dragging an entire browser engine just to have a desktop app is excessive -- less code is always better.
> In almost 10 years, Sciter UI engine has become the secret weapon of success for some of the most prominent antivirus products on the market: Norton Antivirus and Internet Security, Comodo Internet Security, ESET Antivirus, BitDefender Antivirus, and others. The use of HTML/CSS has allowed their UI to stay in touch with modern GUI trends throughout all these years, and will continue to well into the future.
Made me laugh a bit, I usually find antivirus softwares out of touch with good design and really impractical due to that.
i actually am working on greenfield wpf currently but ill be first to admit thats an exception.
windows shop still reach for it heavily in "boring" industry in my experience.
there is a difference between performance critical and sloppy of course. most people default to heavy crap cuz its good enough, or a good fit sometimes, i get that
and this is coming from someone who had to use wpf for software where it ended up too slow in all rendering paths despite MS "trust us bro" and had to render using directx directly. not super uncommon but we were paying the price early (.net fw 3, fuzy wpf text, vibrating layouts, the good days)
No, that‘s very common. I‘m peripherally involved in such a greenfield project, too. And my employer is (very) slowly switching existing WinForms applications to WPF. It‘s the new thing.
(I know that there are a handful newer MS GUI frameworks, but for us it‘s new)
outbound bandwidth on say, "cloud" providers like aws. it can be very expensive. we have been actively reducing our installer sizes, for our costs (edge, cdn, some internal egresses), customer bandwidth, and basically giving a shit and doing a decent job. rare stuff these days
This is a very shallow opinion. I, personally, avoid electron-js apps like the plague. Having 500 MB of RAM wasted by something as trivial as MS Teams or Insomnia is horrendous.
ElectronJS apps tend to be not only inefficient but also much less reliable and poorly designed.
No, your opinion is out of touch. The companies that release these programs don’t care about 500 mb being wasted. What is your mom using? Very likely bloated software she unwittingly installed.
Look around, it’s a bloated, buggy world. Calendar apps aren’t being carefully engineered by European computer scientists.
>Electron apps tend to be poorly designed
How so, are you saying because they use Electron they’re inherently poorly designed?
> How so, are you saying because they use Electron they’re inherently poorly designed?
I’m not the original commenter, but Electron apps are regularly poorly designed and lacking quality. I won’t say it’s inherent to Electron, but it’s largely due to the fact that the standard controls offered by browser engines are incredibly rudimentary. They are still catered primarily to forms and simple interactivity in a document.
Rich interactivity requires you build your own or find some third-party package, whereas at this point most desktop UI toolkits have 20-30 years of development and refinement behind them.
Panels and panes are resizable and collapsible; you can have multiple free-floating, smoothly resizing windows; collections/tables will efficiently reuse cells to avoid tanking performance on long or infinitely scrolling lists.
All of this stuff is possible with Electron I’m sure, but the platform doesn’t offer it for the taking, so most don’t bother. And when they do, it’s less refined than what we had in desktop apps in 2005.
The real reason people stopped developing Gtk applications is that GNOME tends to declare widely used APIs arbitrarily as "internal interface" and makes incompatible changes even on minor version updates.
It's a constant chase not worth any developers time.
Precisely this, the moment they announced they wanted to break backwards compatibility with new GTK versions every 6 months or whatever it was they made it very clear it is exclusively a Gnome API for OSS projects and nothing else.
They backtracked a bit on that but they'll still replace GTK4 with GTK5 at some point, probably deprecating context menus or whatever else this time. Clowns.
The first release of GTK3 that could be considered stable was 3.20. Either way, I'm talking about GTK4, where the original plan was 6 months of breaking releases, stabilization in version 4.6, followed by starting work on the incompatible GTK5, to be released 2 years after the first GTK4 release.
The backlash was so big they at least changed the versioning scheme, but the "break shit every 2 years" is still in full force.
GTK3 did not break its C API. The CSS you could inject was arbitrary and undocumented. They stabilized and documented that in 3.20, yes. I think its very dishonest to say the toolkit was breaking, the vast majority of GTK3 apps didn’t have regressions IME.
And even if you want to keep it non-web, I don't see why you'd use gtk instead of qt (especially since QT has pyside6). And I'm not saying that as someone who likes QT either. I wish I started my PoC with web tech from the get go actually. But still, it's so much more convenient and even if you stick with c++ QT still provides a lot of nice to have tools (for threading, signals, concurrency etc).
I haven't used qml a lot but I wonder if gtk has an equivalent to that too. What am I missing about gtk here? Like, where does GTK beat qt?
C API is the big one. Unless your language is officially supported by Qt (meaning C++ or Python) you're basically screwed.
Secondly would be the license, while they're both LGPL these days, that wasn't always the case, and the current Qt company is highly hostile to open source.
There are a lot of third-party Linux apps built with GTK4/Libadwaita. If you just to to https://flathub.org and click on random apps a lot of them will use GTK.
I tried to learn GTK a few years ago, because I wanted to create an app that was fast, snappy and looked "native" on Linux.
But I was unable to find information about how to set up my repo and build process with GTK vendored into the project. All tutorials said that I should just install GTK libraries with my system package manager, but that was not a satisfactory answer for me.
After some hours
fiddling around stackoverflow, adding flags to my GCC invocation and being unable to solve the problem, I just gave up.
Flutter Desktop seems like a compelling alternative to GTK these days.
I have no issue with it using GTK under the hood, as long as it doesn't inherit the philosophy of "dependencies are installed using your system package manager" to the degree that GTK does.
Another thing I would like to avoid is the philosophy of "the application binary doesn't come with its dependencies bundled, the user should install them using the system package manager". Unfortunately, many frameworks have this philosophy but, apparently, Flutter doesn't.
That's a good point. I just meant that it is not "just" GTK to the extent that it would invalidate the claim that it is "a compelling alternative to GTK these days."
I find that Qt apps also feel native on a wider variety of linux desktops than Gtk apps do. For example, Gtk (since v3 I think) encourages apps to override the window manager, stuffing widgets into the title bar and breaking actions like window shading/collapsing.
In general, Qt acknowledges the differences between desktop styles and tries to match them, while Gtk doesn't seem to care about any style or interaction model other than its own.
AFAIU Ardour hasn't switched anything. What they have done is import Gtk+2 into their own source tree, anticipating that Linux distros will get rid of the long deprecated and unmaintained Gtk+2.
> From a project-level perspective, perhaps the most important change is that we have moved the source code of our GUI toolkit (GTK v2) into the Ardour source tree.
Great thing is that as opposed to the web, the platform/library designers already took care of a lot of that, so the biggest overlap between GUI libraries and CSS is usually the layout (these days, where CSS isn't utterly abominable here).
A lot of the color fiddling etc. that web apps due is due to
1.) Graphic designers having no other way to go, now that print is dead
2.) Corporate Identity (which is of lower priority than platform identity)
3.) Selling stuff (not needed as much with desktop apps)
It's great when you want to outsource your or target a single platform but infeasible when you want to bring your own design or be the same across platforms.
And since most folks end up supporting the web as a first class platform you have to BYOD there anyway. Nobody is out there making a JS framework to emulate WinForms.
I thought this was about making things enticing to the scrum overlord, but sure…
Not everything has to or can be be cross-platform, not everything has to be web-visible. And I'd argue that serving the same view to everyone is quite often a bad idea. (Heck, in the web-case, it's not even just the view)
I recently wrote an app with vala. It was a pleasant experience.
I wanted my app to work well on desktop Linux and my pinephone running postmarketos and phosh.
Vala fit the bill nicely. I enjoyed it much more than python and the performance is great. I wanted something that was performant and minimized battery usage since I’d be using it on my pine phone.
I used vala back when I had a Nokia n900 - it really was the perfect thing to write small apps for my own use, and there was a nice cross-compilation toolchain. in all the years of owning an android I have never done that.
Vala has a sibling language called Genie[1]. Both languages are basically the same, but Vala uses a C#-like syntax while Genie uses significant whitespace like Python. They are both compiled by the same compiler (valac).
What problem/niche is this language a solution/fit for? I've been clicking around for 30 minutes now and have yet to find a defining feature that makes it (significantly) more productive and/or robust than Java or C#.
GNOME is based on GTK GUI library, and they wrote their own object system (GObject) on top of C. Then they wrote Vala, which updates plain C to be more like C# or Java, so it's easier to work with GObject than by using plain C.
Thanks for formulating that context so well - you should ask the Vala people to start their Web page with your 4 sentences, as most who visit the page will ask themselves.
Defining a new language "just" for the GTK library will likely be responsible
for it not taking off that much, even if - as is the case here - the language looks neat. The fact that it compiles to C, which is universally available, and the fact that it is not associated with corporate interests (unlike Microsoft C#/.net and Oracle Java/JVM) could be interesting, but perhaps decoupling things from GTK could have been wiser to get more reach?
I mostly develop software libraries nowadays, and the only GUIs are Webguis to interact with REST services, but for those folks that make the Linux desktop a better place, this seems a good way to be more productive than in C.
Speaking of which, the Linux desktop needs a re-think: someone should start and re-develop all apps in a much more clean and homogeneous way so that it is obvious what is done how. The existing bag of tools from different decades, inclusive apps from xfig, xlock, xv over LibreOffice/KWrite to gedit/kedit are just an inconsistent mess; even MS-DOS apps managed (at some point) to stick to standard text menus, from EDIT to TurboPascal.
About 10 years ago my team was using Vala for a production embedded system because it would transpile to C and cross compile to target the ARM platform. It was a lot easier to write a couple hundred lines of Vala than implement a bunch of high level language features in C. The Vala became a few thousand lines of hard to grok C as I recall.
I guess it solves for tiny community centered around a clean language, which it has, as well as Linux Distributions and Desktop Environments mostly written in Vala, like ElementaryOS and Pantheon. Related HN post: https://news.ycombinator.com/item?id=32787251
I always assumed that vala was a main reason why elementaryos was so slick. As in freeing people from accidental complexity to spend their neurons on new ideas and optimizations.
There is a big difference between what Java calls AOT and this. Statically linked hello world in Vala which uses some basic standard library functions is less than a megabyte (most of it taken up by glibc as I couldn't get it to compile with musl). If you assume dynamic linking for core libraries then it is just 15KB.
I have no doubt that the Java world has excellent tech behind the AOT support but the footprint is simply not comparable when you can't even construct a java.lang.String without bringing in the entire JapaneseChronology.
"Now" being the operative word. Vala's quite old; when it came out C# barely existed on Linux. I think these days C# is almost definitely the better choice for whatever you might have used Vala for in the past.
C# on Linux still has some warts, the runtime is massive and most distro-packaged software pulls that in its entirety. (And for extra fun, sometimes multiple versions.) All that overhead sits between your code and GTK, and something like Vala completely sidesteps that hassle.
That said, it only really shines for the "gtk based linux desktop" usecase, for everything else the situation flips around, as you now need to bring your own GTK. Occasionally still worth it embedded, but not much else.
There were a couple of Linux/Un_x desktop applications written in C# back in the day - Tomboy, F-Spot, Banshee, Beagle come to mind. They were pretty good at what they did.
But the GNU/Linux camp was rather hesitant to adopt .Net for fear of Microsoft suing people over patent issues. At least that is my memory of it. People wrote replacements for those apps Tomboy -> gNote, F-Spot -> Shotwell, Banshee -> ???, using Vala.
Now that Microsoft has made .Net open source, the lawsuit threat seems to be gone (at least for the foreseeable future), but I think the ship has sailed.
A bit of a shame really. Gnome development could be nicer with a language with some basic memory safety features and GC, but still generates fast code. Like C#.
There's still/again some C# apps for Linux desktops, like Pinta, but the dotnet sdk experience with it so far has been a lot rockier than with mono back in the days. Performance is great, ergonomics for end users not so much.
There are quite a few issues that make any JVM language difficult to use in scenarios like this one, in particular, lack of high quality and low overhead interop and certain low level features like C structs.
There is also now an option to statically link native libraries into NativeAOT binaries in .NET, and to statically link NAOT-compiled .NET libraries into existing C/C++/Rust binaries.
Superficially this language appears to be very similar to Swift. Beyond the syntax, it also has first class refcounting, C language binding, and no external runtime (compiles straight to binary).
I wonder, does Vala have a stable ABI, or native compatibility with other higher-level languages like C++ or ObjC? These are other difficult challenges which Swift attempts to tackle (and depending on who you ask, with varying levels of success).
In any case this is an interesting language. Thanks for sharing
.NET follows platform calling convention. GC reference assignment to a memory location does involve going through a write barrier (main user of which is concurrent mark phase of GC) but otherwise it's just plain Windows or System V ABI for the respective ISA.
Practically speaking, you cannot call .NET methods directly unless they are annotated with [UnmanagedCallersOnly] which is necessary to ensure GC is in consistent state, module initializers have ran, etc. This is a concern for NativeAOT libraries as you don't have to explicitly call their entrypoint before calling them AFAIK.
This, however, is true for most languages that are not C. This is also a constraint for both Swift, which has its own reference counting and ABI (Library Evolution ABI) and likely Vala assuming it is reference counted.
The runtime vs runtime-less arguments are not exactly helpful given the context - there are """runtime"""-heavy interpreted languages like Python, Elixir or JS, there is Java which assumes JVM, but is already lower level, and then there's .NET, which under the hood looks a lot like a strange flavour of C++ when you e.g. inspect the AOT binaries with Ghidra.
Fun fact, native profilers work with NAOT applications transparently on all platforms. You can hit "sample" in activity monitor on macOS and it will show you fully symbolicated trace if symbols are available. Just recently, I used Samply to perform multi-threaded profiling and it worked just as well as it would for something written in Rust, if not better.
Swift and Vala and any other eagerly reference counted language don’t have to worry about native C code squirreling away a reference to a GC’s object and not responding to a GC marking callback (either because the mechanism doesn’t exist or because it isn’t used correctly).
How would C track references for heap-allocated data originating from (A)RC-based language?
I don't think what you say on .NET correlates with reality - you are not supposed to pass managed objects across FFI (you just can't, it won't let you unless you do unsafe cast shenanigans) - the correct way is to either marshal the data or use blittable representation (plain structs can be passed as is, either by reference or value, same goes for arrays/pointers of primitives). On the rare occasion where unmanaged code needs to keep a GC object alive, it is passed via special GCHandle but that's an exception not the rule.
Swift has its own high level representation for such objects which are very much not FFI compatible. ARC in Swift is a feature that requires compiler involvement to work correctly, and its structs are not FFI compatible unless they are "trivial". Swift also has its own more advanced Swift Library Evolution ABI, which is strictly not C ABI you expect out of your regular library and has its own calling convention and semantics.
Overall, there seem to be strange misconceptions about how these languages work so it would be best to check with the documentation first:
(I don't actually know if any other other platform, besides Swift itself, implements Swift ABI support, but .NET is going to have it in .NET 9 - likely the first non-Swift platform to do so)
.Net was built for interop (mostly with COM+, but that's close enough to C ABI once you get a function pointer). It's pretty good at making it easy. GCHandle and pinning in general aren't incredibly rare, heck, merely passing a byte array or string to a native function involves pinning. There's also all the heavy lifting it does for you: it doesn't look like you need to pin byte arrays because the JIT does that for you. .Net's safety invariants aren't that hard to uphold either (any more than C).
I have lost all love for the platform, but I still have to hand it to Microsoft: no FFI has come anywhere close to .Net in the 25-odd years of its existence.
> How would C track references for heap-allocated data originating from (A)RC-based language?
Intentionally designed FF interfaces do not at all. C either delegates allocation to the host language, or the host language needs to let C know when it's done with things. I think Lua is an example of the former (it has been a while), the Vulkano crate is a living example of the latter.
Pinning is always done for heap-allocated GC memory, yes. Otherwise fixed statement does nothing for pointers/byrefs that originate from stack and it should be also a no-op for e.g. NativeMemory.Alloc-returned pointers.
On the other hand, GCHandles[0] are rare and only ever needed when you have complex object lifetime where, for example, the object reference needs to be passed back from unmanaged and object needs to survive in the meantime. The unmanaged code cannot interact with an object itself because it is not representable and would have arbitrary layout.
Today, there is support for multiple calling conventions and ways to interact with FFI. [UnmanagedCallersOnly] exports with NativeAOT-compiled libraries are C exports in the same way they are for the dynamic (or static) libraries compiled with GCC. Various flavours of function pointers have existed for a long time, yes. The most recent one allows to cast pointers directly to the desired unmanaged function signature within unsafe code, or create one given mentioned UnmanagedCallersOnly annotation on a C# method.
Objective-C's refcounting is exposed to C via CFRetain/CFRelease. Long before there was ARC (the thing you cite), the bulk of the NexTSTEP and then Apple frameworks were written with Objective-C code manually doing [obj retain]/[obj release] and C code manually doing CFRetain(obj)/CFRelease(obj). There was some doc somewhere telling you the protocol.
Later, ARC came around to automate it for Objective-C code that opted in. ARC carefully mimicked the semantics of the protocol in that doc.
And then later, Swift came along and mimicked the semantics of ARC.
There is a free lunch for languages that use reference counting. That free lunch doesn't exist for GC'd languages, which introduce a semantics that is different from the ones that C code already uses.
If reading documentation and looking into implementation details doesn't help, I welcome you to measure ARC overhead and observe the numbers with your own eyes at least once, especially in multi-threaded scenario. Might also read one of the previously posted links still, surely something will work eventually.
I’m not saying ARC is fast. Reference counting is slower than GC if what you want is throughput, unless you somehow manage to do very coarse grained RC, which is what you get in most C++ code (but then it’s far from safe).
The GC<->legacy-C interoperability problem is unavoidable. I’ve been around the block on that problem as someone who writes GCs for a living. It always devolves to some sort of ugliness.
Anyway, the fact that Vala uses GObject RC semantics is a point in favor of Vala. Folks who go that route, as Swift also did, should just be honest with themselves about the tradeoff: simpler interop, worse throughput.
Oh neat I’ve never heard of NativeAOT. I’ve only used Unity’s AOT compiler “Burst” for C# (I assume that is something different?).
Cool stuff.
edit: Actually I meant to say Unity’s IL2CPP, which transpiles IR to C++. Burst is a different tool with similar goals—it compiles IR straight down to native via LLVM.
- APIs to introspect type system properties / reflection
Swift very much has all these. And so does .NET.
As for Unity, it has diverged and lags behind "vanilla" .NET in features, language versions and performance significantly, so the experience of using it won't translate to what is expected to be "normal" C#/.NET of today.
Vala is pretty old these days. My understanding is that they built it because Mono became popular but there were patent and licensing concerns with it.
GNOME uses a lot of JavaScript nowadays, so large parts of an application can be interpreted. Here are the GJS docs, it gives you an idea of how much JavaScript there is: https://gjs-docs.gnome.org/
Does Elementary use Gnome? I thought it was something else. It's been years since I've been on Elementary, but it didn't feel like it was just a Gnome skin iirc.
I was very fond of Geary, and looked into Vala because of it. Found it to be an elegant language, and good to get practical programs working in GNOME. I haven't looked at it in the past 7 years. Is Vala still actively adopted?
Rust, as wonderful as it is, may be less suitable for GUI programming since it has no classes/inheritance (which is why Andreas Kling is creating the Jakt language for his SerenityOS project, after coming to the same conclusion after exploring whether to replace C++ by Rust).
Vala is a lovely yet criminally underused language. It does a lot of things right IMHO, and it massively simplifies writing GLib/GObject and GTK applications. It's nice to see more awareness around it, honestly.
I agree. I have wondered for many years why this is so. I think because Vala was developed so specifically for use with gnome, that its maturation was mainly limited to problems in that domain. I don't think it offered anything that wasn't already mostly available between Java and C#, so it never took off for web. It also wouldn't have fit well as a GUI building language for other native platforms, so it didn't take off there. It's not a good scripting language, so it didn't take off there.
In the end, I think it lost due to the network effect.
> I don't think it offered anything that wasn't already mostly available between Java and C#
Well it is massively easier to integrate C and C++ libraries in Vala compared to C# or Java - P/Invoke is bearable, but JNI is a pain to use and very hard to get right.
In 2009 I wrote a lib to auto-generate Ruby bindings for Vala code. It gave a very pleasant API to create native extensions for Ruby, if you were happy using glib.
I did a project presentation at university back in 2014/2015 on vala. I remember liking it, but i wasnt yet competent enough to make a verdict. Cool to hear it's still kicking!
Yeah. I clicked the link thinking, isn't it called hylo now? And then became momentarily confused.
At this point I feel something is definitely up. How many V* languages are there floating around out there.
Although on the other hand, we have C, C++, C#, and objective C (etc). So maybe this is just something that happened every once and a while through otherwise unsuspicious causes.
I have tried many boutique programming languages. I think I’ll pass on this one, especially higher level (object oriented) programming languages. I usually end up going back to Java/Scala/C#/python/rust/go.
Don't you just have a git client in your editor? All popular "out of the box" editors include one, and DIY editors like Emacs and Neovim have Magit and Neogit respectively. I find editor git integrations much more comfortable to use than some separate tool.
I use vscode. It didn't have line by line operations until recently. The sweet spot is working on hunks, not lines. For example hunk operations are quick and easy with short menus, while selecting some text then has the regular right click menu which is most of the height of my screen with 33 menu items, 3 of which are git operations. The selection is also character by character vs line by line.
Thanks - I eventually found it in the package repositories.
It does indeed have the same functionality as gitg for staging and reverting individual lines. It does have several UI niggles. For example when selecting it does not do so on a line by line basis, but instead character by character. But the operations are line by line, (or hunk). You also can't right click on file names and choose stage, revert, or delete.
Not a gui, and rather painstaking. With gitg you single click on lines in changes (green added, red removed) which selects them. You can separately click on as many disjoint ones across as many hunks as you want. There is a 'Discard Selection' button which removes the highlighted lines from the code, and a 'Stage Selection' to add those lines to the index.
While git add -p is in theory doing something similar, it is a lot more painful to use, and you are still working a hunk at a time instead of just scrolling through changes.
I often use this functionality when I've made a number of changes during development and everything is now coherent, especially on a multi-language project. It is then easy to go in and discard lines that were added to debug, and stage lines across multiple commits so they are logically grouped.
Go is notoriously difficult to use in a scenario like this, especially when bindings to C# in the form of https://github.com/gircore/gir.core exist (overhead of calling which is very low by nature of interop being a first-class feature since .NET's inception).
Historically, it was designed to resemble C#, yet transpile to GNOME-like GObject-based C code, to provide an alternative way for GNOME developers to get higher level language syntax without having to depend on Mono/C# (which was very controversial at the time).
So the biggest difference from C# or Java is that there is no VM. It is mostly syntactic sugar over C and GObject.
At least, this was the case last I paid attention 15 years ago.
I think I got in a rabbit-hole with it around 2010 for the same reason of liking C# but not liking who backs C#, but I already had enough not marketable languages
> but I already had enough not marketable languages
Ha! Ain't that the truth :-)
It touches on a big problem for new language development in that there are barriers to entry at getting workable in a new language, but employers don't want to use them unless they can hire for them, and they can't hire for them unless people use them, but people don't use them because they can't get hire'd to use them, rinse and repeat.
When I tried it many years ago it was a really leaky abstraction over GObject and C. If you didn't understand exactly how it worked under the hood, stuff would segfault on you pretty regularly. But I suppose that's par for the course in the GObject universe.
I actually first heard of Vala just a few days ago when I was looking at a C#-related PR[1] for highlight.js:
> This fails the tests as the Vala default.txt is recognized now as C#. However, Vala is very close in syntax to C#, and the default.txt also seems to be valid C# so not sure what to do about this.
Yea I guess I should have been more specific - I was looking for this directly on the main landing site.
Maybe I'm alone, but my immediate thought when seeing a new language, with fairly familiar syntax, was "why is this different than Java". And if that's my first thought, it probably makes sense to answer that question immediately rather than talk about vague things like Productivity and Open-Source.
Some HN monkeyboy jerking off and messing his chaddi again, in a knee-jerk reaction to a comment he can barely parse logically.
Downvoting coz doesn't have enuf grey matter to realize dat one can read about Vale outside of HN, and den search hn.algolia.com for vale language and find some hits, and share that info in HN.
There's also a lot of apps written in Vala for elementary OS's AppCenter with screenshots & links to GitHub: https://appcenter.elementary.io/ (not all, but most). I published two apps there and using Vala has been a great experience for creating Gtk/Linux desktop apps.
Yeah it would be nice if there was a list with screenshots of applications written in Vala, on the vala homepage, with links to the applications websites
