I really like Rust, it hits a lot of sweet spots for me – strongly typed, neat type system, the mild functional-ness thats useful while keeping people from going too crazy with functional patterns, usually low on boilerplate, static binaries, clever little things like ? ... but sometimes I wish there was a garbage-collected version of it, the constraints of the borrow checker make things like tree structures at least an order of magnitude harder to get right, and I'd love to have the ergonomics of the language and the ergonomics of a gc-ed runtime. Not going to happen I guess, but I feel like there's an opportunity for a Rust-ish language that is somewhat less finnicky, at the cost of making some abstractions more expensive, for microservices with complex business logic and such.
I actually support the idea of adopting Rust's ideas in a memory-safe, garbage collected language. I like garbage collection—it's not always the right tool, but it's a great tool in the proper domains. Modern GC builds upon decades of research to achieve memory safety at runtime with good performance and very low cognitive overhead on the part of the programmer.
What I don't agree with is the idea of taking Rust's ideas and putting them into manually-memory-managed, unsafe languages. We should be moving away from such languages as an industry.
Swift also has some stuff coming from the history of Objective-C interop (inheritance is the big one I'm thinking of, although I'm sure there are others that are slipping my mind). I'm not sure how mainstream this opinion is, but personally I _prefer_ not having classes and inheritance, and while I could always choose not to use them in my own code, I imagine it's common enough in libraries that I'd end up dealing with it a bit anyways. Combined with the fact that Linux support still seems like it's a bit secondary makes me feel like there still is a potential niche out there for "Rust with garbage collecting" that Swift might not be filling entirely.
Yeah I agree, I think one of the biggest mistakes in Swift was coupling reference types to classes. Choosing whether something is a reference type of value type should have been orthogonal to the class system, if they included classes at all.
But in practice I think modern swift uses inheritance very sparingly, and leans much harder on the protocol/extensions system, which is very well design imo
Swift doesn't have tracing GC, but to be pedantic automatic reference counting is a form of GC.
But that only goes for reference types. For value types you're correct that both languages use mostly static memory management.
I guess in that sense you'd have to consider Rust as a gc'd language as well: the only difference really is that you have more fine-grained control over which mode of reference counting is being used for a given object.
> We present a formulation of the two algorithms that shows that they are in fact duals of each other. .... Using this framework, we show that all high-performance collectors (for example, deferred reference counting and generational collection) are in fact hybrids of tracing and reference counting.
...
> For every operation performed by the tracing collector, there is a corresponding "anti-operation" performed by the reference counting collector.
...
> We have shown that tracing and reference counting garbage collection, which were previously thought to be very different, in fact share the exact same structure and can be viewed as duals of each other.
GC is standalone runtime that does tracing and deallocates memory at some arbitrary time. Are you really claiming that using C++'s smart pointers is using GC? I think you're conflating semi/automatic memory management with GC.
ARC in Swift doesn't have runtime part, retain/release code is injected at the compile time. It doesn't have ie. cycle detector running periodically or anything like that. If you define this setup as GC then by this definition Rust's borrow-checker is also a GC because it works the same way - by injecting static code during compilation (but has different rules).
Chapter 5 of the GC Handbook, one of the major CS references in GC algorithms.
Reference counting is a GC algorithm, regardless how people sell it to the man on the street.
Additionally there is a whole set of politics how ARC had to be sold after the technical failure to make Objective-C GC implementation work without core dumps, due to the underlying C semantics.
Plus making retain/release calls automatic wasn't anything new as idea, VB and Delphi did it first with COM AddRef/Release.
I can attest that so far the lifetime static analysers for C++ haven't progressed that much.
However until certain C++ overloads don't give more love to memory-safe, garbage collected language or languages like Rust, that is better than nothing.
For example, I don't expect Windows team to ever lose their love for C++, NVidia moving from their C++ love for CUDA, or Metal shaders in something else.
Ah, and then many of those languages are keeping C++ around by building on top of GCC or LLVM.
So any improvement towards to make C and C++ safer is better than just using them as they are.
For what is worth, you can opt-into reference counting and internal mutability with container types (Arc/Rc, Cell/RefCell, RwLock/Mutex), and get the same performance characteristics as a GC language (but without a JIT) for the cost of more complex types in your signatures.
Edit:
> the constraints of the borrow checker make things like tree structures at least an order of magnitude harder to get right
The constraints of the borrow checker make those things more unlikely to compile without extra ceremony. The likelihood of getting them right is orthogonal from making the compiler "happy", even in Rust but specially in other languages. The way I've heard it described is that Rust is a language where you get the hangover first. It upfronts dealing with the error conditions of your problem space in a way that (you can argue) hinders the exploration phase, but that makes of a very quiet maintenance phase.
People like to bring up reference cycles a lot as if it's always a deal-breaker, but for short-lived processes it kind of seems like a non-issue. Anecdotally, we've seen Instagram get overall gains by disabling GC in Python (which will still do reference counted cleanup).
Exactly, I like implementing compilers and I personally never bother with anything other than reference counting nowadays. Ref count gives a very easy to reason semantics. So I count as a feature in my language even if it's slower than GC. Moreover, some of the "memory leak" discussions nowadays miss the biggest issue behind memory leak, which is resource allocation. Some people measure memory leak as the # bytes that process didn't deallocate at the time of exit.
> and get the same performance characteristics as a GC language
Pretty sure modern state of the art GCs, like the ones found in Java or .NET runtimes, are way more efficient than reference counting.
Reference counters have that unfortunate RAM access pattern where the counter is frequently updated from multiple threads concurrently. On modern processors, this means concurrent access to a cache line by different CPU cores. These cache coherency protocols are pretty slow. On many CPUs, reading a cache line recently modified by another core costs 300-500 clock cycles, even more expensive than a cache miss and roundtrip to system RAM.
Python is experimenting with a novel approach where objects have two reference counts, one exclusively for the owning thread and another for all other threads, improving performance when most of the increments/decrements are done by the owning thread.
There's some amount of boilerplate that is unavoidable, but, if you have the patience, `macro_rules!` type macros can help cut down on syntactical boilerplate in many cases.
Compared to C, and sometimes C++, there's generally less boilerplate in Rust. Compared to more traditional web languages, though, Rust will seem to have more boilerplate due to it's lower-level design.
I sure hope not. Borrow checker has little to do with memory allocation/deallocation. It's there so that you can't have unprotected mutable shared state.
Kudos to the Rust and LLVM teams for taking performance so seriously! I'm excited to see things get even faster once the new LLVM pass manager is enabled by default.
Rustc supports running with LLVM versions other than 13.0, which some distros enable, but the official builds of rustc all use LLVM 13.0, a pre-release version in 1.56.0, and the final in 1.57.0 onwards.
Anyone using Rust on ESP32? I'm 24 hours into trying and it's dredging up memories of old cross-compile toolchain problems, like trying to compile dependencies as x86 :). Either way, it's a fun project so far so I'm not complaining. Embedded seems like a great fit for Rust for ensuring correctness and speed.
LLVM (Rusts' backend) doesn't support the Xtensa instruction set, which makes this so complicated. The newer ESP32-C{3,6} instead use a RISC-V instruction set which is already supported by Rust, so its much easier to set up.
So far I managed to get basic serial coms working, but am waiting for some HAL so I can build a blinky LED.
No, I started using Nim on esp32's due to the Rust/llvm toolchain issue and found it quite nice. I wrapped much of the esp-idf in a project called Nesper. Though I keep an eye on Rust in the embedded world. Rust type system does seem to require a lot more work creating shared hardware api's.
I remember Pascal compiling crazy fast compared to C/C++. Partly because the language was designed to be easy to parse, but I assume part of the speed came at the cost of producing less optimal code.
But if most of your compiles are during development and debugging where optimization is less important, wouldn't it be nice to have super fast compilation during those stages? I don't know if any other compiled language comes close to Pascal in that regard.
You can even use it as a backend for the Nim (https://nim-lang.org/ ) compiler for subsecond builds of a modern language with various choices for automatic memory management.
Will it allow incorrect code like an interpreter? I edit one controller/view in Django, print something and let it crash. Then I fix it and (hopefully) correct the rest of the controllers.
All languages allow incorrect code that crashes. Perhaps you're referring to compiler-aided refactoring (make a change, compile, inspect the errors, correct, repeat), which yes, Rust is very good at, as are most statically-typed languages.
A big part was that pascal had a decent module system, while C only has includes. The same header files can be included from multiple places and have to be processed multiple times. IIRC the Plan9 C compiler had some restrictions (or maybe just conventions) to prevent this.
Also, Borland Pascal / Delphi compilers weren't terrible at optimizing. And they often produced smaller executables.
From my experience C is very fast to compile. Especially compared to C++, because of the metaprogramming and monomorphization stuff. In C you would use void*.
Dynamic dispatch is faster to compile than static dispatch, but runtime performance differs. You can do dynamic dispatch in Rust, I think it could enable faster/smaller builds but at the cost of worst runtime performance.
While I agree the common pattern is to use void*/dynamic dispatch, this is not necessary. E.g., https://github.com/glouw/ctl/ or https://github.com/c-blake/bst show a couple ways to have generic code statically specialized in regular old C. (Instantiation/specialization is just marginally less automatic/syntactically supported.)
On our C projects back in the 2000's, a full build took around one hour, composed of Apache, IIS ISAPI modules, our own mod_tcl fork, all the TCL database drivers for MS SQL Server, Sybase SQL Server, Informix, Oracle, and several other native modules.
Then we had to repeat it for HP-UX, Aix, Solaris, Windows NT/2000, in release and debug variants.
A release would be a day event, so fast to compile is relative.
While I agree Rust has a steeper learning curve with its lifetime and borrow checker. Why do you surmise that Rust is too syntax heavy? The BNF of Rust doesn't seem anymore complicated than most of the popular languages.
The current trend of Rust seems to to suggest the opposite as well, with more large adopters.
Rust has gotten tremendous momentum behind it—which is great since it’s introducing a lot of useful, heretofore cutting-edge tech from research into a mainstream language. (Thinking affine types.) Tooling is excellent too.
C++ is my bread and butter but I don't want my unborn kids to be raised in the world where C++ is not living at the margins. That's despite of all the awesome people putting their sweat and blood in supporting the little languages additional standards.
TBH, compiled general languages are doomed to be complicated, because they need more info during compile-time. The only exception is C (if you don't count stuffs like Lisp). IIRC, C grammar can be easily printed on a single sheet of letter paper.
C is absurdly complicated (just try to understand all the different arithmetic promotion rules that can apply to an expression like "a + b"), you just don't notice it because it doesn't use that complexity for anything except occasionally giving you undefined behaviour.
I'm not convinced this is true. A simple grammar can express a whole lot of information. I think complex grammar is desirable in some cases because a lot of ways we choose to make grammar more complex are ergonomic. Binary infix operators, various kinds of brackets and braces, ... it all is a bit more difficult to describe as a grammar, sometimes more difficult to learn, but also closer to natural ad-hoc ways that technical people would write things down to communicate them. Just see the typical ways of writing mathematics as an extreme example.
I know this is snark, but there’s an arguably good answer. That’d be Lisp, according to an essay by pg that I’m too lazy to dig up right now. (Probably “revenge of the nerds” or something.) You just write the language in the parse trees.
Brainfuck and Piet come to mind... come to think of it, brainfuck compilers might get mad about unmatched brackets. You can't go wrong with Piet, though.
I do Rust (and C, and C++, and Python) programming professionally, at a company that isn't famous for Rust engineering. I'm happy to answer questions about my supposedly nonexistent job :-)
On the more famous side: Amazon, Cloudflare, and Microsoft all have teams writing in Rust. I'm sure there are plenty of HNers from each who can talk about that work, sensitivity permitting.
I'm proud of the work I do. But the language itself wasn't intended to be a humblebrag.
As far as "very few jobs" goes: sure, it's less than other languages. That comes with any new technology. But it varies heavily by discipline. The work my company does (program analysis and cryptographic research) already has a thriving Rust ecosystem, and demand for engineers is currently above demand for Rust jobs. My understanding is that things are similar in the network engineering space, at least at the larger companies.
I don't know what to tell you: we hired quite a few people this year to do Rust (both programming in it and auditing Rust codebases). And we're a small company.
I assume that it will continue to be easy to find a job as a COBOL programmer for a very, very long time. But what kind of metric is that?
This is trolling, surely. If so, mission accomplished.
Every one of the MAGMA tech companies (Microsoft, Apple, Google, Meta, Amazon) is adopting Rust in significant ways. That is extraordinary; and those companies are only the tip of the iceberg, and what is publicly known lags reality by 6-12 months at least.
Rust won't ever be as widely used as Java or COBOL, but clearly it is already having a huge impact on how infrastructure is built.
I am not a rust fan, but `ever` is a long time, and if operating systems are re-written in rust (which is preferable by far than writing them in C), that is going to be a lot of very widely used code.
The collective has decided that MAAMA is a worse acronym, and I agree.
The reason that Netflix has been booted is because (a) it's not really a tech company and (b) Microsoft's stock has started to grow a lot since Nadella became CEO.
Why would you back your argument related to jobs up with Tiobe which is not a measure of job listing commonality. Hell “assembly language” is listed above PHP in that list, and I can confidently say there are a lot more opportunities for PHP devs that for people working in some assembly.
Your off topic rant on an article simply discussing speed improvements on a compiler seems significantly more ideologically driven than most comments in here.
As I worked on a couple of projects in life sciences, the migration path to VB was those users that wanted to grow beyond VBA so they would eventually adopt VB + WinForms for data processing, they didn't even care for R or Python, Excel and Tableau were they main tools.
The hvasilev's comment got flagged and I could not reply to it anymore, so I'll reply here (sorry) and copy-paste the hvasilev's comment verbatim below, for the sake of commenting on it's claims:
---
Reality is not on the side of this language. 11 year old, has a very low adoption with virtually no jobs associated. (https://www.tiobe.com/tiobe-index/)
On the other hand if you search for "Rust" in the latest "Who wants to be hired?" thread, you will see it is quite popular with unemployed people.
The reality is that the language has a lot of friction, the ergonomics are bad, the syntax is heavy and some poor decision making has been made there for a systems-level programming language.
There are a lot of ideological traps in this industry and many people that fall for them. Why people are interested in ideologies and cults is beyond me.
Now my comments on the issues mentioned in the hvasilev's comment.
> Reality is not on the side of this language. 11 year old, has a very low adoption with virtually no jobs associated. (https://www.tiobe.com/tiobe-index/)
Tiobe index is shit. The most flattering thing I've read about it states that it (poorly) depicts quantity of educational materials available online for particular programming language. Unfortunate naming of programming languages after letters of alphabet, symbols (++, #) and real-life stuff (like islands) doesn't help this rating either.
That said, Rust isn't that popular and isn't growing much according to other better language ratings:
A Github-based rating created by the author of Context Free YouTube channel. For 2021Q3, Rust is on 18th place with Mean Score of 0.82% (up 0.01% from 2021Q2).
... listed on the largest Ukrainian programming site.
---
> The reality is that the language has a lot of friction, the ergonomics are bad, the syntax is heavy and some poor decision making has been made there for a systems-level programming language.
Well, this is matter of taste, largely. But I have a few issues with Rust syntax too (IMHO):
1. F--king single quotes. Eww, really?! IIRC, a tilde (~) character was used for lifetimes until some Europeans (?) complained that their keyboards have no tilde. I wonder, how they programmed in C++ all that time? For years, if I met online a piece of code that was highlighted as a comments mishmash I knew exactly in what language it was. Ugly as f--k.
2. Closures using pipes (|). With no arguments they look like OR operator (||). Distracting.
3. Using angle brackets for generics.
4. Double colons (::) as "path qualifier" produce too much visual noise. Java likes long pathes too and uses dot (.) as separator just fine.
5. What with this arrows (->) before return types? Seems unnecessary. Couldn't return types be purely positional as in Go?
I don't use Rust so it's mostly "glimpses from the outside".
Speaking of friction. This reminded me of a video by Jonathan Blow (creator of Braid and The Witness games and Jai programming language). The video is worth watching whole but piece about friction in gamedev starts approximately at 49:23.
"Rant: Entity systems and the Rust borrow checker ... or something."
As for poor decision making, it was pretty poor decision to include an npm knock off into the language. I'm speaking of crates.io repository. For some time it has a squatting problem that isn't fixed yet:
3 year old thread, the squatter is still there holding 104 packages. At least npm has namespaces.
I wonder, if cargo will turn into malware-ridden micro-dependency hell too?
---
> There are a lot of ideological traps in this industry and many people that fall for them. Why people are interested in ideologies and cults is beyond me.
"MongoDB is web scale" video nicely illustrates "ideological traps" and cult-like behaviors in "this industry".
And what else illustrates cult-like behaviors? Flagging an innocent comment you don't agree with. What was in the hvasilev's comment that warranted its removal? In my opinion, nothing. It contained no insults, no personal attacks, and was more or less factually correct. Rust is relatively unpopular, complex, ideological, syntactically-heavy language with relatively few job offerings, i.e. pretty much what the hvasilev's comment said.
Complaining about the comment being "off topic" is somewhat funny given Rusters' penchant for inserting their language into discussions about other programming languages (especially C, C++ and Go).
> What with this arrows (->) before return types? Seems unnecessary. Couldn't return types be purely positional as in Go?
I guess you could say `->` is too verbose and you can omit it in other languages. Rust has a complex type system and there can be confusing code when you omit `->`.
1. Closure Return Types.
You can define a closure with an explicit return type:
```
let my_closure = |i: u32| -> u64 {
i as u64
};
```
Now how do you omit the arrow here? How do you know `u64` is the return type and not constructing a struct?
2. Parsing stuff
It becomes impossible to parse none-delimited types. Is `fn() fn()` two different types or a function pointer returning a function pointer?
3. Readability
I mean, tokens can be read out loud and omitting it stops making sense.
`fn foo(bar: i32) -> f32` can be read as a "function named 'foo' that takes an argument named bar with type i32 and returns f32". The word returns directly corresponds to the `->` token.
Rust also has the `!` (read: never) type. Poorly formatted code when `->` is omitted is very confusing: `fn a()!` when compared to `fn a()->!`, or just one character generic types: `fn a<T>()T` compared to `fn a<T>()->T`.
> Complaining about the comment being "off topic" is somewhat funny given Rusters' penchant for inserting their language into discussions about other programming languages (especially C, C++ and Go).
The childlike “well they do it too” argument is almost the perfect example of how the anti-rust crowd is becoming even more obnoxious than the infamous Rust evangelism strike squad.
For the record , I’ve never written a line of rust in my life and am not particularly invented in its success or failure. And no, I didn’t flag GP.
You’re not negating anything but a strawman here. You commented too level on an article on someone simply talking about how a compiler whining about something unrelated to the article.
If you were responding to some rust fanatic or if the article was some sort of rewrite in rust call, you may have a point, but it’s nothing but some developer interested in improvements in the compiler. God forbid anyone work on anything other than some mainstream technology.
> why do you think i'm backing my argument to jobs with Tiobe?
You may not be, I assume because it immediately followed the statement about jobs in parentheses.
Try https://indeed.com or http://www.modulecounts.com instead of Tiobe which is one of the worst metrics. The Rust community's module output is well ahead of both Ruby and Go so I'd say it's fairly mainstream.
Graydon Hoare began working on the language that would become Rust in 2006. Rob Pike began working on the language that would become Go in 1995. Neither of these are useful dates because the languages that were eventually produced were drastically different at their inception compared to where they eventually ended up.
For the purpose of maturity, the point in time by which to begin measuring the age of a language is the first point at which a stable release appears for general availability. Go is 9 years old, and Rust is 6.
I think it would behoove you to explain how you're coming up with that number, given that the person you're replying to has pointed out exactly when Rust 1.0 was released.
If we're going by design inception dates, Go goes back to 2007 or earlier.
This is a weird metric to use, given that Rust was incubated at an open source company (Mozilla) while Go was developed for years as part of a private project. Put another way: Rust's development was much more public than Go's was; why should that be held against it?
You're feeding a troll that's managed to derail the point/conversation with an incoherent offtopic comment... I really doubt they care what you or anyone has to say to them (which is evident from their replies). Their comments/replies give you just enough material to pull you in, and then they grapple you to their level. It doesn't even have to be intentional/conscious on their part, but they're definitely doing it.
Not necessarily the troll's motivation, but: there's also a lot of "Rust envy"[1] going around from some people (mostly disgruntled C++ devs who feel threatened by it) who'll baselesly say anything and misrepresent something to prove their point. How does it never cross their mind that they're on the wrong side of things if they have to grasp for lies to prove their points?
[1]: I came up with the term just now, but I'm not sure "envy" is the right word; maybe "petty spite" is a better term.
I'm back-and-forth on whether they're actually a troll. In the best case, they're a non-L1 English speaker who's upset but isn't making particularly coherent points. But things are coming to a close anyways.
I wasn't sure if it's a language issue at first myself (I'm still not completely sure), but based on their replies it seems like it's just a fruitless smear quest because they don't like something about Rust.
Nothing about what I said implies a value judgment about Go (or even Rust, for that matter). This is now the third time this comment tree has gone into accusations of strawmanning. Have you considered that nobody's trying to strawman you, but rather that people are struggling to find coherency in your points?
Rust was announced in 2010. Many sources state it is 11 years old.
The kernel is a crucible. I'm curious to see if it's system facilities are adequate and operate with reasonable costs in that context. We'll have to see, but I am still suspicious of what often comes across as hype.
Uh dude, might want to do a bit of research first. Rust is getting increasingly popular and is close to being an official language for wiring Linux kernel drivers. If that doesn’t count as having made it, I’m not sure what else will.
In my experience Rust has become the go-to language for applied cryptography and is becoming increasingly popular for embedded/iot development. We're currently hiring for both and experience a scarcity of developers.
> There are a lot of ideological traps in this industry and many people that fall for them. Why people are interested in ideologies and cults is beyond me.
Most people who make remarks like that are not nearly as exceptional as they think they are. https://xkcd.com/610/
But just to give the actual answer, it’s probably that:
* Things are not okay. Read any CVE list if you wish to deny it.
* It’s not getting better. In fact, it’s getting worse, because software is getting more complex.
* Making software less complex is a fool’s errand. The whole point of software is that it can be more easily changed than hardware, so just not changing it at all is missing the point. Yet removing features that have been put out there is disruptive, and often selfish, egotistical, and demonstrating a poor organizational structure (I’m looking at you, Google, and your dozens of chat apps). As such, we can expect successful software to monotonically increase in complexity forever.
Do you have a response that isn’t either either: something that a cynic could dismiss as a cult, some sort of “your needs don’t matter” dismissal of features that a lot of people like, or a bleak declaration that the whole world sucks and that’s just the way it is?
I believe that derivatives of this language might be interesting. However we do have to point out what is wrong with it, so it can be fixed in the derivative.
