Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position
Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.
Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolkit would look like, particularly because the traditional tree-of-widget-objects design of C++ GUI toolkits appears a bit inconvenient to realize within Rust's stricter semantics.
IOW, "are we gui yet?" might depend on some sort of new written-in-Rust GUI toolkit to appear. There's 20 years of work by many hundreds of people in Qt, many of whom rallied not just around Qt specifically, but around projects using it. Getting that many people moving isn't easy. Alternatively, major progress has to be made on bindings and bridging to the semantics of other languages in Rust.
That said - of course C++ was around quite a while before being adopted by Qt.
Expecting that is wishful thinking. The fact of the matter is making something like that is an insane amount of tedious work and 99% of the time it is started up by people playing around with the concepts and abandoned once the initial fun problems are tackled. Something I am sure will happen with limn.
It is fair, as whether it's possible for the community to contribute is a moot point if the community wont contribute.
Heck, GTK+, which is used by millions, had just one person working on it full time a few years ago (not sure if changed since), and lamenting how there's no community help in the project's blog. And that's for a hugely used and know project. I doubt a Rust UI lib would get more than that.
This is not true for GTK+ 3. GTK+ 2, however, has been in maintenance mode since the introduction of GTK+ 3 and has been in that state since.
Well as I had already said in my previous post, the community did want to contribute to Sublime Text but couldn't. Hence why I posted my rebuttal stating the original examples weren't really fair.
Your revised example is far more apt however in a roundabout way it just reinforces my original point. Since, by your own admission, any Rust UI lib is unlikely to see many dedicated contributors; it would be daft to criticize limn for a trait that you have just acknowledged would be typical for any Rust UI library.
To put things another way: if the project had stalled for months at a time then I could understand people's skepticism trusting the maintainer. However a brief period without commits during the holiday season seams more than reasonable for an active project. Particularly when you even comment afterwards that any similar project isn't likely to see more active development anyway. So why single this one out as being less trustworthy? It feels very much like your applying double standards here.
To use a personal example, an open source project I actively maintain only yesterday saw it's first commits since the end of November. But I am still very much committed to that project.
There's no version of that concept that's sane at this time, though. Wrapping full-fidelity APIs the browser engine has access to in a lossy abstraction layer of shoddy web platform APIs isn't a practice Servo can improve upon. It takes improving those APIs.
There's a small number of macros that a custom preprocessor expands to (very pedestrian) generated code, but they are optional to use (though it's certainly uncommon not to use them) and these days there's template-based versions of some of them that are preferred and steadily finding adoption over the macro ones because they're superior. Beyond that there's a few more normal preprocessor-based macros that are entirely optional.
In that sense Qt also tracks vanilla C++ very closely and has adopted features from newer language versions at a fairly steady pace and swiftly for such a large production library set.
None of this matters much to my point though - that was about much more basic language semantics like classes-based OOP and the absence of ownership rules.
I need to fulfil task X, with tool Y, then I choose language Z among those supported by Y.
Not I chose language Z, then try to find some kind of Y, that helps me solve X somehow.
When C++ came into the picture we got Turbo Vision on MS-DOS bundled with Borland compilers, Apple adopted Metrowerks tools and used PowerPlant, OS/2 promoted CSet++, UNIX guys were into Motif.h++.
Then came Windows, Borland pushed forward with OWL followed by VCL. Microsoft created MFC, adopted by Symatec and Zortech compilers.
Apple eventually went Cocoa, and Microsoft UWP as of latest.
And then there is Qt, literally the only game in town for C++ GUIs not related to any OS vendor.
Followed by what in possible in Java and .NET eco-systems.
All with good visual tooling support, allowing for productive workflows between developers and designers.
I am not saying that Rust some day won't catch up, and offer something similar in terms of productivity.
I hope it does, but right now in 2018 it doesn't.
So, even if we consider a web app as a GUI, Rust wasn't invented for writing that (you still use CSS, HTML, JS etc for that part). It was invented for writing the backend for that UI.
In other words, Rust is not GTK (a UI library), it's C (the language the UI library itself is written in).
But that's not the only constraint. If you want to save memory, due to the environment you run on, or your workload, a non-GC runtime can be pretty awesome.
And in my experience, it's way easier to reason about allocations in Rust that it is in Java (automatic type erasure if you want to use generic code) or Go (how will escape analysis behave in that case ?) for example. Rust traits are way better than C++ interfaces in that regard also.
Rather languages in the Oberon and Modula family, D, Nim, Eiffel, C# as of 7.2, Common Lisp, and a few MLs.
If you do RC everywhere, using library types, it is slower than a tracing GC, and still not as productive.
Borland was in the process of doing it for Delphi and C++ Builder, but I don't know the current state. Originally they were only replicating the Metro UI, back on Windows 8.
Since cloud providers do all the plumbing, Rust would only have to deliver a tiny Linux binary for the function.
There is nothing in Rust that makes it inherently unfit for APIs or the web. To dismiss the entire language is simply lazy. Having GC also doesn't necessarily make one language superior to another.
While http ecosystem is still in active development, if there was really a choice between Rust and JS for e.g. writing an API I would go with Rust in a heartbeat.
Having a GC means having easier ergonomics to write data structures and distributed algorithms.
I do like a lot Rust's type system, just the ergonimcs aren't quite there yet.
You're correct, but "Rust isn't easy to use for purpose X just yet" is substantially different from "Rust is inherently unfit for X"
I do agree that there are holes, and that's part of being a young ecosystem, but I think you're being a bit too pessimistic. I understand this deeply, as I was once too! As things have evolved, my opinions have changed, though.
Please explain me where is this idea of slow development time coming from? Is it only because people try Rust for two weeks, cannot get the lifetimes and decide the development speed is slow?
why? I do this all the time. Maybe I should check into a nearby asylum.
But as far as using it as a full featured web framework, a la Rails, Django or even Laravel, I can see why people say it's got a long way to go.
That said, I haven't built anything production or large scale in Rust, so I can't claim to be an expert.
...and that is flat out the case for c++, unequivocally.
In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at.
Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services.
Its definitely a good goal for the year~
Arguably, this is why Google made go.
But I'm not sure c++ micro services are a terrible idea. I think the real problems come with a) feature creep as opposed to writing new micro services, and b) the temptation to write "fast" c++.
Just writing plain obvious c++ should give you a leg up on most languages (esp for micro services). But then, rather than refactor and think about the algorithm and data structures (and get a 10x performance benefit from a simpler solution), you could probably get a 2x improvement from a more convoluted, "special" c++ implementation.
And that's where you're likely to encounter elder horrors lurking.
[ed: I'm however more and more convinced there's no such thing as "plain obvious c" that doesn't have a number of serious issues along the lines of not checking mallloc return values, to utf8 string handling etc.]
If you do, make sure it says "believes in micro-services" on the referral ;-)
Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a simpler language.
Using a safer language makes it easier and less prone to out-of-bounds memory accesses.
By using C/C++ you're choosing to make a hard problem harder.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
Oh and btw, "out of bounds memory accesses" are not the primary source of security vulnerabilities at all. In fact, such out of bounds access is more likely to just make your program crash (which is a good thing).
It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.
A common theme in the C++ community is to advocate C++ to devs that only see Assembly and C89, and don't see any reason to move beyond that.
Most recent example "Embedded & C++ - Meeting 2017 Keynote"
Everything else is Spring Boot (java), Akka (Scala) or Nodejs. Apparently nobody wants to embrace a language designed for offshoring, so no Meetups, noisy user groups and so on... even Clojure is more popular
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"
"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"
So a language that makes it quite easy for enterprises to deal with developers as cogs.
Source:
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...
Projects where the languages are easy to pick up and anyone can do it, are always the first on the pipeline to give away.
Just like it happened with Java.
If you're making the weaker claim that Go's design "can" have the effect of triggering outsourcing, then that's speculative and consequently rather difficult to refute. But you haven't provided a single piece of evidence that this has actually occurred, so far as I can see.
Lets see how it looks a few years from now, given that it is becoming a mainstream language thanks to Docker and K8s adoption.
So Go is in the right track to follow their path.
Plus the performance benefits will be nice.
It doesn't mean that your services are written in C/C++.