Earlier quoted context omitted.
Out of curiosity, not to argue: how much time it takes in C++ to compile 45k LoC?
~100k loc takes 40 secs with `make -j 4` on my laptop.
Finally some numbers, thanks. Yes, Rust compilation is slower.
Still in love with Rust
161–170 of 186 posts
Re: Still in love with Rust
#162Earlier quoted context omitted.
So all programming languages at a higher level than ASM are horrible to you? They don't allow you to write everything that pure ASM does. Even C enforces structured programming.
It's all black or white, right. Someone says something less than flattering about your latest ideology and the gloves come off. Consider not identifying so hard with your tools, for all our sake. There are very few rules in C; same in Forth, Common Lisp and Perl among others; they provide tools, not religions. Python was always borderline. These days it's like they're in some kind of competition to stuff as many rule…
> Someone says something less than flattering about your latest ideology and the gloves come off.
Or, for an alternative view, someone makes an extreme statement like "I don't get at all how being forced to do anything could ever be a good thing" and when called on to explain it in common contexts you note how you are harshly being attacked because of someone's ideology.
> There are very few rules in C
There are tons of rules in C. You have to type your variables. You often have to cast between variables to change type. You've likely just internalized them and accepted them as common so you don't think of them as cumbersome.
> same in Forth, Common Lisp and Perl among others
Even Perl is opinionated in spots. Have you ever wondered why postconditionals only work on statements, and not blocks, while regular conditionals only work on blocks, and not statements? e.g.
do_something() if $var_as_bool; # Valid
{ do_something(); } if $var_as_bool; # Invalid
if ( $var_as_bool ) { do_something(); } # Valid
if ( $var_as_bool ) do_something(); # Invalid
The thing is, what Rust is doing with the borrow checker isn't even as subjective as that. It's enforcing a constraint which, like type constraints, is based in a mathematical understanding of how to entirely prevent certain classes of errors. Like most type systems, there are escape hatches to allow you to do what you need as long as you take responsibility. So, since it's in some aspects in concept and execution to type checking, it's natural to ask someone that is critical of it what they think of type checking, as it leads to a natural explanation of how it works and the benefits.
> And that's not even the weird thing, the weird thing is that users are begging for more.
People like street signs as well. That doesn't mean they are always followed, but it is useful to see how to work well within the system most the time.
Re: Still in love with Rust
#163Earlier quoted context omitted.
Does this matter anywhere outside of embedded software nowadays?
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
Re: Still in love with Rust
#164Earlier quoted context omitted.
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.
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"
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 symbols is still 78k smaller than the stripped, release version of the Rust equivalent. But it's great that they're trying to work on this problem.
Re: Still in love with Rust
#165Earlier 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 ]
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 less readable as your needs become anything more than trivial. My main issue is that focus for the important aspect of what is being accomplished swings back and forth from the front to the back of the statement multiple times, especially if nested and with conditionals. e.g.
[(x,y) for x in range(10) for y in range(10) if y > 5 if x [
(x,y)
for x in range(10)
for y in range(10)
if y > 5
if x toTen.filter(y=>y>5).flatMap(y=> toTen.filter(x=>x[x,y]) );
toTen.filter(y=>y>5).flatMap(y =>
toTen.filter(x=>x
[x,y]
)
);
Re: Still in love with Rust
#166Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
Mildly horse shit. It takes both on a team.
Re: Still in love with Rust
#167Earlier quoted context omitted.
So all programming languages at a higher level than ASM are horrible to you? They don't allow you to write everything that pure ASM does. Even C enforces structured programming.
It's all black or white, right. Someone says something less than flattering about your latest ideology and the gloves come off. Consider not identifying so hard with your tools, for all our sake. There are very few rules in C; same in Forth, Common Lisp and Perl among others; they provide tools, not religions. Python was always borderline. These days it's like they're in some kind of competition to stuff as many rule…
It's not like Rust has many rules. There's unsafe, use it if you like. The rest is the minimum number of rules needed to guarantee some level of concurrency safety.
It's not like Rust has any rules just to make your code look funny.
> These days it's like they're in some kind of competition to stuff as many rules as possible down peoples throats and get away with it.
Could you expand on this please?
> And that's not even the weird thing, the weird thing is that users are begging for more.
... which users? And if the majority of them, then this perfectly explains the competition, but why are you surprised about the users' need for rules?
Re: Still in love with Rust
#168Earlier quoted context omitted.
I have empirically witnessed that the larger a project gets, the harder it is to trust that the code does the thing you want it to do. It's far from nonsense.
True, regardless of language.
Indeed, yet different languages seem to have different slopes.
Re: Still in love with Rust
#169Earlier 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…
I agree. The most readable syntax for sequence comprehensions that I know of is C# LINQ and XQuery FLWOR, and it's no coincidence that they put the projection clause ("select" in C#, "return" in XQuery) last - it follows the overall flow better.
Re: Still in love with Rust
#170Earlier 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 ]
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.
What's the difference between a for-loop with an if-statement in it and the comprehension above? Even syntactically, they are almost perfectly matched on tokens. Except with a comprehension, you immediately know that not only it consumes a sequence, but it also produces one (whereas a loop could really do anything).