[HN Gopher] Vala Programming Language
___________________________________________________________________
Vala Programming Language
Author : gtirloni
Score : 220 points
Date : 2024-04-08 12:44 UTC (10 hours ago)
(HTM) web link (vala.dev)
(TXT) w3m dump (vala.dev)
| rco8786 wrote:
| A "Vala vs Java" and/or "Vala vs C#" would be helpful
| lnxg33k1 wrote:
| https://wiki.gnome.org/Projects/Vala/ValaForCSharpProgrammer...
|
| https://wiki.gnome.org/Projects/Vala/ValaForJavaProgrammers
|
| Imagine going to a link called docs and finding the first 2
| links are about what you ask for :D
| rco8786 wrote:
| 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.
| sandyarmstrong wrote:
| 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.
| lnxg33k1 wrote:
| 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
| freedomben wrote:
| > _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.
| throwaway894345 wrote:
| 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.
| nlawalker wrote:
| > it was designed to resemble C#
|
| 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._
|
| [1] https://github.com/highlightjs/highlight.js/pull/3906
| qalmakka wrote:
| 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.
| freedomben wrote:
| 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.
| skywal_l wrote:
| Not to be confused with Vale[0].
|
| [0] https://vale.dev/
| khaledh wrote:
| Or Val[0], now called Hylo (for a good reason), or V[1].
|
| [0] https://www.hylo-lang.org
|
| [1] https://vlang.io
| Verdex wrote:
| 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.
| cpersona wrote:
| "Why choose Vala" would be helpful.
| lnxg33k1 wrote:
| https://imgur.com/a/8aEmtDy ?
| beanjuiceII wrote:
| vala been around quite a long time too, would be nice if their
| app showcase showed some more mature apps
| lnxg33k1 wrote:
| 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
|
| :look:
| hydral wrote:
| https://vala.dev/
|
| an apps list is here
|
| else you have : Pamac-manager is on vala Gnome-Boxes gnome-
| calculator
| orthoxerox wrote:
| There are very few reasons to.
| remon wrote:
| 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#.
| saagarjha wrote:
| GTK+
| sampo wrote:
| > What problem/niche is this language a solution/fit for?
|
| Writing software for GNOME.
|
| https://en.wikipedia.org/wiki/Vala_(programming_language)
|
| https://en.wikipedia.org/wiki/GObject
|
| KDE is based on Qt GUI library, and Qt is 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.
| remon wrote:
| Ah! That's the bit of context I was lacking. Thanks
| xyst wrote:
| Probably some caveats not shown by using GObject over C++
| libs for qt
| jll29 wrote:
| 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.
|
| I also liked the itemwise comparison with Java:
| https://wiki.gnome.org/Projects/Vala/ValaForJavaProgrammers
|
| 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.
|
| https://www.theregister.com/2024/01/24/rise_and_fall_of_cua/
| dagelf wrote:
| 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
| agumonkey wrote:
| 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.
| Maken wrote:
| Vala compiles to native code, no VM or runtime required other
| than GTK+.
| iso8859-1 wrote:
| Java and C# also support AOT now, and the linker should only
| link code that is actually used.
| neonsunset wrote:
| 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.
| wk_end wrote:
| "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.
| creshal wrote:
| 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.
| krylon wrote:
| 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.
| jabl wrote:
| 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#.
| Maken wrote:
| > Banshee -> ???
|
| Pretty much everyone reverted back to Rhythmbox, which to
| this day still feels less polished somehow.
| krylon wrote:
| I switched to Amarok, then Clementine (Amarok 1.x fork),
| lately Strawberry (Clementine fork). It's really nice
| (IMHO).
| krylon wrote:
| EDIT: gNote is written in C++, not Vala. My bad.
| PhilipRoman wrote:
| 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.
| aredox wrote:
| Being to gnome what swift is to macOS
| icameron wrote:
| 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.
| jakjak123 wrote:
| Are there any good gtk bindings for C# or Java?
| aidenn0 wrote:
| I've had good experiences with GTKSharp.
| novagameco wrote:
| It's only available with Mono?
| neonsunset wrote:
| https://github.com/gircore/gir.core
| maxloh wrote:
| Heard the language a few years ago, but haven't seen any apps
| built with it yet.
|
| How popular is it within the GNOME community?
|
| What are its advantages over more popular garbage-collected
| programming languages like GoLang?
| rogerbinns wrote:
| > but haven't seen any apps built with it yet.
|
| The gitg git gui is written in vala. I've used it for several
| years because it allows easy staging of individual lines, as
| well as reverting them.
|
| https://github.com/GNOME/gitg/tree/master/gitg
| all2 wrote:
| > because it allows easy staging of individual lines
|
| I have been looking for this functionality for literally
| years at this point. Thank you! I will be trying this.
| calvinmorrison wrote:
| git add -p
| funny_falcon wrote:
| `git gui` and `gitk` my Swiss-knife tools for every day
| git-ting. They are maintained by git core team.
| jdiff wrote:
| Go is pretty obnoxious to write GTK programs in. Vala is
| basically a GTK-native language.
| neonsunset wrote:
| 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).
| amaccuish wrote:
| IIRC most "native" apps in elementaryOS are written in Vala.
| ainar-g wrote:
| Why the quotation marks? If I recall correctly, Vala compiles
| (by way of C) into native code.
| iso8859-1 wrote:
| 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/
| treyd wrote:
| Haven't they gradually been moving away from gjs though?
| nozzlegear wrote:
| 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.
| pacifika wrote:
| it uses pantheon
| tcmart14 wrote:
| To my understanding, Pantheon is built from scratch, but
| it is still GTK. So it has a lot of similar fundamentals
| as GNOME.
| flafla2 wrote:
| 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
| gwbas1c wrote:
| > Superficially this language appears to be very similar to
| Swift
|
| It's almost a clone of C#; it's tightly coupled with the
| GObject system instead of .Net.
| flafla2 wrote:
| Oh got it. So like c# but compiles to native a la Swift?
| bru wrote:
| There's more languages than Swift...
| zamalek wrote:
| Didn't you watch the latest WWDC? Apple invented
| programming languages.
| neonsunset wrote:
| What does .NET JIT emit? What does NativeAOT compile .NET
| applications to? :)
| flafla2 wrote:
| 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.
| neonsunset wrote:
| To be precise, runtime is an umbrella term. Swift, C++
| and Rust usually have """runtime""" just as much. Which
| includes but not limited to:
|
| - Automatic or semi-automatic memory management
|
| - Threadpool and, optionally, async abstraction
| implementation
|
| - 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.
| pizlonator wrote:
| (I've worked in an AOT for .NET and I'm a JIT expert.)
|
| Even if you compile MSIL to native, you're compiling to
| the GC's ABI, which is definitely very different from
| what Vala and Swift do.
| neonsunset wrote:
| .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.
| pizlonator wrote:
| 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).
|
| That's an enormous difference in ABI.
| neonsunset wrote:
| 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:
|
| .NET P/Invoke (FFI):
|
| - https://learn.microsoft.com/en-
| us/dotnet/standard/native-int...
|
| - https://learn.microsoft.com/en-
| us/dotnet/core/deploying/nati...
|
| Swift non-C ABI:
|
| - https://github.com/apple/swift/blob/main/docs/LibraryEv
| oluti...
|
| - https://www.swift.org/blog/library-evolution/
|
| Swift ARC:
|
| - https://docs.swift.org/swift-book/documentation/the-
| swift-pr...
|
| - https://github.com/apple/swift/blob/main/docs/ARCOptimi
| zatio...
|
| (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)
| pizlonator wrote:
| Swift's reference counting is exactly what C code on
| Apple's platforms were already doing.
|
| And Vala's is exactly what GObject code was already
| doing.
| neonsunset wrote:
| That's not C but Objective-C. From quick skim of the
| spec[0], it relies on macros and same autorelease pool.
|
| There is no free lunch in software engineering, only
| difficulties with accepting reality.
|
| [0] https://clang.llvm.org/docs/AutomaticReferenceCountin
| g.html
| neonsunset wrote:
| Speaking of, there is https://github.com/gircore/gir.core
| the_mitsuhiko wrote:
| 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.
| krylon wrote:
| That's how I remember it, too. I still miss F-Spot.
| kmarc wrote:
| > compiles straight to binary
|
| I checked it ten years ago-ish, I think it transpiles into C
| (with GObject). Still no runtime though.
| sirwhinesalot wrote:
| Vala predates swift by many years. It's meant as a high level
| implementation of the C GObject system, to which it compiles.
| rpncreator wrote:
| Last time I heard about Vala was the Yorba Foundation's (RIP)
| work with Geary and Shotwell, many many years ago.
| sn41 wrote:
| 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?
| ndiddy wrote:
| 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.
| pipeline_peak wrote:
| 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.
| rob74 wrote:
| Yeah... why fiddle with GTK_Window_Context_Handler_Ptr if you
| can fiddle with the intricacies of CSS layouts instead?
| pipeline_peak wrote:
| Well, if you want to make things look pretty, which product
| owners and users expect, you'll have to fiddle with
| cosmetic intricacies regardless.
| megous wrote:
| GTK uses CSS underneath.
| mhd wrote:
| 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)
| Spivak wrote:
| 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.
| mhd wrote:
| 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)
| brabel wrote:
| > how many developers are even writing GTK applications
| anymore?
|
| I would like to know the honest answer to that question,
| actually.
| mirpa wrote:
| See Gnome on Linux.
| Spivak wrote:
| Yeah, but outside the GNOME devs themselves the adoption
| has been pretty meh.
| sitzkrieg wrote:
| 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
| pipeline_peak wrote:
| > anyone who cares about the footprint of their software
|
| That's why I mention performance critical
|
| > wpf is still heavily used in industry
|
| But is anything new being made with wpf? Because that's why
| I left that area.
| sitzkrieg wrote:
| 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)
| Tomte wrote:
| > but ill be first to admit thats an exception
|
| 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)
| sitzkrieg wrote:
| interesting, i was wpf old hat and had to justify it vs
| winui3 (directly) and maui
|
| they are both too new
| neonsunset wrote:
| Yes, but that's against common advice to use AvaloniaUI
| instead.
| JaggerJo wrote:
| We use AvaloniaUI in production for a handfull of apps.
|
| Couldn't be happier.
| sitzkrieg wrote:
| this is not cross platform work, but i checked that out
| and will def keep in mind! esp considering all the AOT
| limitations in the real world
| creshal wrote:
| 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.
| temporarely wrote:
| 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.
|
| https://sciter.com/developers/engine-architecture/
| The_Colonel wrote:
| The motivation behind using electron is:
|
| 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).
|
| Even c) is very debatable.
| jodleif wrote:
| The path to hell is paved with good intentions
| jayde2767 wrote:
| 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.
| mrec wrote:
| What's the "egress" footprint you mention? I hadn't come
| across the word in this context before.
| sitzkrieg wrote:
| 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
| diego_sandoval wrote:
| 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.
| cies wrote:
| Flutter is cool, and new.
|
| Qt is old, and cool.
| mirpa wrote:
| Adding flags to gcc should be just a matter of pkg-config.
| In bindings to high level languages that should be handled
| automatically.
| audidude wrote:
| > Flutter Desktop seems like a compelling alternative to
| GTK these days.
|
| Sad news for ya, flutter just wraps GDK (from GTK) on
| Linux. It also, last time I checked, was limited to a
| single application window.
| fngjdflmdflg wrote:
| It just uses GTK to open a window. Firefox and webkit
| also do this IIRC.
| asddubs wrote:
| qt is a good fit for writing native linux apps. I've tried
| both and qt is much nicer to work with (in my opinion)
| foresto wrote:
| 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.
| bandrami wrote:
| > If you aren't developing a DAW
|
| Now that Ardour has switched are there still any DAWs using
| GTK?
| jabl wrote:
| 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 https://ardour.org/whatsnew.html# :
|
| > 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.
| luciusdomitius wrote:
| 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.
| pipeline_peak wrote:
| 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?
| deergomoo wrote:
| > 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.
|
| Do people care? Evidently not. I do though.
| Sammi wrote:
| Consumers and bosses don't care. They want stuff and they
| want it now
| mardifoufs wrote:
| 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?
| sprash wrote:
| 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.
| sirwhinesalot wrote:
| 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.
| asabil wrote:
| 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.
| xyst wrote:
| 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.
| account-5 wrote:
| I'm sure I read somewhere gnome was moving to flutter, I
| definitely might be wrong.
|
| EDIT: might be getting confused with ubuntu
| popey wrote:
| No, the Ubuntu community is pushing Flutter, not upstream
| GNOME.
|
| Like the desktop app store, the Ubuntu installer is now written
| in Flutter.
| pharrington wrote:
| For everyone (including myself) asking "why?", the Gnome wiki has
| the programmer friendly answer
|
| https://wiki.gnome.org/Projects/Vala/
|
| "Vala - Compiler Using the GObject Type System"
| ip_addr wrote:
| Using Rust for GNOME development seems to be becoming more
| popular. https://gtk-rs.org/
| jll29 wrote:
| 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).
| skeuomorphism wrote:
| 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!
| l72 wrote:
| 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.
| zem wrote:
| 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.
| buzzert wrote:
| My favorite thing about Vala personally is the wide range of
| native libraries you have access to because of its compatibility
| with GObjects.
|
| There's a great documentation website that has everything located
| in one place also, which makes development a breeze:
| https://valadoc.org/
| pizlonator wrote:
| Is it only pleasant when the library already exposes itself via
| gobject, or also pleasant if the library is just a C API?
| buzzert wrote:
| That's true, but as it turns out there's a lot of examples
| out there!
| EasyMark wrote:
| For some app examples: https://github.com/vala-lang/awesome-vala
| jcmontx wrote:
| Looks like java
| fuzztester wrote:
| I saw another one called Vale just today. There are a few HN
| threads about it.
| pacifika wrote:
| Every now and then there's the "what to use for developing cross
| platform desktop gui apps". Well here it is.
| DaSHacka wrote:
| Not qt? In my experience most native linux applications opt for
| qt over GTK, let alone cross-platform ones.
|
| Any reason in particular to use vala over qt?
| vaylian wrote:
| 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).
|
| [1] https://wiki.gnome.org/Projects/Genie
| nu11ptr wrote:
| Yep, unfortunately it is a dead language and I believe has been
| for a while now.
|
| Genie = 24 repos:
|
| https://github.com/search?q=language%3AGenie%20&type=reposit...
|
| Vala = 3.1K repos:
|
| https://github.com/search?q=language%3AVala+&type=repositori...
| novagameco wrote:
| I want a flexible native UI framework without it requiring me to
| use a custom programming language
| wiseowise wrote:
| Very sleek website, like it.
| colinkiama wrote:
| Thanks!
| dang wrote:
| Related:
|
| _Vala Programming Language_ -
| https://news.ycombinator.com/item?id=32113825 - July 2022 (93
| comments)
|
| _Vala Programming Language_ -
| https://news.ycombinator.com/item?id=28905761 - Oct 2021 (1
| comment)
|
| _Vala Programming Langauge_ -
| https://news.ycombinator.com/item?id=26019680 - Feb 2021 (1
| comment)
| Koshkin wrote:
| _The Vala Programming Language_ -
| https://news.ycombinator.com/item?id=39528496 - Feb 2024 (no
| comments :)
| zetalemur wrote:
| Interesting default rendering choice for `()` in their demo
| pretty printer. It renders a space before each opening
| parenthesis.
| swayvil wrote:
| I'm always looking for a simple minimal oop language. Thanks.
| lucraft wrote:
| Ahh takes me back!
|
| 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.
|
| https://github.com/danlucraft/valar
___________________________________________________________________
(page generated 2024-04-08 23:01 UTC)