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

31–40 of 186 posts

Re: Still in love with Rust

#31

Post by microtonal »

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 to be more popular now and I generally prefer it over error-chain.

Re: Still in love with Rust

#32

Post by projektir »

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 ?)…

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

Or you just don't know any better, as was the case for me.

There are many benefits to Rust that are not related to runtime efficiency.

Re: Still in love with Rust

#33

Post by EugeneOZ »

adrianN wrote: post #30
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?

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.

Re: Still in love with Rust

#34

Post by microtonal »

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?

I have some projects of that size (ballpark), typically using some Boost (but not heavy on meta programming), Qt, and the likes. A fresh non-incremental compile usually takes less than a minute.

I have Rust projects that are many times smaller but take much more time for a non-incremental build. Of course, a large difference is that a fresh Rust build (after a cargo clean) compiles all its dependent crates, whereas many C/C++ libraries are provided pre-compiled by whatever system you are compiling on.

Re: Still in love with Rust

#35

Post by pjmlp »

EugeneOZ wrote: post #12

"No race conditions, leaking resources, dangling pointers, unhandled exceptions, ..., the list goes on." Except of dangling pointers, Rust has everything else from this list. About compilation time issue: it doesn't exist anymore. Current versions do "cargo check" in a few seconds even for big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it because of incremental compilation. F…

It surely does, my Gtkmm demo application I wrote several years for "The C/C++ Users Journal" still compiles faster than the Rust rewrite in Gtk-rs, when doing fresh build or after minor changes.

Lack of binary library support on cargo, not having incremental compilation and linking does hurt.

Re: Still in love with Rust

#36

Post by EugeneOZ »

pjmlp wrote: post #35
EugeneOZ wrote: post #12

"No race conditions, leaking resources, dangling pointers, unhandled exceptions, ..., the list goes on." Except of dangling pointers, Rust has everything else from this list. About compilation time issue: it doesn't exist anymore. Current versions do "cargo check" in a few seconds even for big projects (my biggest project is 45k LoC) and it takes a couple of minutes to compile it because of incremental compilation. F…

It surely does, my Gtkmm demo application I wrote several years for "The C/C++ Users Journal" still compiles faster than the Rust rewrite in Gtk-rs, when doing fresh build or after minor changes. Lack of binary library support on cargo, not having incremental compilation and linking does hurt.

There is incremental compilation. And cargo doesn't recompile libraries every time. Not sure how you don't know it if you really use Rust.

Re: Still in love with Rust

#37

Post by dhuramas »

growtofill wrote: post #18
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…

Doesn't Python have an autoformatting tool like gofmt or Prettier?

Yapf- https://github.com/google/yapf

Re: Still in love with Rust

#38

Post by baq »

growtofill wrote: post #18
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…

Doesn't Python have an autoformatting tool like gofmt or Prettier?

there's autopep8 and a few other tools but none are considered idiomatic.

Re: Still in love with Rust

#39

Post by microtonal »

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…

Rust binaries include jemalloc. However, jemalloc is removed in nightly and by default Rust will use the system allocator:

https://internals.rust-lang.org/t/jemalloc-was-just-removed-...

This should reduce binary sizes quite a bit.

Re: Still in love with Rust

#40

Post by EugeneOZ »

microtonal wrote: post #34
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?

I have some projects of that size (ballpark), typically using some Boost (but not heavy on meta programming), Qt, and the likes. A fresh non-incremental compile usually takes less than a minute. I have Rust projects that are many times smaller but take much more time for a non-incremental build. Of course, a large difference is that a fresh Rust build (after a cargo clean ) compiles all its dependent crates, whereas…

Well, what is the point in this comparison then? I'm not trying to say Rust is the fastest compiler on the planet, but really people don't even try to be objective.
Post reply on HN