Rust has been the most surprisingly fun thing I learned this year. I was shocked at how quickly I was productive (even while still having no idea what I was doing). It really is astonishingly like using a very high level language, with a few weird quirks.

I'm really looking forward to building something bigger with it in 2019. I don't know what it'll be yet, but it was such a satisfying experience working with a low-level language (which I haven't done in 15 years, or so), and having it be really pleasant. I think it's impossible to overstate how important having a good way to easily install libraries/modules/whatever is, and Cargo gets it right in ways that few systems languages ever have (that I'm aware of, anyway).

>and Cargo gets it right in ways that few systems languages ever have (that I'm aware of, anyway).

Can you elaborate on that? ("gets it right")

> Async/await is releasing next year, hopefully in Q1. This will simplify future asyncio development and make it much more legible

I started using some of the async/await syntax using https://github.com/alexcrichton/futures-await about 6 months ago. I had much problems with understanding the compiler errors because async functions were created using macros, and the compiler was not going a very good job at showing the errors (Or maybe I was missing some information about how to do this).

However, if you are willing to work with nightly Rust, you will be able to start using Futures 0.3 with async and await!. Using the async and await! syntax gave me such a huge boost to productivity that I am willing to walk on the edge and use the alpha version with nightly Rust (futures-preview = "0.3.0-alpha.10").

The integration with things like clocks and networking (The things you get from Tokio) are not yet perfect, but there is a compatibility layer you can use that works reasonably well. There is also the Romio project (https://github.com/withoutboats/romio) as an attempt to make a minimal Tokio that works with the new Futures syntax. I recently saw this post by jsdw, it might help you get started: https://jsdw.me/posts/rust-asyncawait-preview/

I already wrote large amounts of code using Futures 0.3 with async/await for the offst project (https://github.com/freedomlayer/offst). A very simple example you can start with is the Timer module, providing time ticks over channels to other parts of the system. It's code is pretty self contained and shows what could be achieved with the new async/await syntax. You can find it here: https://github.com/freedomlayer/offst/blob/master/components...

The productivity gains from async/await are substantial. The community cannot release this to stable quickly enough!

Rust has been on my radar. Work has consumed my life this year, so I didn't spend a heck of a lot of time on it. Looks really cool though! I've read a lot about how the memory management works and have been trying to figure out how the API of a "rustic" GUI toolkit should look.

Mostly looking at react and redux for inspiration, as they try to champion unidirectional data flow. In theory, would let me avoid std::RefCell hell that I read about in the forums.

I've been using Rust professionally for web development almost four years now and on January I'll start a new job which allows me to continue with the language. It's been such a nice ecosystem to work with and I'm really happy it's getting more popular in the industry.

How do you feel about the productivity for web development in Rust?

My priorities are unique to my situation, so a responsible answer to your question is "it depends on what you're trying to do".

I am trying to create a scalable platform. Without having best practices to learn from, I had to discover what that required while trying to make the most of Rust. The discovery process involves many iterations of trying approaches out until a decent one emerges.

On the other hand, once I laid the tracks down, I found my usual hindrances to productivity: business logic and data modeling.

I am much more productive with Rust and raw SQL parameter binding than Python with SQLAlchemy query builder. Evidently, the costs associated with using an orm are greater than the benefits for someone who is fluent in SQL. Learning a dsl and then fighting the dsl and then asking for help repeatedly, just to accomplish the same task and no more, is a really bad use of time.

Do you have an example of where you’ve found writing raw SQL queries was more efficient in both time spent programming and time spent executing the query?

I built an API in Python and SQLALchemy. Originally, it was built in Flask and Flask-SQLALchemy, but I eventually decided to migrate it to Falcon + SQLService and saw greatly improved response times from my API (hosted on AWS Lambda). Am I likely to see as significant improvements from a switch to Rust + raw SQL queries?

I am kindly looking for a reason to learn Rust. :) With the recent improvements to AWS Lambda, a Rust run-time is a reality and I am open to migrating the project once again for any additional speed improvements.

> Evidently, the costs associated with using an orm are greater than the benefits for someone who is fluent in SQL.

I largely agree although I've recently discovered the beauty of re-usable, type-checked sub-clauses by composing C# lambda expressions for Entity Framework using e.g., AndAlso():

https://stackoverflow.com/a/13968172

how are you building dynamic queries without a query builder? (for example creating a complex where condition based on given GET parameters)

You could answer this question for your Python work if you refactor one of your dynamic queries to SQL Alchemy's query binding facility. You're working with a query string so you manipulate the string using whatever tools are available in the language. Lots of possible approaches in Python. Same for Rust.

Have you tried writing a doubly linked list?

https://rcoh.me/posts/rust-linked-list-basically-impossible/

In my experience, there are plenty of things that are much harder in Rust than other languages. Those tend to fall on the "how you do things", instead of the "what you want to achieve" side of work, so often it's just a matter of stopping, asking yourself "can't the language help me somehow instead of making my life harder?", and adapting your ways.

A few times you are not so lucky and have an actual need that Rust makes harder. Those exist, like in any other language, and I'd be happy if I knew how to avoid them.

1. Do you often try to implement data structures like this? In my practice, arrays are almost always better. 2. Beside that, you may argue that I use "Don't have therefore is not required" argument. But it contained partial truth: if you fight Rust program model then you have to do some extra steps to achieve it. Rust borrowing model considers one owner who can share its data among consumers. And this is damn common situation. I written a whole telegram bot with futures, using Arc container only once, to share my http client across the threads.

If you fight GC in Java then you have same troubles: all this stuff like weak pointers, byte array storages, reflection, etc, etc... If you are trying to write imperatively in haskell... And so on. If you fight language ideas, then your code becomes more complicated. The answer here is that you shouldn't have to do it often.

To answer your first question:

> 1. Do you often try to implement data structures like this?

Any self-referential data-structure has this problem. So I guess my answer would be "yes".

I was doing adventofcode this year using (and learning) Rust and had to write a doubly linked list. Impossible is obviously an exaggeration but I admit it is painful to wrap my head around it at the beginning. I had to google a reference implementation and understanding why it needs to be done that way is also not straightforward. It is definitely not the best thing to try out Rust with, but to me it is the best to force myself to really think hard and grasp the idea of ownership. Once I figured it out the complex becomes reasonable and I started to appreciate the safety aspect of Rust.

I also did the same puzzle with Go, it was such a breeze, it is as easy as to implement a doubly linked list in python/ruby/$yourfavoritescriptlanguage. But I start to dig Rust as it makes me think more and it feels like an eye opening experience.