> name: 'go'. you can invent reasons for this name but it has nice properties. it's short, easy to type. tools: goc, gol, goa. if there's an interactive debugger/interpreter it could just be called 'go'. the suffix is .go.
I'm surprised that the ability to search easily didn't come into their consideration, given ... well, it's Google.
I'm not a Go developer, so I have no idea of how big of a problem this is, but the fact that there is a commonly used second name 'GoLang' hints to me that this became a problem quickly.
Go was invented by the Bell Labs contingent, not people who care about Google's products.
And C++ is called "cpp". It's a non-issue, not a problem. And it fits the Go ethos of not overcomplicating the whole language to address minor concerns.
But that isn't for searchability but due to + not being permitted in names in some filesystems, or being rejected by some tools even where they are valid in filenames in the current environment, so file.c++ wasn't a good idea.
The ability to find things in a global search engines was not the concern that it can be today back in the early 80s when C++ was named, so this is not really a like-for-like comparison, and anyway a quick test in common search tools shows that searching for C++ seems to work well enough.
I have been using Go since the day of the public release. Search has never been a problem for me. I have never used the term "golang" when searching anything Go-related online. People do it, but it's not required.
Yes and no. If you are searching for jobs on a job board website, then perhaps, but to be frank, while the technology used is an important criteria in selecting for a job, if someone advertises as hiring "golang developers" I would never want to work in that shop and I do not believe I am particularly unusual in my choice.
I am an engineer, and a mathematician, but more importantly I am a generalist. I have worked from hardware, to firmware and operating systems, up to compilers, programming languages and formal systems.
I like to work on interesting and difficult problems that force myself to gain expertise into new niches. The way I approach the solution matters -- I will never use Java for example -- but it's the problem that matters more, not the technology. If someone is looking for "golang programmers", they don't tell me anything about their problem and the chance of being an interesting and difficult problem is very low.
Furthermore, if they think they need Go programmers specifically, they are very deeply mistaken as an organization, which again is a red flag. For a generalist job, general experience matters much more than Go experience. I will happily hire someone who never worked in Go before for a Go position if I feel they have the actual important skills and experience that matter. Sometimes you need to hire specialists, e.g. someone with experience in the Go runtime for some very specific job. That is rare, but even then, the relevant experience is the experience with the Go runtime, not Go experience in general.
But even worse than that, advertising like that tells me that the job ad is not written by a Go expert. It's either written by a corporate HR drone, in which case I don't want to work there anyway, or it's written by someone who doesn't really understand the Go ecosystem very well, in which case I also don't want to work there. I will only work with organizations that have expertise in the technology they are using and where said experts write the job descriptions, because they are the only ones that understand what and who is actually needed, and why.
And to add another point, I don't believe in specific titles and rigid hierarchies, but in my experience, it's a huge red flag for an organization to use the terms "developer" or "programmer" in their job titles, instead of "engineer". Not that there's anything wrong with these terms, I personally like programmer, and most organizations that hire "engineers" don't do any engineering, but for whatever reason, the former organizations are worse than the latter.
Yes. Programming in C++11 was an overwhelmingly better experience than before. C++14 is, additionally, much more fun.
Coding C++17 is better than C++14, mainly for its destructured bindings and improved variadics.
Coding C++20 is much better, again. chiefly because of Concepts, but co-routines will become increasingly important as library support surfaces.
It has been a long time since I shipped a memory usage fault. Languages that promise to make those impossible are hyped now, but their promoters are "fighting the last war".
What makes the difference today is productivity. C++ is still leading that charge. Hype notwithstanding, more people take up programming C++ professionally in any given week than the total paid to code Rust. Soon, many of those Rust coders will begin to jump ship for newer languages.
What makes you say that C++ is leading in productivity? I'm not seeing C++ web applications, or machine learning frameworks. From my own experience, managed languages are easier to write for as well, especially with the average C++ code base which barely touches upon C++14.
If productivity is "the current war", then languages like Go, Python, Rust, Elixir, and TypeScript are definitely fighting it, and it's not clear to me that any has significant lead in anything but limited areas.
Video games are overwhelmingly coded in c++. C# is now more and more popular because of unity, but most AAA games (and their engines) are still made in c++.
Also consider the large amount of qt-based apps still running c++.
In the case of game engines, productivity is less important than performance. Most games use some scripting language on top of C++.
I agree that C++ is somewhat productive through Qt, but then again Qt is just one area of many - and QML is an acknowledgement that JS can bring greater productivity than C++ within Qt.
Having done lots of both QML and QWidgets there are many tasks for which I feel I'm more productive on the latter. There are also regular posts on the Qt mailing list asking for a complete c++ version of Qt Quick, and people who kinda implemented a similar thing in another library (QSkinny iirc?)
Like, in c++, I just type approximately what I want, especially when writing glue code or creating a new api, and add compile-time checks & fix compiler errors until things build which is a super fast process ; with QML (or other less strict languages) it takes much more time in a slower edit-run cycle to write correct code.
And this is mainly due to new c++ features: what would have taken fifty lines to define a static check for in c++03, 30 in c++11/14 with e.g. enable_if, takes at most a couple in c++20 with concepts
>QML is an acknowledgement that JS can bring greater productivity than C++ within Qt.
That's not what my friends who still do Qt jobs tell me. They consider it more of a hindrance because you're limited in what you can do. And it's buggy.
In existing code bases, new subsystems can be fully modern.
Old code can be modernized incrementally, e.g. replacing uses of naked pointers with smart pointers and then deleting destructor code, or replacing C-style for-loops with modern range-style for-loops or calls to standard algorithms, passing a lambda. Many class declarations can be eliminated by using lambdas inline. A sweep throughout a big codebase just modernizing one kind of thing may take only a few days. This typically results in deleting a great deal of code, and all the bugs in the deleted code evaporate.
> Early in the rollout of Go I was told by someone that he could not imagine working in a language without generic types. As I have reported elsewhere, I found that an odd remark.
> But more important, what it says is that types are the way to lift that burden. Types. Not polymorphic functions or language primitives or helpers of other kinds, but types.
Go always had generics: slice, map, channel. Writing without those I also could not imagine working in.
And if anyone's curious how instead of making Go, C++ could be refactored into a smaller cleaner language, see "Can C++ be 10x Simpler and Safer?"[0]. It even allows for a memory arena that's managed by gc.
Sure, when a random programmer on the street says a language "has generics," we mean "generics that I can use to extend my data model," or something similar.
But in this talk, we have one of the creators of the language saying "you don't actually need generics," when what he meant was "you only need the generics I gave you."
Go has, from the very beginning, acknowledged the importance of generics, and offered them to users of the language. But, until fairly recently, Go didn't trust users to use generics in any but a few specific cases.
Well, I think so. I only became a Gopher about 5 years ago and the pace of change has actually been faster than I expected, but it always seems to be in the direction of simplification. Examples of things that made life easier since I started using Go are modules and go:embed.
Of course, an exception is generics, which I haven’t yet had much to do with, and while it potentially scratches a personal itch of mine (I always felt that builtins like ‘append’ and ‘len’ were overly magical), I worry that it’s a complication.
I'm surprised that the ability to search easily didn't come into their consideration, given ... well, it's Google.
I'm not a Go developer, so I have no idea of how big of a problem this is, but the fact that there is a commonly used second name 'GoLang' hints to me that this became a problem quickly.