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

Still in love with Rust

dpc.pw

Post reply on HN
Print view View original

171–180 of 186 posts

Re: Still in love with Rust

#171

Post by int_19h »

goldfeld wrote: post #67
int_19h wrote: post #61

Earlier quoted context omitted.

Long lines come most often in conditions of if- and while-blocks, mostly because there's no way to split them over multiple lines that isn't visually hideous. But a condition can be easily split if it is assigned to a variable, and that variable then tested. And naming said variable well can make a comment explaining the condition redundant.

Yes, that's a great example, especially with deep nesting which forced indentation makes worse. But the solution feels like working against the grain, when a language should be working for human readability, not for workarounds to make a scripting language featureful.

One would argue that forcing long conditions to be split up, and intermediate steps named, is rather encouraging readability. ~

Re: Still in love with Rust

#172

Post by andrenth »

Vogtinator wrote: post #82

Am I the only one who really can't stand rust? I was and still am very much in favor of the ideas and concepts, but when I actually tried to use it my opinion on it turned by 180°: - The syntax is awful - No dynamic libraries - Slow compile times - Many checks are too stupid to figure out some valid cases (maybe that improved meanwhile)

I have really tried to like it. Coming from OCaml, it has many of the things I’ve come to expect in a modern language, but with better tooling and more libraries.

I generally do not mind syntax. I like OCaml’s and Erlang’s, for example, which are usually considered ugly, but for some reason I can’t enjoy the look of Rust code. I think all the nested >> and the use of :: are a large part of this.

But the real issue for me was refactoring owned struct fields into borrowed ones. The ‘a lifetimes leak everywhere; you have to add them to the struct field, after its “impls”, and everywhere the struct name appears.

I’ve found that Pony provides the same level of safety in a much more lightweight manner with its capabilities system. Interestingly, if I’m not mistaken, early Rust was somewhat similar to Pony.

Unfortunately Pony doesn’t have the same development resources and thus the ecosystem is somewhat lacking.

Re: Still in love with Rust

#173

Post by duckerude »

kbenson wrote: post #165
int_19h wrote: post #62

Earlier quoted context omitted.

Comprehensions are very easy to format spanned across multiple lines - since they're always enclosed in some kind of brackets, you can split them over multiple lines in a readable fashion: ys = [x + 1 for x in xs if x > 0] or: ys = [ x + 1 for x in xs if x > 0 ]

My biggest issue with list comprehensions is that while it's a useful and fairly readable format for a single list comprehension, either little attention was given to how it would function when taking a comprehension of of comprehension, or they thought the syntax would be so cumbersome people wouldn't do so (ha!). When compared to a set of functional style mapping and filtering functions, it quickly becomes much les…

That's not quite right. The conditionals are executed in order in the innermost loop. For instance:

  >>> [(x,y) for x in range(2) for y in range(2) if print(x, y) is None if print(x, y) is None]
  0 0
  0 0
  0 1
  0 1
  1 0
  1 0
  1 1
  1 1
  [(0, 0), (0, 1), (1, 0), (1, 1)]
Both conditionals have access to x and y.

So the list comprehension is equivalent to this:

  [(x,y) for x in range(10) for y in range(10) if y > 5 and x
And could more clearly be formatted like this:

  [
    (x,y)
    for x in range(10)
      for y in range(10)
        if y > 5
          if x
And would look something like this in a functional style, perhaps:

  toTen.flatMap(x =>
    toTen.filter(x => x5).map(y=>
      [x,y]
    )
  );

Re: Still in love with Rust

#174

Post by eeZah7Ux »

steveklabnik wrote: post #163
eeZah7Ux wrote: post #158

Earlier quoted context omitted.

Yes: security sensitive applications where being able to inspect or fuzz a binary is strongly dependent on size. Also firmware on servers.

Rust has really strong fuzzing support, incidentally https://github.com/rust-fuzz/cargo-fuzz

So does C and other languages.

Re: Still in love with Rust

#175

Post by z3t4 »

knocte wrote: post #68
sifoobar wrote: post #56

Earlier quoted context omitted.

Only as good as Rust allows you to be, which is fine for some until they stagnate or grow out of it; but far from the final answer to anything. I don't get at all how being forced to do anything could ever be a good thing. Smells like cognitive dissonance from here. I'm all for powerful tools that enables me to write better code faster; but being forced, really? That's the best thing about Rust? Ew.

> I don't get at all how being forced to do anything could ever be a good thing If you don't prefer tools that can automatically check if you were a good developer or not, it not only does not scale (to trust the software you build), it's that I wouldn't want to work with you as a teammate.

If you only see the good, it means you are in love.

Re: Still in love with Rust

#176

Post by nimmer »

kungtotte wrote: post #164
vesak wrote: post #119

Earlier quoted context omitted.

And some rough numbers, rustc-1.30.1 vs rustc-1.32.0-2018-11-21, building a hello world with --release... Mac OS: - 1.30.1 before strip: 573K, after strip: 380K - 1.32.0 before strip: 267K, after strip: 178K Ubuntu 18.04 LTS: - 1.30.1 before strip: 3.9M, after strip: 407K - 1.32.0 before strip: 2.3M, after strip: 191K

I'm on Void Linux right now running Nim 0.19 compiling the following code: when isMainModule: echo "Hello World" nim c hello.nim : Before strip: 113k After strip: 92k nim c -d:release hello.nim : Before strip: 79k After strip: 63k nim c -d:release --opt:size hello.nim : Before strip: 46k After strip: 30k Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbol…

The difference gets bigger on large binaries.

Re: Still in love with Rust

#177

Post by kbenson »

duckerude wrote: post #173
kbenson wrote: post #165

Earlier quoted context omitted.

My biggest issue with list comprehensions is that while it's a useful and fairly readable format for a single list comprehension, either little attention was given to how it would function when taking a comprehension of of comprehension, or they thought the syntax would be so cumbersome people wouldn't do so (ha!). When compared to a set of functional style mapping and filtering functions, it quickly becomes much les…

That's not quite right. The conditionals are executed in order in the innermost loop. For instance: >>> [(x,y) for x in range(2) for y in range(2) if print(x, y) is None if print(x, y) is None] 0 0 0 0 0 1 0 1 1 0 1 0 1 1 1 1 [(0, 0), (0, 1), (1, 0), (1, 1)] Both conditionals have access to x and y. So the list comprehension is equivalent to this: [(x,y) for x in range(10) for y in range(10) if y > 5 and x And could…

Ah, thanks for the clarification. Python is not a language I use often (but of course is a language seen often).

I actually see what's going on a bit clearer now, as I looked closer and found that the correct way to write what I was originally trying to express is actually:

   [(x,y) for x in range(10) if x  5]
which could be formatted as:

  [
    (x,y)
    for x in range(10)
      if x  5
  ]
Which is actually much closer to the functional style's flow, and is correctly eliminating iterations earlier in the loop (which is an important consideration).

I was confused because I had seen examples where multiple if clauses where added to the right side, one per loop level (as I showed), and that makes it look like they are operating on the different levels, when in reality they are working on the innermost loop, like you showed.

I'll retract most my complaints then. There's still some question in my mind as to how you would usefully mutate items of the loop and use them in other levels of the loop without recomputing them again, but that might just be my unfamiliarity with the construct.

Re: Still in love with Rust

#178

Post by speedplane »

BerislavLopac wrote: post #131
speedplane wrote: post #64

Earlier quoted context omitted.

Both of the examples you give are far less readable than an equivalent for loop with an if statement. Programmers use comprehensions because there is an understanding that they are more efficient and the compiler/interpreter can better optimize them.

They seem less readable to you because this is not what you're used to. While I agree that complex, one-line comprehensions, possibly with more comprehensions nested inside, can be quite unreadable even for experienced developers, I find that the given examples, with clearly separated expression-loop-condition structure, tend to be quite easy to read and understand, even for junior developers.

I’m quite comfortable with list comprehensions, I’ve been writing them for decades. I like them because they are concise, efficient, more clearly tell the compiler/interpreter their intent.

That said, they are almost always harder to understand than an equivalent for loop with an if statement. A list comprehension by its very nature groups a number of actions into a single expression, it’s harder to break up the parts.

Even an experienced developer who sees them all the time and can understand one in a second, would probably take a half second to understand the equivalent for/if statements.

Re: Still in love with Rust

#179

Post by vesak »

kungtotte wrote: post #164
vesak wrote: post #119

Earlier quoted context omitted.

And some rough numbers, rustc-1.30.1 vs rustc-1.32.0-2018-11-21, building a hello world with --release... Mac OS: - 1.30.1 before strip: 573K, after strip: 380K - 1.32.0 before strip: 267K, after strip: 178K Ubuntu 18.04 LTS: - 1.30.1 before strip: 3.9M, after strip: 407K - 1.32.0 before strip: 2.3M, after strip: 191K

I'm on Void Linux right now running Nim 0.19 compiling the following code: when isMainModule: echo "Hello World" nim c hello.nim : Before strip: 113k After strip: 92k nim c -d:release hello.nim : Before strip: 79k After strip: 63k nim c -d:release --opt:size hello.nim : Before strip: 46k After strip: 30k Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbol…

>But it's great that they're trying to work on this problem.

I don't know how the Rust team thinks, but I believe that minimizing binary sizes is not a very big priority for them. The cost of a gigabyte these days is, ~0.01$ (or less) for local hard drives, $0.4 for NVME and about $0.1 for AWS EBS...

Technically of course it's cool how small Nim binaries are, and it does make certain things feasible which with larger binary sizes might be difficult.

Re: Still in love with Rust

#180

Post by steveklabnik »

vesak wrote: post #179
kungtotte wrote: post #164

Earlier quoted context omitted.

I'm on Void Linux right now running Nim 0.19 compiling the following code: when isMainModule: echo "Hello World" nim c hello.nim : Before strip: 113k After strip: 92k nim c -d:release hello.nim : Before strip: 79k After strip: 63k nim c -d:release --opt:size hello.nim : Before strip: 46k After strip: 30k Kind of a toy example but it illustrates my point. An unstripped version of the Nim program with full debug symbol…

>But it's great that they're trying to work on this problem. I don't know how the Rust team thinks, but I believe that minimizing binary sizes is not a very big priority for them. The cost of a gigabyte these days is, ~0.01$ (or less) for local hard drives, $0.4 for NVME and about $0.1 for AWS EBS... Technically of course it's cool how small Nim binaries are, and it does make certain things feasible which with larger…

We think it's important to be able to control it if you need to, and have done work to make that possible. But we don't worry about the default too much, as you say, we've got a lot of things to worry about, and it's not near the top of the list.

That said, the smallest executable produced is 145 bytes: https://github.com/tormol/tiny-rust-executable

Post reply on HN