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

61–70 of 186 posts

Re: Still in love with Rust

#61

Post by int_19h »

goldfeld wrote: post #16
vaylian wrote: post #10

> Rust will force you to be a good programmer, > [if] you like it or not. This is probably the best in-a-nutshell statement that describes what a good programming language is for me. I had similar moments in the past. Before Python I cared about indention to some degree. But once I got used to the way Python forces you to indent your code, I came to the realization that this is pretty much the way I should format my…

Python formatting is egregious though, with hopelessly long lines and no sign of where to break them up, or at the most weird places. Yes I'm one of those persons who adheres to the terminal 80 column rule, it's neat for splitting and cascades into many benefits. Python often looks like unkempt code to me, like the developer has no care for how it looks or layouts (which isn't true, it's Python's fault.) The forced i…

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.

Re: Still in love with Rust

#62

Post by int_19h »

goldfeld wrote: post #59
freyir wrote: post #45

Earlier quoted context omitted.

> Python formatting is egregious though, with hopelessly long lines This is the result of writing hopelessly long lines of code. Python doesn't force you to write long lines. I've done it myself, many times, but gradually made efforts to avoid this. I'll move deeply indented code into a new function or split up a long expression with a temporary variable. If I run into a particularly hard-to-format portion of code, i…

But list/dict comprehension puts the programmer in bad shoes, because anything interesting/powerful done with it gets dangerously long. This and other features where non-trivial statements or calls are written seem poorly thought-out, from a formatting perspective (nevermind 120 columns being the style goal for the language and common IDEs, already longish for term vim and Emacs.) Adding to it for the other commenter…

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
   ]

Re: Still in love with Rust

#63

Post by EugeneOZ »

setr wrote: post #58
EugeneOZ wrote: post #27

Earlier quoted context omitted.

Theoretically they are different, in practice they are the same (it's just more difficult to handle panicking - sometimes you can't use catch_unwind because of it's trait limitations). About race conditions: https://doc.rust-lang.org/nomicon/races.html

I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result in rust)…

I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)

Re: Still in love with Rust

#64

Post by speedplane »

int_19h wrote: post #62
goldfeld wrote: post #59

Earlier quoted context omitted.

But list/dict comprehension puts the programmer in bad shoes, because anything interesting/powerful done with it gets dangerously long. This and other features where non-trivial statements or calls are written seem poorly thought-out, from a formatting perspective (nevermind 120 columns being the style goal for the language and common IDEs, already longish for term vim and Emacs.) Adding to it for the other commenter…

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 ]

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.

Re: Still in love with Rust

#65

Post by speedplane »

EugeneOZ wrote: post #63
setr wrote: post #58

Earlier quoted context omitted.

I feel like its quite difficult to call them the same in practice, when they serve very different roles: errors that are likely to be recoverable are not panics! in a sane rust api, whereas they very much are exceptions in sane C++. You recover from either in similar fashion, but panics! are intended to serve a much different role than exceptions (the common usage of exceptions in C++ being covered by Result in rust)…

I hate when people use exceptions for regular errors, it triggers me hard. Please let's don't start this topic :)

You started it.... exceptions are mostly annoying because they are so verbose. Writing try... catch... is a whole lot longer than "if func() == null".

Re: Still in love with Rust

#66

Post by simias »

hbbio wrote: post #6

Rust is a wonderful language, but I still have the impression that it is not stable as of 2018. All the toys I've made to play with it during the last years went deprecated quickly, especially if you rely on the ecosystem of packages (web server, database, ...). In addition, there was this thread: https://internals.rust-lang.org/t/concerned-about-rust-2018-... All in all, Rust will be great when stable (including the…

What do you mean by deprecated? Unsupported dependencies? All the code I've written post-1.0 still compiles correctly (although a lot of it could use an update to use new language capabilities).

I even have a bit of Rust in production at work and I haven't encountered any maintenance issue so far.

Now the ecosystem itself can move pretty fast depending on the dependencies you use, that's true, but that's a different issue. You're never forced to update if you don't want to, you code keeps compiling with newer Rust releases. Compared to most languages I've experienced with, Rust has been very stable post-1.0. And they seem to take that issue very seriously.

The thread you linked might have some truth in it but it seems like the main point is "look, you've had a .2 patch release!" That's not a good thing of course but unless you happened to jump on that new functionality as soon as it got released the impact is rather minor and bugs happen.

Re: Still in love with Rust

#67

Post by goldfeld »

int_19h wrote: post #61
goldfeld wrote: post #16

Earlier quoted context omitted.

Python formatting is egregious though, with hopelessly long lines and no sign of where to break them up, or at the most weird places. Yes I'm one of those persons who adheres to the terminal 80 column rule, it's neat for splitting and cascades into many benefits. Python often looks like unkempt code to me, like the developer has no care for how it looks or layouts (which isn't true, it's Python's fault.) The forced i…

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.

Re: Still in love with Rust

#68

Post by knocte »

sifoobar wrote: post #56
vaylian wrote: post #10

> Rust will force you to be a good programmer, > [if] you like it or not. This is probably the best in-a-nutshell statement that describes what a good programming language is for me. I had similar moments in the past. Before Python I cared about indention to some degree. But once I got used to the way Python forces you to indent your code, I came to the realization that this is pretty much the way I should format my…

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.

Re: Still in love with Rust

#69

Post by flohofwoe »

EugeneOZ wrote: post #28
jerrre wrote: post #22

Earlier quoted context omitted.

>big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it I don't think 45k LoC could be considered big, and I _do_ think a couple minutes compile time is a problem. I say that as a C++ programmer, a full recompile will easily get me out of the zone

Out of curiosity, not to argue: how much time it takes in C++ to compile 45k LoC?

It depends heavily on how you're counting lines of code and what C++ features you're using.

If you include a couple of C++ stdlib headers you're already well past 45kloc per compilation unit (for instance, including pulls in about 25kloc of code). Such a file usually compiles in a second or so, but the problem in C++ projects is that each source file pulls in the same headers over and over, which explodes the line count the compiler has to crunch through (I bet that in most bigger C++ projects, the actual project code is less than 5% of what the compiler actually needs to compile).

C is much more predictable, a 45kloc C project should compile and link in under a second for a full rebuild without optimizations, and at most 2..3 seconds with optimizations. The link-step is usually the critical part, since that's hard to speed up by throwing more hardware resources at it.

Re: Still in love with Rust

#70

Post by bugmen0t »

arendtio wrote: post #54

> Barriers to entry So far I had two faltering attempts to learn Rust but somehow I didn't find good enough material to get me hooked. I am looking for something similar to the Tour of Go[1], where you can interactively try the language by solving minimal tasks. Does someone know of such material? [1]: https://tour.golang.org

https://github.com/carols10cents/rustlings
Post reply on HN