I'm learning Rust by writing graphical / glitch art software. Not too much exposure to 'systems' programming although color spaces are more complex than you'd think. Performance is important when you shuffle thousands of pixels around, and some of it is easy to parallelize.
Rust in 2018: easier to use
251–260 of 305 posts
Re: Rust in 2018: easier to use
#252This is going to sound weird, but I would like to see a garbage-collected Rust. Take away the borrow checker, and you still have a modern language with UTF-8 support out-of-the-box, algebraic data types, pattern matching, a focus on performance, and great tooling (cargo + rustup = OCaml almost fits the bill (Rust is inspired by OCaml after all), but the tooling around it is lacking to put it mildly.
You should know that rust always intended to have owned/shared references, Rc reference counting, and Gc garbage collected pointers. It turns out that LLVM made precise garbage collection a hard thing to add on to the language inside of it's standard library. I believe recent changes to LLVM make this easier and it's still a planned feature in the future.
It still doesn't really meet your idea you probably have in your head. When people can choose between different types of pointers, people will choose rust's normal lightweight lifetime references 99% of the time. Gc will probably only be used in those rare cases where an object has no clear owner. They figured this out in the early days of rust.
Re: Rust in 2018: easier to use
#253Anyone has suggestions on learning rust for a python programmer who is also not strong on systems concepts?
I'm a Python programmer with no prior experience to systems outside university.
Browse Python projects on github and find some that strike your fancy. Especially those which may run slow, like puzzle solvers, image manipulation apps, etc. Bonus points if they have few external dependencies. Rewrite them in Rust.
Re: Rust in 2018: easier to use
#254Earlier quoted context omitted.
F# sounds like it fits the bill. ADT, pattern matching, performant, great tooling (multiple amazing IDEs, a REPL, etc.), and a huge ecosystem of software packages to use with it (all of .NET). It's my favorite general purpose programming language (can be used for frontend programming, server, mobile apps, etc.).
I wanted to get into f# but had a hard time with tooling, cross platform. For example, I'd see a great library and the instructions assume VS while I'm on Linux. There are a variety of build tools and package managers. As Python dev since 10 years I can't point fingers -- Python is probably worse though I've memorized the idiosyncrasies -- but I couldn't justify my way up the tooling learning curve in addition to the…
(I work on F# at MS)
Do you remember the library? The landscape has changed dramatically in the past ~6 months with .NET Core 2.0 support. For example, I can use Fable[0] and Giraffe[1] with the .NET CLI[2] to build full-stack F# apps on my machine which runs .NET Core. The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support, but we're quite close to finishing that.
[0] http://fable.io
Re: Rust in 2018: easier to use
#255Earlier quoted context omitted.
> Ocaml almost fits the bill, but the tooling around it is lacking to put it mildly. I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.
I've built several toy projects with ReasonML. I found the overall experience fairly positive, so please take this comment kindly. I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things. I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward reference…
There's a similar chain for F# running with Fable:
F# code (with a catch) --> F# AST --> Bable AST --> JS
The big thing here is that the F# code you write has slightly different semantics than "normal" F#. That's because the runtime environment is different, and so you can't escape that. Rather than attemp to gloss this over, the Fable creators are pretty explicit about this, including documenting each of the (small) differences. The result is pretty good. Abstractions don't seem too leaky from my vantage point.
Re: Rust in 2018: easier to use
#256Earlier quoted context omitted.
And many others handle this externally, including some functional languages, in case you want a list, I can provide it.
I'm interested in functional languages with a C/C++-like distinction between values and pointers!
Common Lisp (make-array, dynamic-extent, make-pointer, incf-pointer, ...)
F# (nativeptr, struct, nativeint, fixed, byref)
ATS (ptr_succ, ptr_prev, lam@, addr@, ...)
Re: Rust in 2018: easier to use
#257Earlier quoted context omitted.
I was making the claim that can be a side effect of its design and the way the community is against common features in modern languages, deemed too complex. Lets see how it looks a few years from now, given that it is becoming a mainstream language thanks to Docker and K8s adoption.
Many of those features (e.g. generics) are in Java and/or C#, which are nonetheless widely outsourced.
True, however Go is like a Java or C# 1.0, they did not start as they look today.
So Go is in the right track to follow their path.
Re: Rust in 2018: easier to use
#258Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018. http://www.arewewebyet.org Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position
I'm actually writing a lambda function in Rust at work right now!
Whilst I could do it in Python, it was straightforward enough to be a good first thing to try with Rust and it's actually been easier to write than I anticipated.
Plus the performance benefits will be nice.
Re: Rust in 2018: easier to use
#259Earlier quoted context omitted.
That's easy, just change your program so that every value of type T is now a value of type Arc >.
Reference counting does not handle cycles.
Use Arc::downgrade() to get a Weak> as needed. Weak is like Arc but does not affect the value's reference count.
Re: Rust in 2018: easier to use
#260Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…
Good client library https://github.com/seanmonstar/reqwest Could be used as async or as sync. Http/2 client and server https://github.com/carllerche/h2 Web framework https://github.com/actix/actix-web All of them has good quality and performance
Commenting to vouch for Reqwest.
Using it at the moment and it's been great to use: documentation was good, API was straightforward, everything so far has worked practically first time.