If I want to do systems research that needs a simple and synthesizable RISC-V design, what are some good options? BOOM seems to be pretty complicated and I don't really need the out-of-order execution.
I also want to be able to run it on a cheap FPGA, something like Artix A7.
This is what the OpenHW Foundaiton is for. Providing well verified cores for people who just need a core. They are based on the original Pulp Cores from the ETH Zürich and Unviersity of Bolongia. See:
Claire Wolf's PicoRV32 seems to get a lot of "simple and synthesizable RISC-V design to run on a cheap FPGA" use, although that's more typically for much cheaper FPGA's than an Artix A7, like an iCE40. SeRV is even cheaper and simpler but much slower. Graeme Smecher’s RVC-first "Minimax" is almost as simple as SeRV but not nearly as slow.
I haven't tried any of them, though, so take this with a Himalayan salt lamp.
I've been getting tremendous use out of PicoRV32- it works, it's tiny, and for many use cases ("management plane") you just don't need much speed. I work around its slowness by providing things like relatively large communication buffers in the FPGA. I use it in "execute in place" mode from external SPI-flash (the FPGA's config flash), but with an instruction cache. It can do floating point via emulation which is handy for printf.
I've been meaning to update my toolbox to at least a pipelined processor of some sort (to up the IPC rate to at least 1), but so far just had no strong need. For applications that really need CPU power, I use SoC FPGAs like Zynq.
I personally was intrigued by this by the first HN post months ago. Then I showed my wife the website, to which she said, "This looks like a parody product." If only it's more affordable.
More info from Wikipedia: "While headquartered in Taiwan, the company earns the majority of its revenue from assets in mainland China and is one of the largest employers worldwide."
I'm building an HTTP CRUD app on top of PostgreSQL. I have previously used Go for various CRUD apps. The experience is better except for compile time. My favorites:
1. Much more expressive type system: no more `interface{}`.
2. Algebraic data type with `enum`. Exhaustive check.
3. `serde` crate is lightyears ahead of Go's `json:"wtf"`.
4. Compile-time checks against DB with `sqlx` crate.
5. Logging is a breeze with `tracing::instrument`.
6. Using macros to reduce boilerplate has better UX than Go codegen.
What these give me is more confidence in development/refactoring because the compiler can guide me most of the way.
Low lights:
1. Build time.
2. Async is still clunky. e.g. Try to implement an `actix-web` extractor or middleware.
3. Please just stablize nightly rustfmt features already.
> Do you find the 'stubbornness' of the compiler frustrating at all?
I actually love it. The more work I can offload to compiler the better. One simple example that frustrated me in Go was adding a field to a struct. You add the field the the whole thing still compiles even though the zero-initialized value probably broke your app logic. In Rust if I add a field to a struct, the compiler warns me about all the places that I need to double check.
> Would you mind sharing some of your experiences?
I highly recommend zero2prod book which is well-written, practical, but still teaches the essential principles (https://www.zero2prod.com/). You basically deploy a CRUD app to DigitalOcean from scratch. The best way to ramp up IMHO.
> How do you find the tooling?
Cargo is sweet. rust-analyzer is all I need. I need less extraneous tooling to be effective. For example, in Go I might use a task runner to watch the repo and run tests when I change a file. But in Rust I can just follow the rust-analyzer highlights and manually compile less-frequently.
> Also, I've considered Diesel for ORM, so was wondering if you've been using that too.
I was not happy with GORM (https://gorm.io/index.html) and never had a satisfactory experience with any ORM. I'm a fan of writing plain SQL, even in Go. It's just that with Rust sqlx I can get compile-time checks against the schema. It's not anything new (see Haskell), but it tightens the feedback loop and I have full control of the performance.
Thanks for getting back. I'll take a look at those resources you recommended. Certainly, working with Rust, a lot just 'feels right', it brings together elements I liked from other programming languages like Perl, Erlang, C. Those being: expressiveness, efficiency, a reasonably sane standard library, and functional goodies like immutability and closures.
> You add the field the the whole thing still compiles even though the zero-initialized value probably broke your app logic.
Ah, I found Python notorious for the same reason.
I've found ASP.Net's ORM to be quite good, though this is only with a year's experience, so perhaps I'm missing some cracks that might emerge later.
do you have experience with protobuf in rust? that's the main thing making me think twice about using rust in backend (protobuf doesn't have an one-true rust library)
It's owned not by individuals employees, but by the employees' union ... which is entirely controlled by the communist party and not the employees. It's a very obvious fiction. The generated income may end up in the employees' hands, but the control is in fact with the dictatorship.
