It's a very solid language in the no-GC niche and shouldn't need a blog post from every project that uses it.
Does it have to be 30 years old before it's not "new" and weird?
For my many colleagues who do not read HN, Rust is something that they might have heard of but haven't given any real attention to. For that matter, most haven't looked at golang either and they probably couldn't tell you what the difference between the two are.
IMO it will take a while before it grabs the attention of the mainstream software community.
I tried playing with Rust and found the syntax to be off putting. I really wonder why each new language feels it is important to come up with a different syntax to say the same stuff. Go did a lot better than Rust in this respect, at least in my opinion.
It may be that appealing to C programmers isn't a thing any more, but if it is, then Rust could have done better. And, yes, I get that the syntax isn't the selling point of Rust, trust me, I get it. I just don't get why make people wade through some weird syntax when you don't need to.
Rust kind of went in a different direction. Why? Understanding C syntax is pretty basic, there are a lot of C like languages. Why not be another one?
Personally, if every language was just a C variant I'd be happier. It would feel like "OK, I've got the basics down, let's go explore this dialect that added garbage collection and strings as real types" rather than "I want strings as real types, darn it, I need to go learn this Tcl language". That might be an extreme way to make my point, but I think it's clear, right?
* Assignment as an expression is bug-prone
* The precedence for the binary operators is wonky
* Optional braces in if statements make the grammar ambiguous and is also bug prone (the infamous Apple goto bug)
* The type-declaration syntax is convoluted and people need tools like cdecl to understand the more tricky ones.
* The cast syntax is ambiguous and resolving this ambiguity relies on adding dirty hacks to the lexer to tell the parser about type names.
Can be fixed without syntax change other than returning void.
> The precedence for the binary operators is wonky
But that's the precedence everyone is accustomed with. D enhance this by forbidding some non-parenthesized dangerous expressions.
> Optional braces in if statements make the grammar ambiguous and is also bug prone (the infamous Apple goto bug)
I've definately seen such bugs.
> The type-declaration syntax is convoluted and people need tools like cdecl to understand the more tricky ones.
This is fixed in languages that still feel C-like in syntax.
> The cast syntax is ambiguous and resolving this ambiguity relies on adding dirty hacks to the lexer to tell the parser about type names.
Yup.
Here's an example. When I was doing the GUI tools for BitKeeper 20 years ago I used Tcl because Tk was (and still is so far as I can tell) the best gui toolkit around. But Tcl? Holy moly, what a miserable language (with apologies, and respect to John O, it's miserable). So I got some compiler people to make a second, parallel, compiler that took what looked like C as input and compiled it down to Tcl byte codes.
Pingo! All the power of Tk but with a C-like language on top. And you can call the tcl library code and it can call you.
All open source at http://little-lang.org
I wish someone would take the ideas there and make a gcc/clang dialect that had all C stuff but added in a ref counter and real strings, etc.
"Why would Rust change the syntax to say the same stuff?" Well, Rust is able to meet all of C's requirements while addressing one of C's big old warts: lexical analysis of C code is Very Hard. (e.g. if this particular build added "-DFOO" or "-Ibar/" to the command line then maybe there's a syntactical error or not).
This means that writing robust tools to analyze or modify C code is Very Hard. I don't know if this was an inspiration for Rust's syntax but regardless I'm thankful that they didn't try to reuse C syntax.
Most other successors to C (save perhaps C++) have taken on features that make them unable to write code that we have been able to write in C (bootloaders, OS kernels, interrupt routines, device drivers, etc). Teams had a really legitimate and mostly sane reason most of the time for saying "we couldn't possibly consider Java/Go/Python/etc because we won't be able to meet our product's latency requirements."
This change is much better IMO because there's a clear delineation between types and variables.
The same idea applies to function signatures, which are much clearer to me in Rust than in C/C++.
Some ideas are not possible in C as they are possible in Go/Rust/other languages. With the years, some ideas become more mainstream and then get integrated into the new languages that arise. These new languages need to express ideas that were not expressible in C, and thus may be better served by adopting different syntaxes.
In short: the ideas at your disposition and the ergonomic with which you can express them is a function of the syntax used to represent them. Different languages focus on different ideas, and so it follows that different syntax might be warranted.
Whoever is smart will take note of what happened to VisualBasic and is happening to Objective-C.
If one evaluates C# they should obviously look at what MS are doing. Same thing for Swift and Apple.
C++ is one of the healthiest languages in existance. It hits all the important checkboxes of standardisation, wide industry and platform support and large community.
It is just like trying to compile the Linux kernel with clang instead of gcc, with the source code full of gcc extensions.
In short, we're quite safe in terms of if C#, Swift and Go will live on. They will.
C# and to some extent Swift are also two huge platforms, there are very few organisations out there that would be able to steer their development.
Finally, they are not standardised in any way. MS tried something with 2.0 and then gave up.
My impression is that these two live and die by the will of their corporate masters. I'm not saying they will kill them or anything, that would be pretty stupid of them to do.
They are standardized, you just need to look at the right place.
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
https://docs.microsoft.com/en-us/dotnet/visual-basic/referen...
At the end of the day if a language proves popular enough in other domains outside of the area which is directly controlled by the language maintainers, then the community will usually find a way of taking over maintenance of it.
We've seen this with Pascal, various BASIC dialects (including Visual Basic), and to an extent Java too. The problem with Objective-C was that - as far as I'm aware at least - it wasn't widely used outside of Apple / NeXT's ecosystem so if Apple deprecate support for Objective-C on their own platforms then there's little incentive for the community to keep using language (much like the problems with Visual Basic - which is why few know about it's open source forks). But languages like C# and Go are used massively across a multitude of domains so even if MS/Google were to kill them tomorrow, the community would almost certainly find a way to keep language alive. Heck, Go might even become more popular if that happened since many of the complaints against it are down to the highly opinionated approach of the current leadership.
Let's also not forget that Go and C# tooling are open source so the community wouldn't have to reinvent the wheel like they did with Delphi / Object Pascal and Visual Basic.
Please note that I am not demeaning your statement. It's a legitimate curiosity on my side.
worth mentioning that this term has a broader meaning than how some rust evangelists use it.
one common sentiment promulgated by rust evangelists is, for example, that go is 'not a systems language' because it has a GC. however, this definitional exclusion doesn't seem to align with (evidently broader) historical use of the term 'systems language'.
Yes, it may work with some type of systems, but this does not make it a systems language. If you don't want to accept this fact, then you have bigger problems or you reality is narrow.
Maybe this can help you see through your bubble: https://github.com/CppCon/CppCon2017/blob/master/Presentatio...
I've gotten Rust code to run on an ATSAMD21G18 Arm Cortex M0 (Adafruit Feather board). That board has 256K flash and 32K RAM. Go executables can't even fit in the program flash! Considering the sheer number of systems that have microcontrollers in them somewhere it would be very hard to call a language that doesn't support them a "systems" language. Maybe "applications language" would be more appropriate.
Will it? I don't think so, although I think Swift is great. IMHO Rust targets another market compared to Swift. Rust feels more low-level, e.g. Swift uses Reference Counting for everything. Swift also can't give you some of the nice guarantees you get in Rust.
Go also has some nice stuff compared to Swift: simplicity, goroutines or tracing GC. Go is also already widely used.
Swift is certainly great for Mac/iOS-Development, but I am somewhat skeptical for other platforms. I am afraid that non-apple-platforms will always feel a bit like second-class. It's just not Apple's main priority and most Swift-devs will always be paid by Apple. But who knows, I may be wrong.
You would be crazy to use swift (or objc) in real-time stuff. You would be crazy to write a UI-heavy app in rust. (note: I'm talking about high level DOM-like manipulation, not about rendering engines)
In the same lane of thought, I am in love with Go when it comes to microservices, network libraries/bridges and CLI tools but it's very ill-suited for web development. So I shrugged it off and only do web dev with Elixir.
Conversely, Elixir is awesome for a multitude of things but it absolutely can't compete with Go in its strong areas.
Language wars are pointless.
I think the jury is still out on that one. I agree with the current state of things but the potential to ease and facilitate this is tremendous through the use of syntax extensions (procedural macros) which can dramatically simplify that use case. In general I think procedural macros add a _lot_ of versatility/flexibility to the language. I anticipate that there will be a huge boom in that area once they stabilize, and it will catch many people by surprise.
An example of the versatility that they enable is the work-in-progress async/await [0], whereas in other languages they would usually have to be implemented in the language itself. Note that this does not preclude their implementation in the language itself, but since it's a work-in-progress they're able to experiment with them without having to implement them in the language from the beginning.