Obviously, a better language would avoid pitfalls and deficiencies found in other languages and incorporate their most powerful and convenient features/constructs.
Oh, I see some of you are a bit surprised by this question.
Let me explain, please. I am very interested in programming languages from the beginning of my professional career. I have used about a dozen of languages, not counting dialects and implementations. I have been programming professionally.
And I would be glad to compare my personal opinions to community experience.
My surprised face was more to evoke the feeling of
“Oh goodie! Something that everybody has some strong opinion about an aspect that is an irritant to them!”
For me, the single most irritating feature of any language is that logical software blocks don’t have distinct delimitation characters!
For me, that is most critical because I always like to “semi-automate” various aspects of my coding, which involves both
the creation of code … and
the parsing of existing code.
It is this latter task/process which, from my perception of the automation standpoint, is the most irritating and difficult to implement for the likes of Python, again, IMHO. I’ve mentionned that issue in the past, and I repeat it here.
Not to say that I do NOT use Python, just that it is a tool of last resort when no other option is available to me.
Thank you, Eric! You get the point: I’m interested in subjective opinions of our fellows on what they consider pros and cons of programming languages they do use.
Honestly the question kind of answers itself, the hard part is that one person’s pitfall is another person’s favorite feature.
For me it comes down to predictability. I don’t want to fight the language to do the thing I’m clearly trying to do. Writing Bash at midnight to automate something and then spending twenty minutes figuring out that a variable expanded wrong because I forgot to quote it, that’s the language wasting my time. Same with chasing an indentation problem in Python. Just get out of the way and let me work.
Error handling is the one I actually care about the most. Anything that lets you fail silently, or makes doing it right so painful that people just skip it, is setting you up to get burned later. Rust nails this. You can’t ignore an error without saying out loud that you’re ignoring it. That forces you to be honest about what can break, and that matters a lot when you’re touching real systems or real data.
Tooling being built in is the other big one. Go got this right early. Formatter, linter, test runner, dependency management, all included and opinionated. You’re not burning the first week of a project arguing about which formatter the team should use. Not a language feature in the classic sense but it shapes the day to day more than most syntax choices do.
The ideal is probably strict enough to catch your mistakes before runtime, readable enough that future you can pick it back up in six months, and fast enough that you’re not paying a tax for the convenience. Nobody’s hit all three cleanly yet, which is why this argument never dies.
My younger brother is the “software mechanic” (compiler guts, military contracts, parallel processing for animation, etc.) in our family, and he is an absolute adherant (if not evangelist) of Go!
I am just too set in my ways to even contemplate looking at Go.
After working with Crystal (a Ruby like language), I really appreciate the value of a built-in compiler.
You work with a Crystal program - running, testing, fixing bugs and adding features, and then when you’re happy with it, just run “crystal build” and you get a 10x speedup with a standalone executable. I haven’t seen that concept implemented like that in any other language.
I tried Go and I didn’t find anything super compelling about it. UPDATE: However, looking at the language examples below it looks similar enough to C, but claims to be scalable, secure and reliable, so those are decent goals and assuming they’ve been achieved then it has use cases for general programming that would make it worthwhile.
Here’s a statement about Go:
" Go is an open source programming language designed for building scalable, secure and reliable software. Please read the official documentation to learn more.
Go by Example is a hands-on introduction to Go using annotated example programs. Check out the first example or browse the full list below.
Unless stated otherwise, examples here assume the latest major release Go and may use new language features. Try to upgrade to the latest version if something isn’t working."
No, the Go programming language does not include built-in, native mechanisms for Inter-Process Communication (IPC) between separate operating system processes. [1, 2] (Reddit quote, I think)
A common point of confusion is Go’s channels, which natively implement message-passing. However, channels are designed exclusively for communication within a single running process (between concurrent goroutines) and cannot span across different OS processes. [1, 2, 3]
Thank you so much Brian, for the clarification and the links.
To quote from one of the links you mentioned:
Go includes in the language itself the concept of multiple concurrent threads of control, called goroutines, running in a single shared address space and efficiently multiplexed onto operating system threads.
Indeed no inter process communication, but for me personally it comes close enough: Native multi threading and inter thread communication (channels), which is - again, for me personally - a very attractive feature. Message-passing changed my programming style for the better (cleaner and more modular code) and my next language must have it.
@tkn I’ll freely admit that I have NOT been a particularly keen fan of the Go Programming language, but after actually taking a look at it, the syntax is not too tough; it’s actually similar to a few of the major programming languages, including C, but when it comes to security, it has C beat. I’ve supported C for a LONG time, and for systems programming I still don’t want to give up on it; people at that level ought to know how to use it properly, and when they do, C STILL delivers. At an application level, which is where Google usually is, except when they’re working on Android or Chrome OS. My guess is that they probably prefer Go to C everywhere in their infrastructure and over time, that may be the direction they take, and based on my revised opinion of the language, it does indeed appear to be a language that was actually needed and useful.
I don’t get into the weeds very often to look at code, but one of these days I may do so, just to see if Go, Rust, C, or something else is providing the guts of major application and system code.
@Brian_Masinick C will always be my ‘number one’ language. It is, in my opinion, the most beautiful and most clean language I know. It may be because I had a thorough formal training in C.
C was not my first language, but it was the one that just hit that ‘sweet spot’.
If you know assembly, then C is very clean and very transparent.
C on QNX had IPC build in. It made use of the native IPC of the OS. It was implemented in the most elegant way I’ve ever seen.
Since no other C implementation has native IPC , I’m still looking for a language that not only has it but also got it right and those languages are hard to find.
The syntax of GOlang looks a bit awkward, especially the handling of channels looks quite alien with its arrow notation. Nevertheless it could fulfill one of my needs.
Until that time I’ll keep on using bash (with extension) as my IPC/OOP language.
It is still very much alive, according to what I’m reading:
" QNX®, a division of BlackBerry Limited (NYSE: BB; TSX: BB), provides the trusted foundation that software-defined and physical AI systems depend on to operate safely and predictably in the real world. For nearly half a century, QNX has powered safety-critical applications where failure is not an option. The business leads the way in delivering safe and secure operating systems, hypervisors, middleware, solutions, and development tools, along with the support and services delivered by trusted embedded software experts. Today, QNX technology underpins hundreds of millions of vehicles on the road and a wide range of mission-critical systems across industrial controls, robotics, medical devices, commercial transportation, rail, and aerospace and defense. QNX is headquartered in Ottawa, Canada."
Reference: About QNX | Real‑Time OS for Safety‑Critical Systems