Earlier quoted context omitted.
There is no such thing as white space insensitive language.
Aside from strings, isn’t C white space insensitive?
The tokenizer is. `ab` is different from `a b`.
Rust can be difficult to learn and frustrating, but it's also very exciting
241–250 of 282 posts
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#242Earlier quoted context omitted.
Interesting! I don’t know how modern C++ deals with multi threading and shared memory etc.? Care to fill us in on the state of the art and how it’s as good as rust?
State of the art is pthreads and mutexes. The C++ and Rust wrappers for them are roughly equivalent. Rust has some nice features for handling ownership semantics, but they are not significantly better than those in C++. Meanwhile, Rust still lacks a normal exception handling story. Exception handling is absolutely necessary in 2018 for building real software systems. (And even though Rust claims that errors are nicel…
Haven't spent that much time with rust, but so far Result has sufficed for all my exception-needs; it's not clear to me what the practical difference is between exceptions and result, that would be relevant to implementing real software systems?
As I understand it, the primary usage of both is to report, and handle, errors. Rust splits it as panic! and Result, where panic! is naturally left for logic errors (ie states the program should never reach, regardless of circumstance; maintaining invariants), and Result is for everything else.
Exceptions do the same, but you can catch the broken-invariant case as well? I'm not sure how often you want to recover from such a state though.
Another aspect is retrieving the stack-trace, which iirc doesn’t exist in a normal result-type, but error-chain! magically handles it for my case (never looked into how, or at what cost)
Otherwise, the other major difference is that rust enforces that you explicitly handle all result types, making it part of the API contract, while most languages, with unchecked exceptions, leave it as a new runtime error to be found after updating your libraries. Java gives you checked exceptions, but in a much more syntax-unpleasant fashion (but thats always the case with java).
As far as I'm aware, Result seems to me a much cleaner solution than exceptions for the same use-case. A bit of concern for API updating, since the errors are part of the API so its more difficult, but at the same time, I'd rather update the library and fix the codebase, than update and wonder if a new Exception exists (or perhaps, always existed? Is there any way to find out the list of possible exceptions in C++, without reading the function, and all the code it depends on?).
The primary unpleasantness is that a single use of Result infects the entire callgraph until its handled, but thats true with exceptions as well. I'm not too happy about async/await for the same reason
Of course, part of the reason I'm interested in using rust as my hobby-language is because I'm absolutely sick of runtime errors and writing worthless tests in python, so maybe there's an appeal thats missing for me
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#243Earlier quoted context omitted.
The benchmarks game is just that: a game. Notably, Go programs are prohibited from doing certain optimizations that are permissible for C++ programs. The conventional wisdom is that Go and Java are within the same order of magnitude as C++ though still slower. I’d accept that they are a full order slower, but not multiple orders. > Do you dispute nil and * I dispute that Go’s pointer is a “raw pointer” in any meaning…
> The benchmarks game is just that: a game. The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money. It's what you make of it. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > Go programs are prohibited from doing certain optimizations that are permissible for C++ programs Which programs? Which…
[deleted]
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#244Earlier quoted context omitted.
Woah, woah, woah. First, Go and C++ are vastly different languages. Apples and oranges. C++ is huge . It takes an incredible amount of effort to become a proficient C++ developer, and even then, C++ offers none of the amazing safety guarantees that Rust's borrow checker enforces. It's old language with sedimentary layers, including C backwards compatibility. Rust is no where near as complex, and Rust does 5x more to…
> but it's performance is closer to Java, which is a few orders of magnitude slower than C++ A few order of magnitude is an exaggeration. A more reasonable expectation is a 5x slowdown [1]. Depending on your task, a few orders of magnitude can be correct for JVM based languages; they can have very poor startup times (compared to c++) [2]. However, in startup time, go is not similar to Java. [1]: https://benchmarksgam…
> JVM based languages; they can have very poor startup times (compared to c++) [2]
Hello world :-)
And is 54.55 ms perceptable?
(310.81 ms should be).
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#245Earlier quoted context omitted.
> The benchmarks game is just that: a game. The name "benchmarks game" signifies nothing more than the fact that programmers contribute programs that compete (but try to remain comparable) for fun not money. It's what you make of it. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... > Go programs are prohibited from doing certain optimizations that are permissible for C++ programs Which programs? Which…
That benchmarks game quote supports my point (not sure if you quoted it to contradict me or not?). As for prohibited optimizations, arena allocation is the one that comes to mind since it’s the standard way to avoid O(n) allocs.
> That benchmarks game quote supports my point…
As-long-as your point was not intended to be dismissive in any way.
> prohibited optimizations
Go programs are not prohibited from using arena allocation provided by a generally available library — that is what the C++ programs do.
Unfortunately there doesn't seem to be a generally available Go library that provides arena allocation. Of course, Go does provide GC.
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#246Earlier quoted context omitted.
It is somewhat unfair to compare this to Python, since a lot of the simplicity in Python comes from the semantics (dynamically typed, garbage collected and so on). Rust need to express all this information (types, lifetimes etc.), so it will necessarily be more dense. The question is if this information could be expressed in a more readable syntax. This might be possible, but I would like to see a suggestion of how.…
Here is a simpler syntax: fn accumulate tuples: &[(&'a Str, &Fn(i32) -> Bool)], i: i32 -> t where t: Monoid + From &'a Str + From String, this is how Haskell with lifetimes and borrowing would look like (if arguments were not curried)
This is arguably less readable, because it's missing some delimiters for your eyes to latch onto.
It's also not realistically parseable- the Haskell/Ocaml-like removal of s and ()s relies on application being left-associative, and if you read this under that rule you've changed the meaning (e.g. `From &'a Str`).
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#247Earlier quoted context omitted.
That benchmarks game quote supports my point (not sure if you quoted it to contradict me or not?). As for prohibited optimizations, arena allocation is the one that comes to mind since it’s the standard way to avoid O(n) allocs.
> That benchmarks game quote supports my point… As-long-as your point was not intended to be dismissive in any way. > prohibited optimizations Go programs are not prohibited from using arena allocation provided by a generally available library — that is what the C++ programs do. Unfortunately there doesn't seem to be a generally available Go library that provides arena allocation. Of course, Go does provide GC.
It is dismissive of the idea that the game can tell you meaningful things about a programming language’s average or percentile performance or even its peak performance.
> Go programs are not prohibited...
Right, and this is why the Go benchmarks for allocations aren’t very meaningful. Using arenas (or other kinds of preallocation) is a common optimization in Go even if Go doesn’t have a library for it.
I’m sure you’re well aware of all of this since you evidently contributed to these benchmarks, but for other readers, here’s a good thread about why these benchmarks aren’t meaningful.
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#248Rust is the answer to the question "can we have speed, correctness, and expressiveness in one language?" My company has been running Rust in production for awhile now, and it's exceeded every expectation. It's fast, it's safe, and it's so productive it's hard to find a reason to use anything else. We've also found that the learning curve is, in our opinion, a bit overstated. We've ramped up several new grads on Rust…
A shallow learning curve and cute compiler messages are the least of your problems when doing C++-caliber software. The 'small, easy language for ignorant developers' niche certainly exists, but it's already taken by Go. Rust currently provides no benefit over (modern) C++ for the problems where using Rust or C++ makes sense. (Though perhaps Rust will make it easier for layman developers to learn Rust and then transi…
I... what? Rust is hardly targeting "small, easy language for ignorant developers," and putting it in that camp because it has nice error messages is unreasonable.
I'm even more perplexed by "Rust currently provides no benefit over (modern) C++."
* Rust's "pthreads and mutexes" wrappers prevent data races at compile time, and there's Rayon to compete with things like OpenMP.
* Rust's moves are destructive, guaranteed nothrow, and also checked at compile time.
* Rust's borrow checker is light years ahead of C++'s.
* Rust's type system lends itself to far simpler generic code, with trait-based generics and sum types instead of concepts and std::variant.
* Rust's iterators are much better than C++'s, to the point that Ranges is one of the most highly-anticipated additions to C++.
All of these are things C++ is actively trying to improve, so clearly at least the committee agrees they're worthwhile features.
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#249Earlier 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.
C++'s ADTs are std::variant, which is horrific.
C++'s type classes are concepts, which are hardly more than syntactic sugar over SFINAE.
Neither can really compare to Rust's enums or traits.
Re: Rust can be difficult to learn and frustrating, but it's also very exciting
#250Earlier quoted context omitted.
There is no such thing as white space insensitive language.
Fortran IV came close. You could put spaces in the middle of identifiers, keywords, and numbers, and the compiler ignored them. The language did not require spaces as separators anywhere. Spaces were only significant in Hollerith constants (what we'd call string literals today) and in columns 1-6. Columns 1-6 were reserved for line numbers, comment signifiers, and continuation marks.
Indeed, the classic resulting bug was the do loop with a typo.
Instead of comma the program had a period. So this
DO I = 1.100
DOI = 1.1
http://catless.ncl.ac.uk/Risks/9.54.html#subj1