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

51–60 of 186 posts

Re: Still in love with Rust

#51

Post by skrimp »

EugeneOZ wrote: post #33
adrianN wrote: post #30

Earlier quoted context omitted.

That really heavily depends on the kind of code. Template metaprogramming slows down the compiler a lot.

So sometimes it takes couple of seconds, sometimes couple of hours? Maybe there's some approximate range.

C++ compile times heavily depend on the code that is being compiled and the build system that is compiling it. Code that doesn't touch STL or boost or do much metaprogramming of its own is going to compile extremely fast (especially when compiled in parallel). Code that pulls in half of boost isn't going to compile so quick without tweaking the build settings. Due to how variable compilation times are, I don't think the range you provided is that unreasonable. Build time is something that changes on a project to project basis.

Re: Still in love with Rust

#52

Post by EugeneOZ »

jerrre wrote: post #43
EugeneOZ wrote: post #28

Earlier quoted context omitted.

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

Like the others say: depends. But wasn’t saying C++ compiles faster, just that I know from experience that anything over a couple of seconds can ruin your flow.

Well, if you can't even call a range (seconds, minutes, hours) then I can say that Rust is more predictable at least :)

Couple of seconds for 45k lines - I think you are too demanding :) But if C++ can compile it in couple of seconds - great, good competition for Rust :)

Re: Still in love with Rust

#53

Post by steveklabnik »

leni536 wrote: post #25

I tried Rust a few weeks ago. Is my understanding correct that Rust doesn't have the equivalents to the following C++ features yet? - non-type and template template parameters - constexpr functions I understand that Rust macros can replace them some of the time, and they are much better then the C preprocessor, but that's quite a low bar to meet. Last time I checked non-type template parameters (called "const generic…

The equivalent of "constexpr functions" has a design, and is usable in nightly.

The equivalent of "non-type template parameters" has a design, but is not yet implemented. It's being worked on.

There's no direct design for the equivalent of "template template parameters", but a similar feature has a design, but is not yet implemented. It's being worked on.

Re: Still in love with Rust

#54

Post by arendtio »

> 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

Re: Still in love with Rust

#55

Post by steveklabnik »

jerrre wrote: post #24

> Let's face it – typically developers are familiar with OOP, garbage collected, dynamic programming languages. I think most of these programmers, and their project are not the target of Rust? If you're writing Java/C# or higher level languages, you already made the choice to sacrifice some computing efficiency for programming efficiency. I always thought Rust was more destined to convert C and C++ (and D/Swift/Go ?)…

We have three major audiences:

* "systems programmers", aka the C and C++ folk

* "functional programmers", largely Haskell folk

* "scripting programmers", mostly Ruby/Python/JavaScript folk

Each has gotten something out of Rust, and also brought some things to Rust.

Re: Still in love with Rust

#56

Post by sifoobar »

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.

Re: Still in love with Rust

#57

Post by rqs »

microtonal wrote: post #31
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…

I think it depends a bit on which in part of the ecosystem you work. I do not do web applications at all, but use Rust for machine learning. Things like ndarray , petgraph , and the Tensorflow bindings have been very stable for me. The only large change that I had to make over the last year due to ecosystem changes was going from error-chain to failure . Of course, this was not strictly necessary, but failure seems t…

> depends a bit on which in part of the ecosystem you work

This is also my experience. The feeling towards Rust is highly depends on the dependency of choice.

Rust itself is mostly very stable though. I've implemented few pure algorithms in Rust a little over two years ago, and it still compile and runs today without having to change a single letter.

Wish one day I can say the same thing to my other Rust projects :)

Re: Still in love with Rust

#58

Post by setr »

EugeneOZ wrote: post #27
Laaas wrote: post #21

Earlier quoted context omitted.

It is indeed true that you can unintentionally leak resources, but it is still much harder. Also, what do you mean that it has unhandled exceptions and race conditions? Rust doesn't even have exceptions (although there are panics, which is not the same thing), and race conditions are statically prevented in safe code due to how a mutable reference works.

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

Re: Still in love with Rust

#59

Post by goldfeld »

freyir wrote: post #45
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…

> 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 (vaylian) who asked for example code, pretty much any codebase I've been delving into will have at least one ugly line per non-trivial class implemented (some undergo TWO virtual linebreaks!! Maybe OK for mouse-clickers but vimmers recoil and shriek.) It just doesn't play nice. I won't go into how I dislike the class system which feels bolted-on (to a script language) too because then that'd be a bit unfair and off-topic.

Re: Still in love with Rust

#60

Post by weavie »

kungtotte wrote: post #23

Another point against Rust is binary size. If you write the Fibonacci generator in one of the first chapters of the Rust book it will create a 4MB binary. Even stripped it's over 400KB. If you write the same code in Nim it compiles down to 112KB with debug symbols, unstripped. Statically linked against libc (still with debug symbols) it's only 850KB. 850KB statically linked versus ~450KB dynamically linked and stripp…

How far does this scale? What are the binary sizes of a 100k loc app in Rust vs Nim?
Post reply on HN