5 ms·
> I thank it for making me a better software engineer It's especially nice that Rust has kept this basic attitude from C/C++ and in fact strengthened it a lot
by 0815test 7y ago
> I thank it for making me a better software engineer
It's especially nice that Rust has kept this basic attitude from C/C++ and in fact strengthened it a lot and aligned it with modern trends, even as it got rid of the annoying "core dumped" part almost in its entirety.
(The latest tagline of Rust is "A language empowering everyone to build reliable and efficient software." Do notice the everyone part, and especially the empowering bit - as opposed to letting even novice developers hobble themselves with substandard, bootcamp-level software-dev practices!)
- jimmaswell 7y agoI wish Rust would have kept saner OOP style classes from C++ instead of this bizarre trait stuff. The whole language feels like everything is just different for the sake of being different. Why is it "fn blah (x -> int.. -> int" or whatever when the rest of the tokens seem designed to save keystrokes at the cost of readability? Everyone is used to "int x(int y..". I've learned it some and the concepts around memory ownership and everything are good but the syntax is needlessly weird and annoying.
- Retra 7y agoRust is not based on C++. People coming from Haskell/ML aren't used to C's backwards type declarations, and that's why they're not in Rust; the people who make Rust have experience with more than just C/C++. So it's not different for the sake of being different, it is actually trying to be similar ... just not similar to C.
- jimmaswell 7y agoSimilar to languages much fewer people use, instead of languages more commonly used as systems languages which Rust is meant to be.
- steveklabnik 7y agoIn general, it’s a thing more newer languages are moving to, because it’s regarded as superior for a few different reasons. Mostly, it keeps the syntax more regular when you have type inference. See Kotlin as another recent example. In rust, we have additional reasons, and that’s because it’s not let name: type = expression; It’s let pattern: type = expression; Patterns offer more power than simple variable declarations. The names may not correspond 1-1 with the type, because you can create multiple names by destructuring more complex types
- deleted 7y ago[deleted]
- nullwasamistake 7y agoI agree. The language design is great, but they purposely use weird conventions everywhere. And by weird, I mean foreign to C++ programmers which is 90% of their user base. They should have done what java did. Copy C++ syntax, only change it when needed. I've ported over java code where 2/3 of lines are nearly identical. The async debacle is a great example of this. They settled on weird syntax instead of doing what every other language does, because of some holier than thou acedemic snobbery. If every other language does it that way, it would have worked fine in rust.
- 0815test 7y agoThe Rust type syntax is not weird. C-like languages are weird, because their syntax grew by accretion from a much simpler use case where something like "int x;" or even "int f(int a, int b);" could make sense. But even typedefs famously screw that up, never mind everything else. > because of some holier than thou acedemic snobbery The async syntax was one of the most widely discussed issues in Rust development, and ergonomics concerns were key in what eventually was chosen. It's very misleading to describe it as your comment does. Re: parent comment, the Rust programming language book (free online) has a very nice section describing OOP-like patterns in Rust - as it turns out, the "good parts" of OOP are very nicely supported, and in a far simpler, more orthogonal way than what you get in C++. This means fewer dark corners in the language and something far easier to work with overall. Just because it may be different from what we did back in the 1990s, doesn't make it wrong!
- nullwasamistake 7y agoI really like rust, the design is great. I'm glad they cleaned up OOP and ditched nasty C++ stuff like templates. However, I went through the book recently and I'm quite annoyed that much of the syntax differs needlessly from C like languages. It massively increases the cognitive overhead for someone coming from Java, C++, C#, C-like language world. Rust is a systems language, it doesn't even have a runtime. 90%+ system level work is done in C-like languages. Rust syntax differs in countless pointless ways. I'm not saying it's wrong, it's just different in ways that don't matter from all other popular systems languages. Which is dumb. Things like "fn" instead of "function" and async syntax make Rust difficult to adopt by the target user base. Why fn? Is saving 6 characters worth confusing everyone?
- ChrisSD 7y agoC++ classes vs. Rust traits isn't just a matter of syntax differences. Btw the function syntax is: fn foo(x: u16, y: u16) -> u32 If it were more C++ like it'd be: u32 foo(u16 x, u16 y) Which is less keystrokes if anything.
- jimmaswell 7y agoExactly, they do stuff like fn yet make it longer than necessary otherwise.
- ChrisSD 7y agoI don't think it should be designed to save keystrokes at the cost of readability.
- jimmaswell 7y agoIt already does that elsewhere, yet strange backwards type definitions are much less readable by default to most programmers. It's like making us learn French when we could have learned British English, assuming American English as a starting point.
- ChrisSD 7y agoI think you have to be careful when presuming to speak for "most programmers".
- jimmaswell 7y agoHere, at least 40% of programminging is done in C style syntax. The rest isn't in any consistent majority style. Most programmers are probably most familiar with C style and almost all are familiar in some form. https://www.tiobe.com/tiobe-index/ https://www.tiobe.com/tiobe-index/
- a1369209993 7y ago
- feanaro 7y agoI actually greatly appreciate that function definitions begin with a dedicated keyword in Rust. I've always found it rather painful that definitions don't stand out from function calls in C and C++.
- hollerith 7y agoAgree. With a dedicated keyword, you can find a function definition using just grep.
- blt 7y agoSpecial keywords like `fn` make parsing simpler. Trailing return types are useful in languages that support generic programming, because they make it easier to write a function whose return type depends on the types of its generic inputs. Even C++ has this feature now, using decltype and arrow notation: template<typename T, typename U> auto add(T t, U u) -> decltype(t + u) { return t + u; } C++ is notoriously hard to parse. Consider the "most vexing parse", or the fact that refactoring tools for C++ are always flakier than their Java / C# / Go equivalents, or the fact that https://cdecl.org/ https://cdecl.org/ exists. New languages in the "expressive, high performance" niche cannot continue to be held back by C++ syntax.
- jimmaswell 7y agoC# and Java as you mentioned use very C++-like syntax.
- joshuamorton 7y agoTo a first approximation, yes. But consider that the C++ grammar has ~100 more rules than Java (~170 vs. ~280), and parts of the C++ grammar are strongly context-dependent, which isn't true in Java.
- llukas 7y agoTools can use LLVM infrastructure to get ast. No need to parse it yourself.
- MauranKilom 7y agoThe AST is still really complex though (in terms of corner cases to cover).
- deleted 7y ago[deleted]