Live data from Hacker News

Rust can be difficult to learn and frustrating, but it's also very exciting

influxdata.com

171–180 of 282 posts

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#171
post #147

Earlier quoted context omitted.

Actual problems like: - sending dangling references to thread functions. Lambdas with automatic reference capture creating threads from inside functions that exit are terrible here. - returning a pointer or reference to an invalidated iterator - returning a pointer or reference to the contents of a temporary Yes indeed, C++ programmers never actually have these problems, they are purely imaginary. /sarc

Yeah, I don't think there is a professional C++ developer who has any of these problems. It's called static analysis... welcome to a decade ago. Why on earth would an organisation move their codebase to Rust when they can just run Clang? Which they should be doing anyway.....

Unfortunately a lot of browser's CVEs tell a different story.

> Why on earth would an organisation move their codebase to Rust when they can just run Clang? Well, you can ask C++ professional at Mozilla.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#172

Earlier quoted context omitted.

Python is pretty to look at, but I hate working in white space sensitive languages. If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window. Also, it makes autoindent in Emacs worse.

Well, tabs versus spaces is not a Python thing, that will bite you in any language eventually. Blame the VT-100 terminal. Here is the thing about indentation versus curly-braces-and-semi-colons: It boggles me that people find it acceptable to use one mechanism to communicate block structure to the compiler, and a completely different mechanism to communicate block structure to humans, and have no way to automatically…

> It boggles me that people find it acceptable to use one mechanism to communicate block structure to the compiler, and a completely different mechanism to communicate block structure to humans, and have no way to automatically check that they have the same semantics. This is a frequent source of bugs, and is entirely preventable.

Strongly agree. The solution that Rust, Go and other new languages have adopted is shipping a formatting tool to consistently make the semantics of indentation and braces match. I personally can't help but think that this is a worse-is-better solution when compared to significant whitespace, but at least it works. Every Rust CI I am setting up will fail the build if `rustfmt --write-mode=diff` feels like you didn't run rustfmt before committing.

> But the main thing that makes Rust harder to read is all the punctuation noise

Given the decision to favor explicit casts, references and dereferences over implicit ones, this cannot really be helped. In some ways, once you get used to it, it helps readability, because it always communicates what the things being worked on are.

> and short, cryptic keywords.

I agree that this was probably a mistake. Cannot really be helped now, though.

Overall, I think the readability argument against Rust is overstated. Sure, when you are starting out it looks like line noise, especially if compared to python. But it didn't take me more than a week or two before it basically became entirely clear and readable. The radical explicitness of the language helps readability in many ways that make it much better than C++.

Of course, much better than C++ is a low bar to pass.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#173
post #157

Earlier quoted context omitted.

> Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My biggest gripe is that they left out readability. I like the semantics of Rust, and appreciate the performance and the transparent memory model. I am extremely excited to try Rust on an embedded project. Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance…

>Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance on my keyboard. What exactly is terrible about it? The snake_case I got used to, I kind of like having braces, and that's not really a killer argument either, because most languages have them, apart from that I find Rust also much cleaner than Python syntax. I'm really not sure what you mean. Is it the lifetim…

Okay, tell me if this is readable to you:

   fn accumulate(tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> T
   where
        T: From + From,
this is JUST the function signature

yes, every single thing in there is necessary, it can be written in a more gruesome way, but the where clause clarifies it a bit

But let me cheat a little bit

    ( $(#[$attr:meta])* enum $enumer:ident { $($i:ident => $e:tt $( ( $($m:ident),* ) )* ; )* } ) => {
how is this macro syntax looking?

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#174
post #117

Earlier quoted context omitted.

I always found it easier to improve the time waiting for postgres by tuning critical queries than to track down runaway memory usage and tune garbage collection. I also felt like I spent a lot of my wall clock time during active development waiting for apps to start up and run tests or whatever. There are best practices which speak to most of this, but they were hard won.

But that doesn't come for free with Rust. You still have optimize the DB. And then does it really matter which language you use, since the DB is still going consume most of the time generating a web page anyway, right?

You should really be memcaching the database aggressively. I got it to the point that PHP was taking more time than the database for most pages because most pages DON'T need to be updated that frequently.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#175

Earlier quoted context omitted.

Rust is based on ADTs, typeclasses, and type parameters. C++s toolkit for abstraction is templates and OOP. They're completely different, and it sounds like you're just trolling anyway.

C++ has ADTs from C++17 and will have typeclasses from C++20. Templates with type traits are effectively a superclass of type parameters anyway.

Templates generate bad error messages because they are duck-typed. Rust is better at this.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#176
post #173
post #157

Earlier quoted context omitted.

>Bur honestly, the syntax is gruesome. Coming from Python, Rust looks like two rabid gerbils had a war dance on my keyboard. What exactly is terrible about it? The snake_case I got used to, I kind of like having braces, and that's not really a killer argument either, because most languages have them, apart from that I find Rust also much cleaner than Python syntax. I'm really not sure what you mean. Is it the lifetim…

Okay, tell me if this is readable to you: fn accumulate (tuples: &[(&'a str, &Fn(i32) -> bool)], i: i32) -> T where T: From + From , this is JUST the function signature yes, every single thing in there is necessary, it can be written in a more gruesome way, but the where clause clarifies it a bit But let me cheat a little bit ( $(#[$attr:meta])* enum $enumer:ident { $($i:ident => $e:tt $( ( $($m:ident),* ) )* ; )* }…

#1 I find is not worse than C++, granted there's more complexity here than in Python but in terms of cleanness its ok IMHO. Because as you said there's nothing unnecessary. Rust addresses different problems than Python, so we should compare apples with apples.

On the second one you got me though, I find the macro syntax a bit horrible. Sometimes I just want simple text substitution.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#177

Earlier quoted context omitted.

All network I/O is inherently asynchronous of course, so the sync vs async debate is more about whether to use the blocking abstraction the kernel provides versus bringing your own or writing async code directly. Using async I/O or a userland abstraction like green threads necessarily means you're moving the I/O scheduling work into userland. Sometimes this might be the right call, but it's effectively a bet that you…

> These days OS threads are a totally viable option for building highly concurrent network services on Linux. Spawning hundreds of thousands of threads works fine and is fast enough for most applications. I don't agree. If you're at the point where you need to handle such large numbers of concurrent threads, my own experience and online benchmarks clearly show it is not fast enough. Why are none of the top performers…

You don't need million threads to be really fast. You need enough threads for your load. If you need to handle 1000 requests per second with each request taking 10 ms in average, you need 100 threads. It's absolutely adequate number of threads for OS to manage. If you would write this code with async style, you won't achieve anything, because bottleneck would be with database or another service or disk I/O. Million threads is very rare case.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#178
post #131

Earlier quoted context omitted.

Some of those reasons are political, not technical. Like C on embedded vs C++. On Windows large majority of apps are in .NET with some C++. On OS X and derived systems it is all about Objective-C and Swift for desktop apps. C++ is mostly used for drivers, LLVM tooling and Metal shaders. Android is Java with some C++. ChromeOS is all about JavaScript. So no, C and C++ have lost the desktop, nowadays they are used for…

C is not used in the embedded space for 'political' reasons but for the fact that in contrast to C++ you have full control over what your program does and don't have to worry about when certain functions get magically called and why the size of your two-int struct is suddenly way larger than the 64 bits you expected it to be. Sure, this is all a matter of 'using it right', but from my experience many developers in th…

That's relevant when you target .15$ processors, but they are rather niche.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#179
post #142

Earlier quoted context omitted.

Python is pretty to look at, but I hate working in white space sensitive languages. If I have to have another argument about tabs vs. spaces I am going to toss my monitor out the frickin’ window. Also, it makes autoindent in Emacs worse.

PEP-8 (more than 15 years old) recommend spaces, so unless you are deliberately looking for a fight, the question is settled. Autoindent is a solution to a problem that doesn't exist in Python in the first place. Having two independent representations for blocks, one for human readers (indent) and one for compilers (braces), leads to nasty bugs when they get out of sync. Autoindent is a tool to keep them in sync. In…

But the tooling for editing the code has no support for indenting blocks as trivially as adding braces. Sure, you just run clang-format or such on the block/file, and get all the visual stuff sorted out.

Re: Rust can be difficult to learn and frustrating, but it's also very exciting

#180

Earlier quoted context omitted.

Well... compared to Python is kind of an apples to oranges comparison. Compared to Java or C++ I find it to be incredibly direct and expressive. Rust definitely doesn't stop you from writing spaghetti, but no language does.

I don't think the potential for spaghetti code is the problem, I think it's more the terseness of Rust code that makes it hard to read (speaking as someone who doesn't know Rust very well, but has a mild interest in learning it). I agree with the above complaint - it does feel a bit terse and that makes it harder to read IMO. Languages like Java are more verbose which does make it a bit more frustrating to write but…

That's in part due to the compiler not yet being the best in type inference, and should get better (as far as explicit type signatures are required).
Post reply on HN