Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in 2018: easier to use

jvns.ca

Post reply on HN
Print view View original

211–220 of 305 posts

Re: Rust in 2018: easier to use

#211

Post by xfer »

z0ltan wrote: post #194
xfer wrote: post #169

Earlier quoted context omitted.

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…

Excellent. Thanks for the detailed answer - that really helps. To be honest, I want to use OCaml for writing some toy compilers to begin with, and I'm sure that that'll require only the core language, but I would like to use it for more serious projects after that! I'll start off with "Real world OCaml" and see how it goes!

Here is some resource for you to learn from: http://plzoo.andrej.com/

Re: Rust in 2018: easier to use

#212

Post by twic »

devit wrote: post #137
yen223 wrote: post #12

This 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.

The problem is that it turns out that cyclic garbage collection is essentially useless, except for running existing code that expects a garbage collector to be present (e.g. JavaScript code if you are writing a web browser). Since it's useless, not having it is great since you no longer have to worry about it and the problems it causes like random pauses, sawtooth-shaped and excessive memory usage and inability to us…

If i've understood you properly, i would phrase this slightly differently: because Rust doesn't have GC, it has evolved a lot of language and library features that make it practical to not have GC, and so adding GC doesn't make Rust easier to use.

I think there's a lot to that. I'd be really interested to try it, though, to see how it pans out.

Re: Rust in 2018: easier to use

#213

Post by paulddraper »

banachtarski wrote: post #63
fauigerzigerk wrote: post #61

Earlier quoted context omitted.

>Maybe I should check into a nearby asylum. If you do, make sure it says "believes in micro-services" on the referral ;-)

I just mentally edit "micro-services" to "services" any time I read it hehe.

And "REST" to "HTTP"

Re: Rust in 2018: easier to use

#214

Post by stumpelrielzchn »

Sammi wrote: post #148
stumpelrielzchn wrote: post #144

Surprised no one mentioned the long compile times yet. For me, while I'd really like to try Rust, these are a deal-breaker.

Looks like incremental compilation has been enabled in nightly: https://github.com/rust-lang/cargo/pull/4817

That's a welcome improvement from last time I looked at it.

Does anyone know a ballpack figure for how many LoC/s you can expect on a beefy workstation?

Re: Rust in 2018: easier to use

#215

Post by seertaak »

papaf wrote: post #23
StreamBright wrote: post #11

Earlier quoted context omitted.

Depends what is your goal. Learning a language with decent type system? Learning a language with lower level access to operating system features? I would suggest to learn OCaml because it got really popular in 2017 thanks to Facebook & Bloomberg, it has an amazing type system and you can use it to build CLI tools and web pages (Reason/Bucklescript) with an insanely good tooling (utop, jbuilder, merlin) and the commun…

I used OCaml a few years ago and I thought it was an excellent language. Despite being powerful it was really easy to learn. One thing that put me off in the end was that it didn't support native OS threads (I have the same problem with Racket). Has threading support improved over the years?

I tried it too; after I realized I that every struct had to have unique field names, I gave up. This was too much craziness for me, although I did think the module/functor concepts were very cool.

Re: Rust in 2018: easier to use

#216

Post by yen223 »

fhars wrote: post #150
yen223 wrote: post #22

Earlier 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…

There ist no ReasonML -> Ocaml compilation step in that chain, ReasonML is just another syntax for ocaml.

There is still a necessary syntactical transformation sstep via `refmt`, and that transformation step does occasionally break.

Re: Rust in 2018: easier to use

#217

Post by pimeys »

Thaxll wrote: post #182
chmln wrote: post #158

Earlier quoted context omitted.

> Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity There is nothing in Rust that makes it inherently unfit for APIs or the web. To dismiss the entire language is simply lazy. Having GC also doesn't necessarily make one language superior to another. While http ecosystem is still in active development, if there was really a choice between Rust and JS for e.g. writin…

Except it takes 10x time to write anything backend related. Why would you choose Rust over Java / C# / Go ect ...?

I don't buy this claim. I've written many services with Rust and I'm not slower with it that I am with GC'd languages I also need in my work, such as Clojure, Scala or Python.

Please explain me where is this idea of slow development time coming from? Is it only because people try Rust for two weeks, cannot get the lifetimes and decide the development speed is slow?

Re: Rust in 2018: easier to use

#218

Post by yen223 »

xfer wrote: post #142
yen223 wrote: post #22

Earlier 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 probably got the name wrong, but it's the ability to use a function before it is defined.

In OCaml/ReasonML, you'd have to use the rec keyword and structure your codebase in a particular way to define mutually-recursive functions. It is a small but noticeable papercut, especially since recursion is so common in a functional language.

Re: Rust in 2018: easier to use

#219

Post by TillE »

cesarb wrote: post #172
shmerl wrote: post #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.

Yeah, people with C++ experience have an advantage when learning Rust, since they're used to these concepts, and the Rust compiler enforces things they already know to be careful with (like not mutating a container while there's a live iterator to it). On the other hand, Rust lacks some things C++ has like being generic over values instead of just over types, so for instance implementing a trait for every fixed-size…

As someone who's extremely comfortable with C++, I've tried Rust multiple times but keep bouncing off. Ultimately my problem is just that it doesn't have enough exciting features to lure me away, especially with C++ improving every few years.

Compiler-enforced safety and a built-in package manager are really nice, but it doesn't quite make up for the loss of a lot of handy C++ features.

Re: Rust in 2018: easier to use

#220

Post by lobster_johnson »

bjz_ wrote: post #156
grayrest wrote: post #9

I expect a "it's easier to use" evangelism push around the upcoming epoch release. There are a bunch of mostly completed but still feature flagged changes that should remove a lot of the borrow checker toe stubbing. Getting rustfmt (formatter) and clippy (linter) on stable Rust would ideally be part of the push. Aside from the almost completed features in the pipeline, I only see procedural macros (macros 2.0) and wh…

> [1] I'd really like to see F# Computation Expressions instead of async/await. I know the language experts have said Haskell-like do notation doesn't work in Rust but I'm not sure if the F# tweaks would make it work or not. I'd prefer a systems-y, zero-cost take on algebraic effects, similar to what OCaml is going to get. Could be much more extensible, and open things up to annotating whether functions panic or not,…

Is there a paper or writeup anywhere on what the algebraic effects system coming to OCaml is going to be like? (Does it have a name that can be googled?)
Post reply on HN