One related thing that might be of an interest to you is to check out https://www.rust-lang.org/en-US/friends.html ; many of our production users have linked blog posts explaining more details about what they're doing.
I built a order book data storage in Rust. It's kind of like redis but for order book data. I can't imagine writing such a complex piece of software in any other language in such a short time (2 months).
It's the best Vulkan library I've seen so far (Though the C++ one is pretty good as well). It will preprocess your shaders and generate rust structs that are guarenteed to be the same alignment as the structs in your shaders, which is very nice. They also use a future-based API (a la tokio) such that I don't have to deal with fences and semaphores and whatnot myself. The future simply resolves as soon as the GPU is done doing work. It's an amazing abstraction, and really makes you think of your GPU as an asynchronous machine, instead of the openGL hacks that try to hide that from you.
I’ve written a few compiler-related libraries in the past few years for a DSL (e.g. a few LLVM optimization passes and a type checker). I love two things about Rust: it’s easy to integrate into existing C and C++ projects and it’s super easy to build and compile (including dependencies). I dislike a lot of stuff about Rust like the noisy (Perl-like) syntax and strange (and enforced) style rules (Arm not ARM), but they are mostly the type of annoyances you’d encounter with anything you really like.
I forgot to mention another amazing feature: documentation. Rust has speculatcular documentation for beginning, intermediate, and advanced users. Likewise, Rust manages their community so you always know where to look for help (like the managed forums).
I agree that Rust can be pretty noisy in some cases, but I've never really thought of it as Perl-like. Perl's syntax has so much noise so that the language can be enormous whereas Rust is at its core a pretty simple language. Rust code tends to be noisy because it includes a lot of information that you might not care about at the moment
Rust is a powerful enough language where you can do crazy stuff like write inline JavaScript inside of your Rust code, and freely pass data in and out of those JS snippets, and compile the whole thing to WebAssembly.
It's nice that Rust has a macro facility to make this possible. It reminds me of the delightful way that Google Web Toolkit lightly abused the "native" keyword (which marks FFI methods in Java) to do inline javascript.
In my mind Rust macros are easily the least appreciated feature of the language. Nearly every non-trivial library I've had any contact with use macros in some manner to enhance their API and usually the result is very good. For me one of the most compelling things about Rust when I first learned of the language was print!() and how it comprehensively solves the type-safe string interpolation problem better than anything that has ever been provided in C and C++.
If you're using Rust -- tell me, what are you building in it? And what do you love about Rust in your experience while building it? (Get me excited)
I think that it is wrong to think of Rust in terms of internet popularity contests. Its mostly a frustrating and difficult language.
That said, I think that Rust lives up to its hype and is one of the most important languages to come out in recent times. I am writing an SMTP server and can say without doubt, that Rust enabled a much better result than I would be capable of in any other language. I have used Ada and modern C++ in the past and I consider Rust to be an improvement.
I have seen demonstrations of the language Idris that were like looking into the future. However, the larger community and good tooling make Rust a more practical option.
Bearing in mind that I find Rust to be an annoying language there are things that stand out as better than average:
1. Cargo. The only build and dependency tool that has never annoyed me.
2. A very open and welcoming community.
3. Nom, a very weird parser combinator that is a joy to use when you get used to it.
4. Multithreaded programming. For old school C++ multithreading its incredible to write something and have it work first time and not find any weird threading bugs.
5. Coming back to old code is not the painful experience that it is in other languages.
If you are interested in learning a C++ like language, I would recommend Rust. If you are a C++ programmer, I highly recommend learning Rust.
what kind of projects will one want to write in rust? I am going through rust right now , and I find it very difficult, simple stuff like doubly linked list or graph is not very intuitive, especially when you want to update inside rc using refcell.
Any tips for newbie like me on motivation and learning?
What's easy and hard in Rust isn't the same as what's easy and hard in other languages. As a beginner, don't try to learn Rust by implementing data structures, as you need to know a lot of Rust to do it correctly. Here's an entire book on writing linked lists, for example: http://cglab.ca/~abeinges/blah/too-many-lists/book/
What did you do so far to learn? How do you learn other languages, and what other languages do you know?
I read the rust tutorial up to chap 16, currently reading too-many-list and have not read nomicon, I know python, javascript, golang pretty well. And I know a bit of java and scala.
Usually I learn language by implementing data structures: linked list, tree, graph.
If I can do those then I am pretty confident in doing mostly everything else.
Rust is really the first language that I have trouble with writing simple data structure, I have a bit of issue with scala on covariant and contravariant generics and monads, but they are not bad after I learned it.
For rust everything is awesome until I get to pointers since I have to wrestle with nested smart pointer that makes it insanely hard to manipulate, the rc, refcell nesting is just not very ergonomic (maybe once I learn unsafe it will be easier?).
I like rust paradigm alot since it brings safety and speed, so I was wondering if I am missing anything since I am having some trouble.
Gotcha, thanks. Based on what you know, I'd say pointers and stuff like memory layout are generally going to be where you have issues, and data structures are basically an exercise in applied pointers and memory layout. So you shouldn't feel bad! Regarding what you should do next, reading the last few chapters of the book (19 in particular will be useful for you) would be good; and chapter 20 is a project, which it seems like you are looking for. I can also highly recommend the new O'Reilly book as well.
> I was wondering if I am missing anything
Nope, I think it's just that your experience led you astray.
If I need a linked list in Rust, I... well, I don't ever use linked lists (you can read the book for why). If I had to, I'd use the one in the stdlib.
If I need a graph in Rust, I use petgraph from crates.io.
Basically, other people are good at writing data structures, so I use their work as much as possible. Only if I'm particularly interested in a specific structure, or I require one that doesn't have some implementation out there yet, do I try to write my own.
Of course, at some point you'll want to learn it, but it's just going to be frustrating until it clicks. The less frustrated you are with the rest of Rust when that happens, the less overall frustration you'll have.
> (maybe once I learn unsafe it will be easier?)
That's very possible. Often, you can take a C implementation and translate it into unsafe Rust. Many data structures use unsafe internally, and present a safe interface.
Good luck on your journey! I hope it all makes sense for you soon.
Correct me if I'm wrong, but reading through the linked list code it seems as though it's just a linked list structure on top of a normal vector (via the arena class), combining the worst aspects of each.
Yes, it is. But why 'the worst' aspects of each, though? I see it as the opposite: linked lists built on top of vectors combine good cache efficiency of vectors with algorithmic benefits of linked lists (many operations become O(1), or at least in the amortized sense).
Of course, arenas do have tradeoffs - I'll try to summarize.
Pros:
- Completely safe.
- More ergonomic than dealing with `Rc<RefCell<T>>`.
- Improved cache efficiency of linked data structures.
- Fast node allocation and deallocation.
Cons:
- Any two simultaneous node accesses must be immutable.
- Accessing a node incurs the cost of a bound and liveness check.
- Vector growth can be costly and cause a spike in latency.
- Vector growth moves all nodes in memory.
- Removing a node creates a hole in the vector, possibly wasting memory.
Generally speaking, I think anyone learning Rust and trying to implement a graph data structure should first do it on top of a vector. It's easier than other commonly suggested approaches and it's not a bad one either. In fact, that's how rustc builds some of its data structures, how conrod (a GUI toolkit) represents its widget graph, and how Way Cooler (a window manager) manages window tilings.
> Yes, it is. But why 'the worst' aspects of each, though? I see it as the opposite: linked lists built on top of vectors combine good cache efficiency of vectors with algorithmic benefits of linked lists (many operations become O(1), or at least in the amortized sense).
That's really going to depend on the size of the list, if it's larger than the cache size then it's not as quick to iterate over as a vector because it's jumping around to random (albeit contiguous) memory.
> Generally speaking, I think anyone learning Rust and trying to implement a graph data structure should first do it on top of a vector.
That really depends on why your learning it. Typically when I'm learning/evaluating a new language I run through pain points like this because it show you the good and the bad.
I find graphs and trees are common 'exercises' that people do when they try out a new language, but you usually won't be implementing stuff like this day to day. You'd be using a well tested library, not cooking one up yourself.
My advice would be to try and write some 'real world' code instead of programming kattas to get a feel for the language.
yeah, but another thing I am worried is that if I want to get a rust job, I should be able to do interview problems in rust, which mostly consist of linked list, tree and graph.
you'd use a cell/refcell/box or just wouldn't get this excercise as everyone who got past it in rust know it's not easy and critically it's not supposed to be easy.
it's difficult in rust because recurrent data structures are super hard to reason about in general in terms of borrowing and ownership when AOT compiling and you unfortunately must know this to be efficient at rust; this realization is one of the stages of learning the language.
I landed a job w/ Rust, and the programming challenge I was given was a simple C programming challenge to implement a parser to parse gzip headers, to which I did it in both C and Rust.
Nobody hiring for a position that's largely Rust is going to ask you to write linked lists, trees, and graphs. They're going to want you to build something more complex & practical.
> If you are interested in learning a C++ like language, I would recommend Rust. If you are a C++ programmer, I highly recommend learning Rust.
Also, if you are a Scala programmer, I highly recommend learning Rust. There are major similarities, and the ownership/borrowing concept is an improvement over Scala's JVM GC issues.
If we are talking about C++ then the problem is that there a too many build systems and all of them are incompatible.
CMake is quite popular (and maybe most popular) but it's a complete horror in comparison to other build systems, especially for other languages (like Cargo for Rust).
If you need some specific example: try to add a git-based dependency with a specific branch in CMake.
I'm not sure about that. If you have dependencies to other internal repositories and to specific revisions, it is not clear who is responsible. Make can be agnostic, but Maven or NPM probably can not.
Well the first thing I saw there was a critique to Ant because of aesthetics, which I'd argue is a pretty weak reason to avoid a technical tool like this.
Most probably, it will make sense to counterargument or discuss some (or most) of the anecdotes that will end up appearing in that document.
Seems a fitting use case for Arguman! (I'm not related at all)
not OP, but when people say rust is annoying they are almost always talking about the borrow checker.
coming from c or c++, which allow you to play fast and loose with pointers and types, it can be frustrating to find out that a lot of stuff you would normally do in those languages is not permitted in safe rust code. the flip side is that, once you get the code to compile (in safe rust), you are guaranteed not to invoke undefined behavior. of course, you can just use unsafe blocks if you really need to play around with raw pointers a la C.
my apologies if you already understand rust and my explanation was very obvious to you.
I actually see it as a benefit, not something to be annoyed about. And if someone feels too restricted by the borrow checker (like for implementing some library logic), there is unsafe Rust for that.
I am building async web framework with http/2 and websockets support. I think rust is great! You can write high level code, but if you need to you can always access low level system
My project to learn rust was a camera RAW format loader[1]. Compared to the good modern C++ codebase it's based on the end result supports the same formats, has the same performance, is only 20% of the lines of code, and is much safer to use (binary formats are rife for exploits). Doing all that took me less time than I had already spent previously fuzzing the C++ codebase and doing whack-a-mole on extremely scary exploitable bugs. For that use case it was extremely successful.
The next step is to build an image pipeline and editor around it[2][3]. For that the graphics ecosystem isn't as mature as the equivalent C/C++ ones but the possibilities are also amazing. The expressiveness of the language combined with the great LLVM backend means some things like very clean ways to do SIMD/threading become just a joy to use
If only I had the chance to work on this full time for a year... Help would be very much appreciated!
The kinds of things that become possible and even pleasent once you remove the mental overhead of dealing with the fundamental warts of C/C++ are amazing. After this experience with rust I don't see any reason to ever write C/C++ again.
Yup, that mirrors my experience working with binary wire formats and the like.
There's also the added bonus that doing cross-platform code with Rust is a breeze. If you aren't depending on any C libraries you basically get it for free. I had a UI framework that was running on 5 different targets that was a joy to work with. I've done that in C/C++ before and it's a massive pain.
I want to write a source code spell checker with performance better than scspell.
I didn't want to take that on as my learning project, so I instead started with a lint tool that is driven by user-defined regexes.
But I wanted to blog about my experience learning Rust. I wanted a blog that was good with code (so I'm moving off of blogspot finally) and easy to deploy (so no Jekyll) and decided on Cobalt which is written in Rust. There are some features lacking, so I've been contributing back (and have become the primary maintainer).
One year later and I've still not gotten around to my regex-based linter or source code spell checker.
What gets me excited about Rust:
- Cargo
- Level of confidence that compiled code will work because of both the type system and the borrow checker
- Zero cost abstraction (I'm weird)
- Error handling that has similar ergonomics to exceptions, easier to reason about, but can work in any environment. Exceptions can't run in places like the Windows kernel, so you end up using what feels like a fork of the language + standard library.
Misc notes on my experience:
- Borrow checker has rarely been a problem for me. Yes, sometimes it complains but is usually right and easy to fix
- I've never used the `unsafe` escape hatch
The things that frustrate me are nitpicky and I recognize they will go away as the language matures:
- Lack of specialization. e.g. I have a type that I want convertable from/to iterators but the trait for this has a no-op implementation for "convert from self to self", causing ambiguity that fails to compile.
- Can't have a struct implement the function-trait
- You can't specify that a variable should implement multiple traits (like the primary one and Debug). Instead you need to make a treat that inherits all of the traits you care about.
- CI conventions have too much maintenance overhead for an ecosystem that encourages a lot of small packages.
The last one is probably my next step in Yak Shaving once I get cobalt into a "good enough" state for myself.
I'm building a user-friendly database interface for postgresql https://github.com/ivanceras/diwata . It is a very complex application, but rust and elm helps me build it with ease.
As a python programmer, the part I find exciting/motivational is performance -- I can get my hands dirty writing low-level math code to dump weird sounds out to the speakers 44k times per second, accidentally wandering into interesting glitchy sounds that I don't think you would create using higher-level audio tools, and not feel limited by the speed of the language or reliance on C libraries.
(Not that Rust is necessarily the best or easiest way to mess around with low-level audio generation, but it sure is a fun way to learn.)
A full system emulator like QEMU that's built as a compiler generator. The goal is to build new interpretors and stage 1 JITs at runtime that are tailored to specific supervisor states to give good low latency performance before code hits a real big boy JIT.
Targeting game consoles at the moment because of how sensitive those emulators are to latency as well as raw perf, but better a ARM Android emulator is one of the end goals.
My most interesting projects are currently a security focused network sniffer[0] and a sandbox debugger[1] that I came up with while writing the sniffer to inspect what an attacker can and can't do assuming the process gets fully exploited while the sandbox is active.
I'm writing a text editor. I love it, its handling of UTF-8+ strings makes me want to bawl with the amount of time I've dumped into handling that in other contexts. The lifetimes take some getting used to but after you do, the language is a breeze and so much fun to work on.
Steve, what’s your recommendation for installing and managing Rust releases on macOS in 2018 in a manner that’s compatible with Homebrew? Last time I looked into this (early 2017) the recommendation was using rustup outside of Homebrew. Has this changed?
One other note, I heard at least one Homebrew user saying that rustc was compiled from source, and so it takes a really, really long time. I don't know if they've added binary packages, but that'd help.
Thanks for the reply. It sounds like rustup outside of Homebrew is still the best option. I should add, it’s tottaly fine. My only annoyance is that Homebrew’s doctor command complains, but I suppose that’s more of a Homebrew issue.
What are your problems with homebrew? I have my share of them, but I wonder if your problems are more community oriented, MacOS oriented, or brew itself.
I used to love Homebrew, but I recently uninstalled it from my machines and went back to MacPorts. This was motivated by the discovery that the lead maintainer of Homebrew is a huge jerk. The tl;dr is he deliberately took offense at inadvertent rudeness in someone's GitHub comment that they had already edited to remove (he recognized this and quoted the original form from the email anyway), then subsequently threatened to ban them from the Homebrew GitHub organization for politely asking that their issue be reopened, and when I pointed this out, he banned me and deleted the relevant comments.
I used Homebrew back when it wouldn’t work without chowning /usr/local/bin. I’m not sure if that is still a requirement, but it did leave a bitter after taste.
Beside that, I like to install packages from their canonical source. That could mean installing Go from golang.org to MariaDB from mariadb.org. It’s simple to compare sha256 checksums, which I suspect is also possible with Homebrew, I just don’t know how.
My biggest issue with Homebrew has been it's default prefix: /usr/local. Too many other packages put stuff there, and cause Homebrew breakage.
This is why I put Hombrew in /opt/homebrew. Despite the freakout warnings about this potentially breaking homebrew packages, I have never had an issue.
Homebrew has made binary packages (“bottles”) for rust available for as long as I can remember. You might want to build from source if you’d rather use Homebrew’s LLVM than the one bundled with Rust.
We're aware of the upstream patch existing, but haven't talked about it at all yet.
Furthermore, we haven't upgraded to LLVM 5 yet, and that's the farthest they're backporting, so we also have to sort through that. We were already at work on the upgrade, just takes a while.
This comment and others showing similar concern about the recent appointment of the leader of the rust community team were removed from internals.rust-lang.org and the rust subreddit:
Apologies for posting in this thread, but it seems unhealthy to not be able to question community leaders and other discussion has been stifled. Do rust developers have any comments on this?
As a web developer I haven't found any reason to use Rust yet but I have delved into it recently and I really love the language despite it being frustrating at times. Hoping Lambda supports Rust natively at some point so I can actually use it!
(an aws employee, but just as in the dark as you are)
It'll be interesting to see how the golang lambda implementation is done, as i could see it being a backdoor into supporting any statically linked binary so long as it fits whatever constraints they need.
That's already possible - Apex[0] provides a shim for running golang and Rust, and I'm running headless chrome on Lambda to take screenshots right now (see [1] for an example).
Similar to C; you can do OpenGL stuff, etc. Business logic things work too. It's the same as C; you produce a C abi, load it up the way you'd load up a C library.
Currently harder than plain C or C++, due to lack of integration with mixed debugging on Android Studio, integration with the Gradle/CMake build infrastructure and extra effort of writting FFI bindings to Android native APIs.
It might, never bother trying it, because that is just one of the issues among the ones I have listed, and I skipped a few other ones, like producing AAR libs for example.
Also some of the nicer native libraries are C++, like the newly introduced real time audio, https://github.com/google/oboe
So it is still an higher bar to use Rust than just using what the the NDK/SDK offer out of the box.
86 comments
[ 2.7 ms ] story [ 150 ms ] threadIf you're using Rust -- tell me, what are you building in it? And what do you love about Rust in your experience while building it? (Get me excited)
https://github.com/rickyhan/tectonicdb
It's the best Vulkan library I've seen so far (Though the C++ one is pretty good as well). It will preprocess your shaders and generate rust structs that are guarenteed to be the same alignment as the structs in your shaders, which is very nice. They also use a future-based API (a la tokio) such that I don't have to deal with fences and semaphores and whatnot myself. The future simply resolves as soon as the GPU is done doing work. It's an amazing abstraction, and really makes you think of your GPU as an asynchronous machine, instead of the openGL hacks that try to hide that from you.
I agree that Rust can be pretty noisy in some cases, but I've never really thought of it as Perl-like. Perl's syntax has so much noise so that the language can be enormous whereas Rust is at its core a pretty simple language. Rust code tends to be noisy because it includes a lot of information that you might not care about at the moment
The syntax is light and clean, eschewing redundencies like parens around if conditions.
More lifetime inference and non-lexical lifetimes help to clean it up even more.
Rust is a powerful enough language where you can do crazy stuff like write inline JavaScript inside of your Rust code, and freely pass data in and out of those JS snippets, and compile the whole thing to WebAssembly.
I think that it is wrong to think of Rust in terms of internet popularity contests. Its mostly a frustrating and difficult language.
That said, I think that Rust lives up to its hype and is one of the most important languages to come out in recent times. I am writing an SMTP server and can say without doubt, that Rust enabled a much better result than I would be capable of in any other language. I have used Ada and modern C++ in the past and I consider Rust to be an improvement.
I have seen demonstrations of the language Idris that were like looking into the future. However, the larger community and good tooling make Rust a more practical option.
Bearing in mind that I find Rust to be an annoying language there are things that stand out as better than average:
1. Cargo. The only build and dependency tool that has never annoyed me.
2. A very open and welcoming community.
3. Nom, a very weird parser combinator that is a joy to use when you get used to it.
4. Multithreaded programming. For old school C++ multithreading its incredible to write something and have it work first time and not find any weird threading bugs.
5. Coming back to old code is not the painful experience that it is in other languages.
If you are interested in learning a C++ like language, I would recommend Rust. If you are a C++ programmer, I highly recommend learning Rust.
Any tips for newbie like me on motivation and learning?
What did you do so far to learn? How do you learn other languages, and what other languages do you know?
Usually I learn language by implementing data structures: linked list, tree, graph.
If I can do those then I am pretty confident in doing mostly everything else.
Rust is really the first language that I have trouble with writing simple data structure, I have a bit of issue with scala on covariant and contravariant generics and monads, but they are not bad after I learned it.
For rust everything is awesome until I get to pointers since I have to wrestle with nested smart pointer that makes it insanely hard to manipulate, the rc, refcell nesting is just not very ergonomic (maybe once I learn unsafe it will be easier?).
I like rust paradigm alot since it brings safety and speed, so I was wondering if I am missing anything since I am having some trouble.
> I was wondering if I am missing anything
Nope, I think it's just that your experience led you astray.
If I need a linked list in Rust, I... well, I don't ever use linked lists (you can read the book for why). If I had to, I'd use the one in the stdlib.
If I need a graph in Rust, I use petgraph from crates.io.
Basically, other people are good at writing data structures, so I use their work as much as possible. Only if I'm particularly interested in a specific structure, or I require one that doesn't have some implementation out there yet, do I try to write my own.
Of course, at some point you'll want to learn it, but it's just going to be frustrating until it clicks. The less frustrated you are with the rest of Rust when that happens, the less overall frustration you'll have.
> (maybe once I learn unsafe it will be easier?)
That's very possible. Often, you can take a C implementation and translate it into unsafe Rust. Many data structures use unsafe internally, and present a safe interface.
Good luck on your journey! I hope it all makes sense for you soon.
Doubly-linked list: https://github.com/stjepang/vec-arena/blob/master/examples/l...
Splay tree: https://github.com/stjepang/vec-arena/blob/master/examples/s...
Of course, arenas do have tradeoffs - I'll try to summarize.
Pros:
- Completely safe.
- More ergonomic than dealing with `Rc<RefCell<T>>`.
- Improved cache efficiency of linked data structures.
- Fast node allocation and deallocation.
Cons:
- Any two simultaneous node accesses must be immutable.
- Accessing a node incurs the cost of a bound and liveness check.
- Vector growth can be costly and cause a spike in latency.
- Vector growth moves all nodes in memory.
- Removing a node creates a hole in the vector, possibly wasting memory.
Generally speaking, I think anyone learning Rust and trying to implement a graph data structure should first do it on top of a vector. It's easier than other commonly suggested approaches and it's not a bad one either. In fact, that's how rustc builds some of its data structures, how conrod (a GUI toolkit) represents its widget graph, and how Way Cooler (a window manager) manages window tilings.
That's really going to depend on the size of the list, if it's larger than the cache size then it's not as quick to iterate over as a vector because it's jumping around to random (albeit contiguous) memory.
> Generally speaking, I think anyone learning Rust and trying to implement a graph data structure should first do it on top of a vector.
That really depends on why your learning it. Typically when I'm learning/evaluating a new language I run through pain points like this because it show you the good and the bad.
My advice would be to try and write some 'real world' code instead of programming kattas to get a feel for the language.
it's difficult in rust because recurrent data structures are super hard to reason about in general in terms of borrowing and ownership when AOT compiling and you unfortunately must know this to be efficient at rust; this realization is one of the stages of learning the language.
Nobody hiring for a position that's largely Rust is going to ask you to write linked lists, trees, and graphs. They're going to want you to build something more complex & practical.
Also, if you are a Scala programmer, I highly recommend learning Rust. There are major similarities, and the ownership/borrowing concept is an improvement over Scala's JVM GC issues.
What exactly is annoying about other build systems?
I asked that questions a few times already and I rarely get concrete answers. This time I just started a public document [0]. Contributions welcome!
[0] https://github.com/qznc/annoying-build-systems
CMake is quite popular (and maybe most popular) but it's a complete horror in comparison to other build systems, especially for other languages (like Cargo for Rust).
If you need some specific example: try to add a git-based dependency with a specific branch in CMake.
The unit of dependencies should be other projects or binary libraries.
I have blanked out painful memories of cross-compiling protobufs using CMake but will add a description when I can face them.
Most probably, it will make sense to counterargument or discuss some (or most) of the anecdotes that will end up appearing in that document.
Seems a fitting use case for Arguman! (I'm not related at all)
https://arguman.org
What do you find annoying in it specifically?
not OP, but when people say rust is annoying they are almost always talking about the borrow checker.
coming from c or c++, which allow you to play fast and loose with pointers and types, it can be frustrating to find out that a lot of stuff you would normally do in those languages is not permitted in safe rust code. the flip side is that, once you get the code to compile (in safe rust), you are guaranteed not to invoke undefined behavior. of course, you can just use unsafe blocks if you really need to play around with raw pointers a la C.
my apologies if you already understand rust and my explanation was very obvious to you.
0: https://github.com/srct/sks-rs/
https://github.com/actix/actix-web
The next step is to build an image pipeline and editor around it[2][3]. For that the graphics ecosystem isn't as mature as the equivalent C/C++ ones but the possibilities are also amazing. The expressiveness of the language combined with the great LLVM backend means some things like very clean ways to do SIMD/threading become just a joy to use
If only I had the chance to work on this full time for a year... Help would be very much appreciated!
The kinds of things that become possible and even pleasent once you remove the mental overhead of dealing with the fundamental warts of C/C++ are amazing. After this experience with rust I don't see any reason to ever write C/C++ again.
[1] https://github.com/pedrocr/rawloader
[2] https://github.com/pedrocr/rawloader/tree/master/src/imageop... (to be spun out into its own crate)
[3] https://github.com/pedrocr/chimper
There's also the added bonus that doing cross-platform code with Rust is a breeze. If you aren't depending on any C libraries you basically get it for free. I had a UI framework that was running on 5 different targets that was a joy to work with. I've done that in C/C++ before and it's a massive pain.
I want to write a source code spell checker with performance better than scspell.
I didn't want to take that on as my learning project, so I instead started with a lint tool that is driven by user-defined regexes.
But I wanted to blog about my experience learning Rust. I wanted a blog that was good with code (so I'm moving off of blogspot finally) and easy to deploy (so no Jekyll) and decided on Cobalt which is written in Rust. There are some features lacking, so I've been contributing back (and have become the primary maintainer).
One year later and I've still not gotten around to my regex-based linter or source code spell checker.
What gets me excited about Rust:
- Cargo - Level of confidence that compiled code will work because of both the type system and the borrow checker - Zero cost abstraction (I'm weird) - Error handling that has similar ergonomics to exceptions, easier to reason about, but can work in any environment. Exceptions can't run in places like the Windows kernel, so you end up using what feels like a fork of the language + standard library.
Misc notes on my experience: - Borrow checker has rarely been a problem for me. Yes, sometimes it complains but is usually right and easy to fix - I've never used the `unsafe` escape hatch
The things that frustrate me are nitpicky and I recognize they will go away as the language matures:
- Lack of specialization. e.g. I have a type that I want convertable from/to iterators but the trait for this has a no-op implementation for "convert from self to self", causing ambiguity that fails to compile. - Can't have a struct implement the function-trait - You can't specify that a variable should implement multiple traits (like the primary one and Debug). Instead you need to make a treat that inherits all of the traits you care about. - CI conventions have too much maintenance overhead for an ecosystem that encourages a lot of small packages.
The last one is probably my next step in Yak Shaving once I get cobalt into a "good enough" state for myself.
https://github.com/jcushman/coolsounds
As a python programmer, the part I find exciting/motivational is performance -- I can get my hands dirty writing low-level math code to dump weird sounds out to the speakers 44k times per second, accidentally wandering into interesting glitchy sounds that I don't think you would create using higher-level audio tools, and not feel limited by the speed of the language or reliance on C libraries.
(Not that Rust is necessarily the best or easiest way to mess around with low-level audio generation, but it sure is a fun way to learn.)
• 3rd party dependencies are easy to use (often even on Windows) and usually have no runtime overhead.
• Basic unit testing is built in, so there's low friction to use it (not only for me, but across the entire ecosystem).
• Result type + `?` operator is a nice compromise between clarity and flexibility of return-based error handling and low syntax noise of exceptions.
Targeting game consoles at the moment because of how sensitive those emulators are to latency as well as raw perf, but better a ARM Android emulator is one of the end goals.
[0]: https://github.com/kpcyrd/sniffglue
[1]: https://github.com/kpcyrd/boxxy-rs
My opinions are basically the same as https://users.rust-lang.org/t/best-way-to-install-rust-on-os...
One other note, I heard at least one Homebrew user saying that rustc was compiled from source, and so it takes a really, really long time. I don't know if they've added binary packages, but that'd help.
I used to love Homebrew, but I recently uninstalled it from my machines and went back to MacPorts. This was motivated by the discovery that the lead maintainer of Homebrew is a huge jerk. The tl;dr is he deliberately took offense at inadvertent rudeness in someone's GitHub comment that they had already edited to remove (he recognized this and quoted the original form from the email anyway), then subsequently threatened to ban them from the Homebrew GitHub organization for politely asking that their issue be reopened, and when I pointed this out, he banned me and deleted the relevant comments.
https://www.quora.com/Whats-the-logic-behind-Google-rejectin...
Beside that, I like to install packages from their canonical source. That could mean installing Go from golang.org to MariaDB from mariadb.org. It’s simple to compare sha256 checksums, which I suspect is also possible with Homebrew, I just don’t know how.
This is why I put Hombrew in /opt/homebrew. Despite the freakout warnings about this potentially breaking homebrew packages, I have never had an issue.
Furthermore, we haven't upgraded to LLVM 5 yet, and that's the farthest they're backporting, so we also have to sort through that. We were already at work on the upgrade, just takes a while.
https://i.imgur.com/g3cVtxm.png
https://internals.rust-lang.org/t/6453/12
https://www.reddit.com/r/rust/comments/7nx3cm/
For reference, this is the same person (https://www.reddit.com/r/node/comments/6whs2e/).
Apologies for posting in this thread, but it seems unhealthy to not be able to question community leaders and other discussion has been stifled. Do rust developers have any comments on this?
It'll be interesting to see how the golang lambda implementation is done, as i could see it being a backdoor into supporting any statically linked binary so long as it fits whatever constraints they need.
[0]: http://apex.run/#runtime
[1]: https://github.com/sambaiz/puppeteer-lambda-starter-kit
We support both targets in-tree.
Does bindgen not work here?
Also some of the nicer native libraries are C++, like the newly introduced real time audio, https://github.com/google/oboe
So it is still an higher bar to use Rust than just using what the the NDK/SDK offer out of the box.
So if you happen to have a good device, it just works, if not it can be a big pain yes.
With Rust, currently, there isn't even the option with a good device firmware.