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

241–250 of 305 posts

Re: Rust in 2018: easier to use

#241

Post by marmaduke »

Nelkins wrote: post #192
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.

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 language curve.

Re: Rust in 2018: easier to use

#242

Post by papaf »

masoodusmani wrote: post #171
papaf wrote: post #23

Earlier quoted context omitted.

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?

Are you sure Racket doesn't support native threads? I thought it had something called "places" for that.

I did not know about places, but after reading about them [1], I can see that although they are implemented on top of OS threads, it is not a conventional threading model.

For instance there is an instance of the Racket VM per place and this makes them heavier than it would be in a standard system programming language language such as C, C++ or Rust.

I am not saying it is better or worse -- just different.

[1] https://www.cs.utah.edu/plt/publications/dls11-tsffd.pdf

Re: Rust in 2018: easier to use

#243

Post by laumars »

coldtea wrote: post #201
laumars wrote: post #190

Earlier quoted context omitted.

That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute (and the community did want to contribute when it looked like development had stalled). Where as limn is open source so if it does prove worthwhile but development stalls it would be trivially easy for any number of other developers fork the git repo and carry on the work.

> That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute It is fair, as whether it's possible for the community to contribute is a moot point if the community wont contribute. Heck, GTK+, which is used by millions, had just one person working on it full time a few years ago (not sure if changed since), and lamenting how there's no community help in the proje…

> It is fair, as whether it's possible for the community to contribute is a moot point if the community wont contribute.

Well as I had already said in my previous post, the community did want to contribute to Sublime Text but couldn't. Hence why I posted my rebuttal stating the original examples weren't really fair.

Your revised example is far more apt however in a roundabout way it just reinforces my original point. Since, by your own admission, any Rust UI lib is unlikely to see many dedicated contributors; it would be daft to criticize limn for a trait that you have just acknowledged would be typical for any Rust UI library.

To put things another way: if the project had stalled for months at a time then I could understand people's skepticism trusting the maintainer. However a brief period without commits during the holiday season seams more than reasonable for an active project. Particularly when you even comment afterwards that any similar project isn't likely to see more active development anyway. So why single this one out as being less trustworthy? It feels very much like your applying double standards here.

Re: Rust in 2018: easier to use

#244

Post by shaklee3 »

pjmlp wrote: post #104
K0nserv wrote: post #72

Earlier quoted context omitted.

Golang is a language designed for offshoring? It was invented at one of the largest engineering orgs to be used in house

In the words of Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to…

He really said they're not capable?

Re: Rust in 2018: easier to use

#245

Post by pygy_ »

Shoothe wrote: post #64
Manishearth wrote: post #37

Earlier quoted context omitted.

The closing keynote at RustConf is generally someone who is new to Rust or has never used Rust but can bring in an interesting perspective. Last year we had Joe Duffy, who I don't think has done much Rust aside from perhaps basic experimentation, but has a lot of relevant experience from running the Midori (Microsoft's safe systems language) project. (also, the author isn't a "guy")

It's interesting because when I read about how Rust can rewrite iterators code into more performant direct loops I thought about Joe's blog posts that mentioned the same efforts for .NET. Also Span . It seems .NET will have similar abstractions like Rust (of course not all can be migrated).

LuaJIT does the same, down to an absurd level.

From the luafun library readme (which uses iterators under the hood):

https://github.com/luafun/luafun

————

> Let's see an example:

    > -- Functional style
    > require "fun" ()
    > -- calculate sum(x for x^2 in 1..n)
    > n = 100
    > print(reduce(operator.add, 0, map(function(x) return x^2 end, range(n))))
    328350

    > -- Object-oriented style
    > local fun = require "fun"
    > -- calculate sum(x for x^2 in 1..n)
    > print(fun.range(n):map(function(x) return x^2 end):reduce(operator.add, 0))
    328350
> Lua Fun takes full advantage of the innovative tracing JIT compiler to achieve transcendental performance on nested functional expressions. Functional compositions and high-order functions can be translated into efficient machine code. Can you believe it? Just try to run the example above with `luajit -jdump` and see what happens:

    -- skip some initilization code --
    ->LOOP:
    0bcaffd0  movaps xmm5, xmm7
    0bcaffd3  movaps xmm7, xmm1
    0bcaffd6  addsd xmm7, xmm5
    0bcaffda  ucomisd xmm7, xmm0
    0bcaffde  jnb 0x0bca0024        ->5
    0bcaffe4  movaps xmm5, xmm7
    0bcaffe7  mulsd xmm5, xmm5
    0bcaffeb  addsd xmm6, xmm5
    0bcaffef  jmp 0x0bcaffd0        ->LOOP
    ---- TRACE 1 stop -> loop
> The functional chain above was translated by LuaJIT to (!) one machine loop containing just 10 CPU assembly instructions without CALL.

Re: Rust in 2018: easier to use

#246

Post by quotemstr »

steveklabnik wrote: post #225
quotemstr wrote: post #180

Earlier quoted context omitted.

For low level code, do you really want to abort on panic? Rust error handling is easily my least favorite part of the language, combining the disadvantages of exceptions and return codes.

Many do, yes. Panics are non-recoverable errors, and aborting produces leaner code, which is important on embedded.

Panics are recoverable though

Re: Rust in 2018: easier to use

#247

Post by papaf »

StreamBright wrote: post #122
papaf wrote: post #23

Earlier quoted context omitted.

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 am not sure what exactly you are missing, isn't this a native OS thread either POSIX or Win32? http://caml.inria.fr/pub/docs/manual-ocaml/libref/Thread.htm...

The documentation that you linked to is not describing native OS threads. I am sure that the OCaml implementation is good for a lot of applications.

However, because I am used to writing multithreaded code using pthread or std::thread, I find the standard OCaml model uncomfortable and limiting. Its mostly a matter of personal taste but this is the reason I stopped using OCaml.

Re: Rust in 2018: easier to use

#248

Post by laumars »

rapsey wrote: post #198
laumars wrote: post #190

Earlier quoted context omitted.

That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute (and the community did want to contribute when it looked like development had stalled). Where as limn is open source so if it does prove worthwhile but development stalls it would be trivially easy for any number of other developers fork the git repo and carry on the work.

> it would be trivially easy for any number of other developers fork the git repo and carry on the work. Expecting that is wishful thinking. The fact of the matter is making something like that is an insane amount of tedious work and 99% of the time it is started up by people playing around with the concepts and abandoned once the initial fun problems are tackled. Something I am sure will happen with limn.

I agree however that could equally happen with any similar Rust UI library that isn't backed by a corporate entity. And seeming as there isn't any corporate backed UI libraries for Rust (at least that I'm aware of), you're literally no worse off with limn than you are with anything else.

Re: Rust in 2018: easier to use

#249

Post by foota »

mmirate wrote: post #166
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.

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.

Re: Rust in 2018: easier to use

#250

Post by foldr »

pjmlp wrote: post #240
foldr wrote: post #229

Earlier quoted context omitted.

Your responses to K0nserv and singhrac suggested that you were defending the claim that golang was "designed for" outsourcing. If you're making the weaker claim that Go's design "can" have the effect of triggering outsourcing, then that's speculative and consequently rather difficult to refute. But you haven't provided a single piece of evidence that this has actually occurred, so far as I can see.

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.
Post reply on HN