Is there something like Helix (Rust) for Python?
Rust-cpython is excellent.
Rust in 2018: easier to use
161–170 of 305 posts
Re: Rust in 2018: easier to use
#162Earlier quoted context omitted.
Oh yes - there will be some explicit type like std::vec::Vec in the error and that all-important '&' gets lost in the verbosity. Definitely necessary to learn to see the needle in that haystack. (Some have proposed simplifying the explicit types if no confusion results, but this could always done by a post-processor. I saved some of my sanity when doing C++ this way)
> and that all-important '&' gets lost in the verbosity Perhaps some console colouring could help as well. I'd really like some type diffs on type mismatch errors (I think Dotty has this?). That could be super handy for quickly diagnosing errors - speaking as a reasonably experienced Rust user here.
Well, we already have a christmas tree colour issue. I think rustc could do better here - check whether types differ by only '&' and put out a hint. That is, by adding/removing &, could the error have been resolved?
Re: Rust in 2018: easier to use
#163> like – maybe Rust is not for people who are already C++ experts and who are happy with C++? I don’t know!
I think Rust is very good for C++ experts. Some key concepts like ownership / RAII and etc. are well known in C++, and they should be easy to understand.
Re: Rust in 2018: easier to use
#164Julia 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
Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs. Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.
Thanks to Rust's great C interoperability, hybrid can be a great approach. I've really been enjoying re-writing sections of node.js applications in Rust. It fits fairly seamlessly and can really broaden the scope of what is possible.
Re: Rust in 2018: easier to use
#165Earlier quoted context omitted.
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…
No builtin utf-8 strings is a good/bad thing is debatable. You don't need to use bucklescript toolchain to write Ocaml, it has a very good package manager, the build-system tooling is getting better, already has great editor support for many years now(merlin). I think the tooling scene is much better than Haskell. Not sure what you mean by "no forward references"?
> Not sure what you mean by "no forward references"?
I'm guessing they are talking about having implicit mutual recursion between items in a module, like Haskell has.
Re: Rust in 2018: easier to use
#166This 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.
That's easy, just change your program so that every value of type T is now a value of type Arc>.
Re: Rust in 2018: easier to use
#167Well 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…
So if a language can't do HTTP and async I/O (with state-of-the-art performance) then we shouldn't consider any other possible application for it? Rust is not Java, you have better languages to build webservers with.
Re: Rust in 2018: easier to use
#168The error messages are indeed _mostly_ marvelous (and there's an ongoing effort to make them even more marvelous). Often working with `rustc` feels like pair programming for introverts. But here's a question: `rustc` often gives _actionable_ advice - how far can can you get just following that advice? You can make `rustc` happy by following suggestions, but may end up puzzled as to the reasons for the changes it sugg…
> You can make `rustc` happy by following suggestions, but may end up puzzled as to the reasons for the changes it suggests.
This is how I felt, but it wasn't bad: I think you start to pick up on the patterns. In other words, learning isn't short-circuited after you've made rustc happy, even though you're still a bit puzzled - you'll carry the experience along with you and continue to learn from it later.
Re: Rust in 2018: easier to use
#169Earlier quoted context omitted.
You don't need Core, the shipped stdlib is good enough for toy projects. There are other stdlibs like containers and janestreet has split their stdlib into smaller pieces. What's your issue with having to use alternate stdlibs? Regarding books, Real World Ocaml is very well written, although some examples might need tweaking.
Thanks for the reply! Mostly wondering how people ship stuff if there are different variants of std libs? Say you write your code entirely using one std lib and then try to share it (the code that is) with somebody who uses a different std lib, then the onus of learning the new std lib is entirely on him, right? How does that work for teams then? I know that Jane Street is a big user and so they have considerable inf…
The standard stdlib has all useful data structures, mostly the differences are in providing more convenient functions and monadic interfaces that you might have to write yourself, if you didn't use the alternate libraries. There is nothing to "learn" about using another stdlib since most signatures are the same. And they can use a different stdlib if they want.
The migration from standard stdlib to alternate ones is fairly trivial(some signatures might differ but typed language means the compiler will catch them for you), so you can start using the stdlib and if you feel like writing some trivial things that should be in the stdlib or you need some advanced data structures you can use the alternate ones.
Also you need `lwt`(most people prefer this)/`async` library for writing concurrent programs like a webserver. `Cohttp` is a good library for doing http based client/servers. I strongly recommend `Real world ocaml` and the reference manual is excellent at looking up some new type-level features. Also reading well-known libraries code is an excellent way to learn a language.
Re: Rust in 2018: easier to use
#170Earlier quoted context omitted.
Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs. Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.
Writing GUI with rust is totally possible: http://gtk-rs.org/
gtk-rs needs a macro package to parse a HTML or a XML snippet and generate GUI, with embedded rust code in appropriate place. Look at Yew for example: https://users.rust-lang.org/t/yew-a-framework-for-client-sid... .