If I can ask, what are you using for UIs with Go?
Weâre working on a Saas web service project and using React/Typescript for front end work.
I have been looking at The Wails Project if I ever get a burr in my britches to do another cross platform apps. Just for grins I might redo the first app I ever did on Xojo and keep using it today (a time tracker). https://wails.io
They blogged about version 3 in January which looks very interesting and a whole less complicated than V2.
way to go IMHO, I mean any web frontend, if you can live with the pros and cons of course and as always.
If someone wants to have some real desktop-ish, you can have a look at:
They even have a kind of a visual designer, called DeFyne (which I kind of love as a naming 
)
I have played around with their solution. Kind of fun, kind of mature in some areas, kind of early days in others. I would say: mature enough for some small GUI stuff, kind of UI for console apps, internal tools, small apps, etc.
Is is mature on the level of Java Swing, JavaFx, etc.? No way! Just look at their tablelist etc.
to bring this back to topic: they have conferences too, and you can watch their recordings for free:
And they delivered on their 2022 conf promises. A bit of a delay, but only a few weeks.
1 Like
Well, Iâm currently not involved with the front end - all back end work. Eventually, I think, Iâll get into some of the front end work but Iâd like a good solid 6 months of Go work before I do that.
Itâs not like I had any choice in the matter. Go and React were selected long before I got moved onto this team. Before that it was 3 solid years of Xojo desktop apps. To say itâs been a weird transition is to be a bit too kind. There are things I like about Go and is far superior to Xojo and there are things that I think Xojo is clearly superior on. However, as a whole, Iâm more secure in my future as a Go developer than I am about my future as a Xojo developer.
3 Likes
Sadly, you wouldnât get a job even with the most arcane Xojo skills here in Europe. Even Xojo Inc is not hiring. Go developers can cherry-pick their job.
Xojoâs Pro posting channel for opportunities has been very quiet
Iâve been looking at Go as a âbest fitâ among a number of desired features, and itâs a pretty well-designed language with a lot of practical features. Iâve looked at the various GUI options (nice list here: GitHub - go-graphics/go-gui-projects: A list of Go GUI projects ), and currently going this book: https://www.amazon.com/Hands-GUI-Application-Development-cross-platform-ebook/dp/B07GYLYSCT/. Focusing most on GTK.
Yes, there are many options. One advantage of fyne is that it comes with everything. No need for any bindings ⌠GTK, QT etc., but with the limitation that it is IMHO not yet feature complete for complex UIs (you have been warned 
).
I just have the feeling that some people are already dreaming that it will solve all problems. That wonât happen, nobody in the fyne team claims that. So please be careful and test it yourself. For instance try the âFile dialogâ. Looks âgood enoughâ, but well ⌠not beautiful at all! Try the lists and tables, etc.
The beauty for smaller helper tools: you can compile for windows, linux, macOS. I even achieved to do so from a Mac M1 for all platforms. Neat.
Thatâs nice, no doubts. But they have only a few developers. Who can trust a tool with only a handful of devs . Fyne might exel, but it might as well stop tomorrow. Not my words, but those from the authors. Again you are warned.
As for Go in general, I really liked it for Web APIs, very easy, very fast. The approach / dogma of only having one way to achieve things, aka one kind of loops is at least âinterestingâ and ârefreshingâ, on the other hand it leads IMHO to some funny âlongâ code for simple task which is then annoying to read and potentially difficult to maintain (if not well documented).
I wrote some well documented code for instance, but after only a few weeks I was sometimes still âpuzzledâ what my code really did.
The GO community is in general friendly, the documentation okay, the available libraries usually good enough, but for pdfs for instance not really maintained. Most of the newer ones rely on ONE older one, or you use a commercial library. https://unidoc.io/ for instance. But look at their price ticket. Now MBS DynaPdf is all the sudden a bargain. Here again, be warned, make your own tests and your due dilligence. One example: check if your chosen library is able to change meta data of a pdf (author, etc.), JAVA, DynaPdf, etc. have you covered - GO and Rust libraries, as of today, often not. This might hurt some devs, others might not even know what Iâm talking about
I donât mind the GO way of doing error handling, but I have to admit that I still prefer a good old school clear and easy try catch statement.
Compilation time is one of the beauties of GO. Youâll remember by words if youâll try âRUSTâ in comparison
If someone is mainly working with backends, cloud, Kubernetes, networking then GO is a little dream, and with nice any easy capabilities for âmulti-threadingâ. But many languages have those capabilities. You might need a few hours more to read the documentation for other languages than GO, but thatâs the main difference IMHO.
So I personally donât see multi-threading as the biggest advantage of Go. Granted, it is implemented in Go in a way, that even beginners will learn it a day or two. Thatâs of course nice but if you have never been dealing with multi-threading I believe you will still need weeks / months to master the topic.
BUT, where I believe @thorstenstueker is very right, though some people donât want to listen to his JAVA mantra: if it comes to the best compromise of features sets (UIs, brilliant feature-complete libraries, ease of language, documentation, stability, clear roadmaps, coverage by many companies and endless fellow developers) then it is hard (impossible?) to beat JAVA, at least if multi-platform development is important to you.
Especially if you donât want to deal with CSS, TS, HTML for web. Of course you can integrate / combine all that with JAVA too, but if you donât want then there are a few alternatives available in the Java ecosystem to keep this stuff away from you, and you will still get a web app.
Now I do know that some of us donât have the choice, as their companies or projects already chose a programming language for them. But if a reader of this post has yet all âfreedom of choiceâ and wants to move away from Xojo, then I think it is worth to try Java.
It will take you a week or two but then you will be able to compile an exe, pkg, dmg, deb for all platforms, even self-deploying the JRE if you want. And this in a way that technology agnostic users, will probably not even see that you are using Java.
But of course, people have to make their own decisions. If someone hates semicolons, or curly braces, well ⌠use something else :-). I firmly believe that you have to at least try programming languages to form your own opinion.
Iâm refreshing my Java knowledge now since roughly July / August 2022, in parallel to my investigations into GO and RUST. All I can say: Todayâs Java ecosystem(!) hasnât much in common any longer with what I remember from it in the late nineties and the 2000s. Though older Java code would still compile with the current JDK, that alone is impressive.
2 Likes
That I have this âMantraâ I can say comes from experiences in the market since 35 years. And that is a long time. When I started with Java it was not like today. Other languages also not. But Java had something I could be a friend with from the first day. Reliability. There were Bugs. But never complete Showstoppers. That was the difference to Delphi, C++, later C# and many others.
And over the last two decades the ecosystem was growing. In 2003 (I may remember wrong then please correct me) server based Webapps with Vaadin were becoming possible. In 2012 mobile Apps with IOS Xcode Compilations became possible. And so many other things nd all of the Stuffs where Open Source. That makes the use of Java really nice and without having to pay for all small stuffs, no Plugins buying and so on. And while sun made it open Source it is existing as openJDK since 2006/2007 what is also in a short time: two decades. So everybody can use the Technology for free.
And so I can say: yes, I was testing. Even Delphi, C# of coarse and many others including Lazarus/Freepascal. And I am still testing new technologies. At the moment for example I am in a tryout for Rust with RTOS Operating System. It is nice but I can do the Job faster with C++. Why? The missing Ecosystem of Rust. And that is the next problem in the World f Rust, Go, Flutter/Dart und many others.
1 Like
Thanks, this is a very nice summary!
nice any easy capabilities for âmulti-threadingâ
I was just thinking about this in the context of the discussion about true multicore threading in Xojo.
Yes, Iâve looked at Fyne carefully. Lack of a webview is a showstopper for me. That requirement and a few others seems to rule out most of the smaller UI toolkit projects, which, to your point about a âhandful of devsâ probably isnât a bad thing. Thereâs a lot of things Iâm wary of with GTK, but vanishing overnight isnât one of them.
Thatâs a good point, though Iâd hope continued growth would expand and maintain the ecosystem. I would expect that it works pretty well with shared libraries.
FWIW, as far as ecosystem growth, this was just now in my inbox; OâReillyâs survey claims âJava and Python were the leaders by a long way and saw minor gains, while interest in Rust and Go grew 20% each. Go was the third most popular language, followed by C++, JavaScript, C#, C, Rust, Microsoftâs JavaScript superset TypeScript, R, Kotlin, and Scala.â Top programming languages and topics: Hereâs what developers want to learn about | ZDNET
While I find the absolute ranking in this survey questionable, growing interest in Go isnât, and at least it doesnât seem to be going in the wrong direction!
I would suggest that there is the following situation coming up in reality:
Python as small script for startups, initialization and so on is itâs most used capability.
Major languages in use c++, c, java and after a ling time comes nothin and only then c#. All others also with a big distance.
Why? While all others are not making anything better. Go, rast, dart and so on will be able to compete with the major languages in a decade. If they exist until then.
So you can find small companies using this languages but there is nothing you could not do with the other ones.
Looking on this fact you want web. The most comfortable way to build Webapps I know is vaadin for example. Extremely flexible and blazing fast. Write ui in Java as serverbased running application and thatâs it.
At the end everybody has to decide by self. But the arguments I had to evaluate until now had often nothing to do with reality. Sadly I have to say.
As example go and ui. There is no real production ready desktop ui for go. And that will need a decade. For java and c++ there is definitely. So I canât understand Xojo users trying to get the world turned the other way around. But okay possibly I am not professional enough as developer cause i studied theoretical physics and mathematics and applied physics and not something else. So for me other things are counting like reliability, secury, ling term existence of a platform, platform not only from a small vendor while growing letâs get all out of control like you can see at Xojo.
The argumentation against Java is often: yes that is for you but for me it is not possible to use and xyzzy is better for me. In the most cases I look behind and doing tests I can say: crazy. Not. And that I will never be able to understand. Rest Services you can write in many languages. Starting with Python, C++, C, Java and C# you can do that also with Go and other languages. But what if you need to refit the project for longer time? What if there is no compiler anymore? I can understand many things and I believe that every decision for or against a Programming toolchain is a decision following clear technical rules and foreseeable future of the toolchain itself. And there I can say: I canât see that for languages like GO at the moment. Also not for Xojo.
Languages like C++, C and Java are the most commercially used Languages. Java has the biggest amount of commercial Vendors starting with Oracle there are many OpenJDK Vendors. Java Development is not living from Oracle but the entire OpenJDK community and all the Vendors. And they do invest massively in the Language and its development environment. That results in the most optimizes Compilers and virtual machines the market knows. Even native Compiles are possible.
And there I had the next Discussion where people even then say: but there is the rest of a virtual machine and my customers donât want that. I canât get. First no it is not, second: yes Garbage Collector and so on are still working also in Xojo Programs. And there is much more background activity.
So I stopped to argue while I canât argue against missing acceptance and against missed knowledge. I can only tell what is fact I canât do the miracle I get presented when people speaking about writing projects they want to maintain at least for a decade better more with a language driven by a few enthusiasts and that cross platform. That will not work.
It is the same with Maui. Maui is not even ready for production and C# still not really cross platform with a word concept but people love MAUI. And what? Nobody can use it for production until now. And it has the best chances for a short lifetime because even MS had to learn that maintaining it is a nightmare.
So we come to the next Point, cross platform. The relying on GTK is dangerous what vendors had to learn with MacOS Ventura. Many of the programs were not working anymore after the change while the last GTK Version was and is not compatible with Ventura. Not a Joke. And the entire point is: that tech stack was never until now out of Beta. But used for Production. The risk of doing that to become cross platform is really high. And that Risk you have also with other tech stacks. Looking on this I could always compile and run without any problems Java Swing and also JavaFX for MacOS Platforms. Why? Because the technology behind is able to. There is no it will not run.
The foreseeable future is the time we can see that a project will be maintained and run. There is no Language in the entire Market where the foreseeable future reaches to 2032 except Java. The upcoming LTS is supported until 2032. Long time from today. And the LTS 25 coming in 2025 is planned to 2034. Writing this I have the guarantee that all my investments for Java Swing Code, Vaadin Code, JavaFX Code and CodenameOne Code are at least can be running on JDK, packaged to native packages and be compiled with Native Image as native compile until that time with actualized Compilers and Security Updates. While we all can not expect that the Development will stop until that time I see the foreseeable future for the next 2 decades. And even JavaFX and Java Swing will stay alive until then. Makes sense while projects can be maintained over decades if needed. I canât see that for GO.
Coming to the next argument: Reliability. Grabbing old Code I wrote before 2 decades I could compile it without changes in Java 19 (the actual JDK). That will not work with C++, C#, C, Python and any other Language except Java. The same UI and the same Code but 2 decades ols. That helps maintaining projects over long time.
That isnât a mantra. It is a strategy to be secure that my code will still run in future and I can rely on it completely. My commercial interest is that I can maintain my code for a long time. That is important for me because I want my Software running and my Clients happy with it. All known toolchains can not provide that. The other way around: massive changes in syntax and available Libraries making it impossible to use the Code years later. It is my lifetime spendet in changes of programming languages when I have to rewrite 80% of my Code. Look on Xojo for example. All product connections between Xojo 2019 and 2023 are broken. The API 2 had massive changes after its first Release and should be named API 4 to speak truths. That is not reliable that is a time killer without sense. And so I decided for me not to loose that amount of time.
Platforms is one of the spheres I have to look on also. As I need all of them I need a language capable to provide me all of them. Like Xojo tries Java is available for all platforms and running on all platforms. So I can compile for all platforms. Coming up with the need of the security and maintenance for all platforms. Looking on other languages like GO I can see only a few people developing for all of them. The Office for the organization of Swing maintenance is bigger than the most of this entire developer groups. That makes it possible that a platform will stop one day working.
Looking on all of this I saw for me no alternatives. While I have a running toolchain which is above all this facts completely open Source (if I want also the IDE IntelliJ IDEA Community Edition, Netbeans, Eclipse). I donât have to pay. I can decide to order for example CodenameOne. Always with the right to use their Build Servers. I can get Vaadin commercial Edition. With more Components and add ons. But I can write all kinds of applications for Desktop, Mobile and Web for free. No upfront costs. All I need to do is: using it. For me a massive argument. Why? While.
Letâs look on it. What happens if the Company dies, the Vendor is not available anymore. Like Xojo. Then all licenses are working until you need a new computer or a new Harddisk. And no maintenance is happened for the IDE and the compiler. Stops immediately. That is the risk of it. While there is in that case no licensing Server anymore there is also no chance for using it anymore.
Vaadin, CodenameOne, JavaFX, Java Swing are free Software licensed under GPL or MIT license. That means: I can still use it for long time. As the community is even now taking care of the Code it will stay for long time. I have no problem to maintain project updates for example. I have no stresses with holding my Products in the market. And I have all time I need for rewriting in another toolchain. If that will be even needed. That is the for me most important point.
So if you see in this positions a mantra, do it. But in truths: it isnât a mantra it is the result of a long process of decisions made for future ready Software Development.
1 Like
Thereâs no doubt that GO has a growing following, and for good reasons. You never know what Alphabet will do with it in the future, but thatâs also true for many competitors. ORACLE can also pull the plug on Java, but that seems even more unlikely because they make real money from it and because openJDK would âlive onâ for at least a very long time (years, not just months). As of today, Java is too big too fail in an enterprise context. That doesnât guarantee it wonât happen one day, but it wonât happen over night.
But yes, I wouldnât worry too much about that with GO either, but I would worry a tiny bit more. Google has just let me down too many times.
There are also many other aspects that I found great about GO. How to handle JSON / BSON (VERY easy), Multiple return values (great, just stupid when you switch programming languages and then donât have it there ). A nice language for companies, if only because you can quickly onboard new, inexpensive programmers. But you have to know what youâre using it for. GUI in GO is just not the focus for most companies/users. Large companies also have fewer problems with the current status of some libraries: when in doubt, they write what they need themselves (possibly also in other languages), or just buy expensive libraries.
Now back to @thorstenstueker ;-). No matter what he writes, I feel that his core message is often lost on the readers. It took me a while too. Please remember that I wrote about Java as a âcommon denominatorâ. What do I mean?
The following is so to say copyrighted by Thorsten :-). I mainly repeat what he is preaching all the time. If we forget the annoying bugs, unreliable roadmaps at Xojo, and just strip all features from their advertisements (including!) all available plugins, documentation, and wish lists (git, multi-threading, etc.). If we then add features, like hat we should theoretically be able to generate web apps with Xojo Web with little knowledge of JS / CSS, and being able to compile for iOS and Android on top of all desktop platforms** then we have a LONG list of features what we would like to have**.
This list is then used to search the market for alternatives. If you then add to the mix that a layout manager would be nice, multiplatform is a must, and you want reliability for the future and reliable version-controlled documentation, then I think it is fair to conclude that the only thing left is Java at the moment, providing ALL features from our wishlist. Or you will use MANY tools for each platform. Swift for macOS, C## for Windows, etc. or you will use Xojoâs competitors, but they donât cover everything that we have always requested from Xojo.
I think that Thorsten is right here, but Iâll add to his âmantraâ my perception too
Is Java the coolest language in the world?
Debatable âŚ
Is Java the most modern language?
No certainly not.
Is Java dead?
A clear no.
Are there any further developments in Java at all?
Definitely more than ever. Itâs not just GraalVM going towards native compilation, there are many projects, e.g. Leyden, doing something like that, and often with many more developers than e.g. fyne or Xojo. Exciting and promising!
Is Java easy to learn?
The language itself? Yes, a week is enough, if you have a programming background to be on-boarded.
Is the Java ecosystem easy to learn?
No way and it depends :-). As with any language, if you know the language, you donât yet know the libraries, nor do you master the layout managers, the packagers, etc. To master the borrow checker in Rust, you have to count in a few months too. If you know GO, you donât know anything about fyne yet.
What about learning resources for Java?
I have so far always found what I needed. But yes, it feels easier with more modern languages / ecosystems? Why? Java exist for decades. If you google a topic, youâll find a lot of old stuff and a lot(!) of new stuff. Plus there are many, many ways to solve a particular issue in the Java context, so youâll find many results, following different approaches, that is sometimes confusing.
I tried Go, Rust, and I feel it is easier than Java?
Your are probably right. Remember Xojo? Xojo was easier when still called Realbasic. Why? Because it had less features (and only one API , no iOS, no web, etc.) it is normal that a younger language simply looks clearer because it has a smaller ecosystem, but of course also because as a new language you have the advantage that you can learn from âmistakesâ of more dated languages.
What about the Java community?
This is a difficult point. But that is also due to the complexity of the ecosystem. I still havenât found THE forum, not THE discord channel that would answer all my questions. There are thousands of resources (thatâs good), but yes, itâs certainly at least a little more tedious to navigate the Java world at first.
What do I see as biggest challenge to learn the Java ecosystem?
With languages like Go or Rust, a simple text editor would do. In my opinion, this only makes sense in Java in theory.
Without an IDE, IntelliJ, Netbeans, Eclipse you make your life difficult, very difficult. Problem: if you use an IDE, you have to master it first. Thatâs a lot of stuff at the beginning and thatâs also something that the gurus just donât understand because theyâve grown into it over the years.
But whining doesnât help, only diligence helps. After a few weeks, however, you have quickly developed a foundation that you can build on. In addition, this is not much different in more modern programming languages. Without an IDE you make your life unnecessarily difficult. And without diligence, no programming language will get you anywhere.
2 Likes
thanks for sharing experiences
since you tried tauri and fyne, you should make a medium post for the comparaison of building desktop apps
maybe fyne is more easy since itâs go ?
do you know any desktop apps worth seeing using wails ?
thx
That depends, as I am fluent in Vue3 / TS a web frontend was easier to me, than using fyne. For Tauri you donât need to use Rust, but it is nicer to use it. But that part wasnât too complicated either, but yes Rust is a different beast compared to Go. But as well in a positive way: the language has more features, with GO I have the feeling that you need to loop over everything, you are always âloopingâ
I moved all my nodejs logic to Go in a week or so for a large project (which took me 2 months to develop in nodejs). Thatâs the very nice part in Go.
Fyne is nice to play with and easy to learn, but one has to understand the concepts: layer, containers, and overall the layout is somehow fluid / responsive. You wonât achieve a pixel accurate design as you could do in HTML / CSS. 2 different beasts.
And with Swing (JForm Designer) or JavaFX (Scene Builder) you have GUI Builders, which make you feel at home almost instantly.
So als always it depends. If you can live with electron-ish apps, use tauri. For small UIs for console tools, play with Rust or GO UI tools. If you have some complex UI designs in mind, you are probably better covered with the standard programming languages. Use Swift if only macOS is in the scope, C## for Windows, etc. If you really need cross platform, or if you want to keep that freedom, then Java is really nice.
And ultimately, you always have to question your own patience. For example, all UIs for Rust and GO are still in alpha or beta stages. And new releases often mean breaking changes. That doesnât matter for prototypes and small programs, and you donât have to update it - but rather grossly negligent for serious customer projects IMHO.
Thatâs what I mean by the common denominator. Java is certainly often an idea weaker in some areas than solutions, especially frameworks that have specialized (so not different from Xojo).
Itâs the whole package, itâs almost impossible to find something that doesnât work in Java or that canât be solved somehow. Even Windows Services via wrapper, etc.
And here you have to ask yourself what you want. If you only want desktop web apps, then tauri is probably the easiest at the moment. But if I already know (my case) that we will program all sorts of things, then I want a tool that covers more, even if I have to make a comparative compromise in detail, and use a programming language that is simply used by many as classified as old-fashioned.
There is no right and no wrong here. Everyone has to make their own decision here, and the best way is to try it yourself. And that is quite time-consuming and often gets on your nerves
Learn, un-learn, re-learn. I for instance hated(!) Java from ⌠the beginning ;-). But a LOT happened since those days.
2 Likes
While Google is a big driver of Go, it is an open source language. So theoretically if Google decided to stop using it the language would still continue to be developed. With that said, it still seems to be a fairly âyoungâ language and it has some quirks.
For example, I ran across this the other day in a code review and it seemed strange so I flagged it.
// Code simplified for discussion
for i, v := range vals {
v := v
sendSomewhere(&v)
sendSomewhere(&vals[i])
}
My question was why redeclare v inside the loop? Isnât the v in the for loop good enough? There is a very long discussion thread on Go forums why this needs to be done and theyâre considering breaking their âversion 1 promiseâ to not break existing code because of it.
Our architect said this is something that gets every Go developer at some point or another. Hence why theyâre thinking of changing behavior despite the promise.
1 Like
Looking on gwt I can say: if google stops development the community isnât a good driver for the Development of the language. And there are many examples of it in googles history. The gwt is still under development or let me say slow motion maintenance. A bit slower than necessary. And if that would be happened you can du a funeral 
for your Code. This said I know that from many examples cause for Google itâs only interesting as long they use a tool. And as long as google is willing to pay.
I think it is solved now, but there was an issue that binaries compiled for Windows were flagged by Smartscreen even if you had a certifcate. Apparently even some virus scanners paniced. Interesting as well.
Yes, there are chances it will be continue to be developed. But usually once Google jumps off the wagon, it is a bit like falling dominos. I would prefer more companies officially backing it, but thatâs a personal thing.