I kind of feel like it goes without saying that Rust isn't ideal for beginners. For developers who already have a good knowledge of other languages I feel like learning about these things shouldn't be a problem, as becoming familiar with these concepts is one of the main benefits of learning Rust.
I think that depends on, first, what the goal is, and second, what you're comparing to. It think Rust is easier on beginners, in many ways, than C. And C is easier on beginners, in many ways, than assembly or machine code. But if you want to really understand computer programming, starting at machine code or at least assembly isn't a crazy way to start.
I can also see (having experienced it myself, albeit I already knew C etc. these were not requirements and many of my classmates did not) beginning with a pure functional language where all the practicalities are abstracted entirely.
Today the University where I learned this begins with Java, which I am confident is the wrong choice, but the person who part-designed their curriculum, and is a friend, disagrees with me and he's the one getting paid to teach them.
I mean sure. But equally, starting with Python isn't a crazy way to start. And Python is much easier language to learn than any of those (esp. if you want to actually create something practical with it).
https://www.amazon.com/Writing-Interpreters-Compilers-Raspbe...
It's also popular to write compilers in distinctly non-"systems-y" languages, most notably Standard ML but also eg Haskell, and lots of languages are self-hosted.
I see meta programming as anything that deals directly or indirectly with ASTs. Compilers (er parsers and linkers) make ASTs and transform them. Refactoring engines (should) work with them.
Sadly, I’m not sure what language I’d recommend as ideal for this (meta programming) now days. I think it’s zen cool when a language like Lisp or Zig or Elixir slides sideways in and out of meta programming, but that doesn’t mean they have good ASTs to work with, or that they’re ideal as a pseudo language to manipulate them. It should be something that is both not too complex, but also not so zen abstract that you have to bootstrap meaningful things endlessly.
I personally liked the Smalltalk AST. But I couldn’t speak to its pedagogical or industry value as a meta programming environment.
Racket (a Lisp) and ML-family languages like Haskell are really good at manipulating arbitrary ASTs and similar structures. ML was even invented to do exactly that, the letters stand for meta-language.
I do agree that the structures you need to represent Haskell would be rather complicated: Haskell is a rather complex language after all.
I'm not sure what you mean by having to bootstrap meaningful things endlessly? I can understand that eg C is pretty limited, so you have to put in lots of effort to bootstrap to something meaningfully. But most higher level languages would be doing just fine. And you can also use libraries:
Eg no need to write your own parser from scratch, if you can just use a parser combinator library like parsec. Also no need for a beginner to write native code generation from scratch: just use a library to interface with llvm.
The overlap comes from two places:
(1) If you want to generate fast code, you need to know how your target works. That's pretty low level, and could be considered systems programming?
(2) Many people want compilers themselves to run fast. Here again, the way to get the most speed out of your programs is often to go low level (and again we could see low level as a synonym for systems programming?)
Given that Bastion written in XNA, and widely successful, then from your list C# is a system programming language.
Or maybe Java is one, given Minesweeper and bare metal deployments like those sold by PTC and Aicas.
Unless your systems code runs using a JIT.
For a C programmer, the Rust borrow checker is likely to elicit feelings of relief and jubilation “You mean I don’t have to spend another afternoon in valgrind tracking down use after free bugs? Awesome!”
So far, C, Scheme, Python, Haskell, Erlang, Rust etc haven't been too hard. (Though I'm not sure I'm cut out for C++'s antics or Java's dependency injection.)
OTOH hand languages like python (and especially JavaScript where pipelines of pure data transformations are already idiomatic) don’t use references much anyway, so use of them is new and doesn’t come with so many expectations.
The C++ programmers who have been using std::unique_ptr have absolutely the easiest time learning Rust as Rust is basically C++11 smart pointers on steroids. These C++ programmers usually have the opposite problem, there’s things you are allowed to do in Rust, that you can’t safely do in C++ without copying.
Then there are C++ programmers who are still using C++98 style for whatever reason (commonly gamedev) and they don’t benefit from any similarities because their style of C++ is so old that there aren’t any similarities.
Indeed, there's a subset of C++ (and C) programmers who get Rust almost immediately, because they've effectively been informally using a similar ownership model in their C++ (/C) code already. But there's another subset who write "fast and loose" C++ (/C) on the principle that "it's fine if it works at runtime", and they tend to really struggle.
Extremely low level programming would be their motivating goal, even if they don't know it yet.
On the other hand, if they’re fascinated about cryptocurrencies, Rust would be a logical choice.
I think there's merit in learning assembler because you then appreciate what all the other languages are doing under the hood, but then python is also good for getting something done quickly.
I suppose it's what scratches you itch. If you want to print out "hello world" quickly and easily then python is a better bet. If you want to know the mechanics, assembler is the better bet.
I've long suspected that the CS field was founded on two approaches: The people who started from EE and worked their way up, and the people who started from Math and worked their way down. The former people think assembly is the "real" way to approach software, and probably view C++ as "very high-level", whereas the latter people think everyone should start with a course on the lambda calculus and type systems and gradually ease into Haskell, work down to Lisp, and then maybe deign to learn Python for *shudder* numerical work.
Basically in computing, there's mathematicians who want to deal with languages and those who want to deal with numbers.
Math itself is all about communication. Finding a new theorem is neat, but it's only proper math once you found a proof for it that you can communicate to other people.
The best thing I did was start doing minor contributions to opensource Rust libraries, I did a small PR for arrow2 and polars which taught me a lot, and also the maintainers and contributors there are incredibly friendly and helpful.
The problem is that we seem to believe there is something 'inherent' about the way Rust solves these problems, and that by doing so with Rust lifetimes, we solve some kind of inherent issue in software.
This makes us believe that Rust = Value in some ways which I believe is wrong.
Rust is only 'one way' - and it may be far more complicated than it needs to be and in many cases more complicated than it is worth.
I feel that Rust may be an experiment, our 'first attempt' at advanced compile time safety, like it's a kind of C++ whereas the Java/C# of memory safety will happen once we've ingested all of these lessons.
Funny I feel that with Rust 'There's a much smaller and clearer language struggling to come out' like what Stroustrup said about C++.
The only successful C++ code bases I've worked on were multithreaded, and most were also asynchronous.
If you assume those design decisions are required, then you'll find that programmers have to reinvent the borrow checker in their head and manually apply it to code in whatever language they're using.
That's incredibly boring and tedious, and people are demonstrably terrible at doing it. Rust automates away all that stuff.
I don't know of any approach to threading or I/O that doesn't rely heavily on reasoning about ownership and mutability. In that sense there really is only one way to do it.
Erlang's message passing style is interesting here. And so is eg Software Transaction Memory that you can try in Haskell.
Have a look at deterministic parallelism, too.
it just hides who owns the message data object though, no ? The problem is still here.
e.g. for instance I work on a C++ software where there is a lot of message passing across threads, but the OS thread on which "malloc" and "free" are called for the messages and any data they may contain really, really matters - some threads must never call "malloc" or "free" under any circumstance. Would I be able to manage this with Erlang, knowing that every thread should be able to send message to pretty much any other ?
Also, looking at that code... https://www.erlang.org/blog/message-passing/ I don't really see what this gains me over the trivial C++ solution:
processing_thread.message_queue.send([=] (Context& ctx) {
int x = ... some computation ...
ctx.ui_thread.message_queue.send([x] {
... show some info ...
});
});
Erlang messages have a semantic as-if there are copied. (Because that's the only way to do it over a network, and Erlang wants to be agnostic over whether two 'processes' are on the same machine or not.)
Erlang doesn't need to worry too much about ownership, because it has a garbage collector.
If you want to explicitly control which thread uses malloc/free, then Erlang isn't at the right level of language in this case.
I think that approach could be called pessimization. The assumption that some components are on the same machine, or better yet the same address space, unlocks some significant optimizations. Sometimes you can be sure that a particular system won't need to scale beyond one machine. And of course, the more efficient the implementation is, the bigger a system can get without having to scale beyond one machine. (Aside: I was reading earlier today about how Uber heavily uses microservices. I wonder if Uber could be a monolith running on one machine given the right architecture and implementation.)
Throughput-wise, that might be possible for all I know.
For latency reasons, you'd probably want to have at least one monolith per city. Similar objections apply for redundancy and resilience.
Splitting your system into individual services ensures that there are well-defined interfaces between the different parts.
In principle, you can always wring more performance out of a system, if you are allowed to break down these interfaces. But that makes maintaining and further developing these systems harder and harder to do for mere mortals.
Have a look at how much of a kludgy mess our genome is for an example.
---
In principle, you could write something as individual services but compile them into a single binary that runs in a single memory space on bare metal (see unikernel architecture). A sufficiently strong type system could make sure that any one service being buggy wouldn't bring down the rest of the application.
You could probably even work on a system like the above that still allows you to replace individual parts without restarting everything else.
This could be much faster and smaller than traditional micro-services that live in separated processes or even machines, but even this utopian system would still be hampered by the conceptual walls between services that can only talk to each other via well-defined interfaces. (Even if your compiler is smart enough to do a lot of inlining etc.)
---
The discussion reminds me of exokernels. Have you heard of them?
Basically the idea is that traditionally operating systems are supposed to have at least two functions: abstract hardware, and safely multiplex different uses and users.
Serving two masters means serving neither of them well.
So the exokernel people say: let's just use libraries for abstracting over hardwarde, and let the operating system present the hardware as raw as possible and concentrate on safely multiplexing.
See eg https://www.classes.cs.uchicago.edu/archive/2019/winter/3310...
You seem to simplify Uber's tasks to only ridesharing. But there are many other typical tasks for large tech orgs. For example (never worked at Uber, taking from my imagination):
1. Handle ride-sharing business (the easiest part maybe).
2. Make a pipeline to extract data for legal requests from courts, processing all Uber's historical logs.
3. CEO asked to make a forecast (like chart), using billing data from their financial processor.
4. Serve video and quizes and check tests during driver's onboarding process.
5. Monitor/alert internal network for network security purposes.
6. Gather some analytics over Uber's cloud resources spent and give recommendations on where to optimize.
Not sure how to pack those all into a monolith.
There are definitely other ways to do things in concurrent programming, such as isolating data structures to a single thread etc. and other forms of synchronization etc..
Rust is a stellar language, and there's a lot we as a field can learn from it. Its borrow checker is pretty amazing for optimization, but it can be a detriment for a program's overall architecture, not to mention the difficult learning curve, which people tend to underestimate as an issue.
I want Rust to grow and succeed in the realms it's uniquely suited for, but I think we can make a general purpose programming language that combines its features in a new way and brings its strengths to the rest of the programming world.
For example, we found a way to recreate the borrow checker based on regions [1] on top of a foundation of shared mutability with reference counting (or generational references [2] in Vale's case).
Another example is inspired by Rust's RefCell; we found a way to decouple it from Rust's usual aliasability-xor-mutability rules to make it more flexible, in something we call Hybrid-Generational Memory. [3]
If we succeed, then we'll have found a way to get the borrow checker's benefits without its complexity. We're a little over halfway done with implementing the region borrow checker [4] and haven't broken ground on HGM yet, but we're well on our way.
Hopefully Vale will be the smaller, clearer language that's struggling to come out of Rust!
[1] https://verdagon.dev/blog/zero-cost-refs-regions
[2] https://verdagon.dev/blog/generational-references
[3] https://verdagon.dev/blog/hybrid-generational-memory
[4] https://github.com/ValeLang/Vale/tree/master/Backend/src/reg...
Good luck.
UIs generally change a lot, errors aren't so critical, and there are types of abstractions and complexity that just don't exist at the lower layers.
You could so some of the 'core' stuff in rust, but people building UIs would want to use a higher level language.
Imagine writing websites in C. Why would you want to do that, even if you could (aside from novelty).
It's quite beyond the scope of rust.
C++ was out in 1985, and qt's first version wasn't until 1995, with kde starting in 1997. And these were simpler times.
I'm very not convinced that lack of GUI is a rust specific problem
I agree if you mean: "Beginners should be using Python, Ruby, Java, etc."
People who suggest that "Beginners should be using C." have blocked out from their memory the trauma that is "Segmentation Fault (core dumped)."