81–90 of 120 posts
I wasted three months on rust then got sober, and went back to c++, then life was good!
Also, nice to read a review of Rust that didn't reduce to “C is the worst evar!” or “Haskell makes no sense!”. Reasoned and clearcut. I certainly disagree with various parts of the review, but I don't do any dev for webservices so it is unsurprising that the author and I have a differing of opinion.
> The Rust community seems to be populated entirely by human beings. :D Regarding your borrow checker example, note that your code is now prone to blowing up if `step` is modified too much. You have created the necessity of an invariant (step should not pop out of the vector) which may be broken by later cleverness. See http://manishearth.github.io/blog/2015/05/17/the-problem-wit... for more details. Note that in thi…
The take-away for me is this: "Despite the restrictions of the type system, I am more productive in Rust than I am in either Javascript or Haskell. It manages somehow to hit a sweet spot between safety and ease of use." When I toyed with Rust last year (so, I'll admit my knowledge is outdated, I need to refresh it), I had a pleasant experience on the productivity side. The big reward for me, coming from C/C++, is tha…
"Modern machines are a huge pile of opaque and unreliable heuristics and the current trend is to add more and more layers on top. The vast majority of systems are built this way and it is by all accounts a successful strategy. That doesn’t mean I have to like it." This is a really valuable observation. "Smart" compilers seem great for letting you write code without thinking too hard when performance requirements are…
I think the opposite is true. Modern hardware is so complex[1], made even more so by its constant interaction with a complex OS, that any sense of familiarity with the actual performance model is illusory, unless you're doing something very controlled and very specific (like, say, DSP). Modern hardware itself is an abstraction, hiding its operation away from you. We can no longer hope to tame hardware with meticulous…
Earlier quoted context omitted.
Why can't you practice Rust in a non-business environment?
Programmers always spend too much time on studying which hammer is better, but they forget what they really want to do, right?
+1, at the very least, because of the nod to Terra. Terra, imho, feels a lot like the perfect middle-ground between Lua and Rust. It has a clean syntax with some handy/fancy features but keeps a simple static typing system that makes me feel comfortable. Also, nice to read a review of Rust that didn't reduce to “C is the worst evar!” or “Haskell makes no sense!”. Reasoned and clearcut. I certainly disagree with vario…
> I don't do any dev for webservices so it is unsurprising that the author and I have a differing of opinion
I don't either, I'm working on a database / language runtime. It happens to have a html interface rather than a console interface, but the majority of the work is very far away from normal web-dev :)
> Terra, imho, feels a lot like the perfect middle-ground between Lua and Rust
In particular, I really like the idea that the Terra type-system is just Lua code, so you can have different kinds of static analysis in different places instead of one-type-system-to-rule-them-all. Of course, it's a totally unproven idea at this point so it's hard to say how that would turn out in a real project.
Earlier quoted context omitted.
I think the opposite is true. Modern hardware is so complex[1], made even more so by its constant interaction with a complex OS, that any sense of familiarity with the actual performance model is illusory, unless you're doing something very controlled and very specific (like, say, DSP). Modern hardware itself is an abstraction, hiding its operation away from you. We can no longer hope to tame hardware with meticulous…
And yet I consistently find that checksum tools, compression libraries, and things like video decoders (such as H264 decoders) written in assembly consistently outperform all other implementations I've had to deal with. "Sufficiently smart compiler" is a tired meme at this point. There are few programs that benefit from being entirely written in assembly, but quite a lot who do having parts of them hand optimized. So…
That's precisely the example I gave. Although many modern decoders use GPUs, which are much simpler than CPUs (simpler even than 90s era CPUs). The GPU performance model is very simple to comprehend.
> No$GBA would lose a lot if it were rewritten into a high level language.
That's a nice sentiment, but I don't think it is supported by the facts. You could probably write a JIT in Python that would perform much, much better (but that would be overkill, given that you're emulating a very slow, very small machine), and a trivial implementation in Java would probably perform just as well.
The ability to achieve significantly better performance for general-purpose tasks (let's call that "branchy code") with low-level languages today is more myth than reality. What is true that some high-level languages consciously give up on some performance to make development easier, but that's a design choice. That's not to say that optimizing JIT and AOT compilers get everything right -- they don't -- but they get it right often enough that they're very hard to beat.
"Modern machines are a huge pile of opaque and unreliable heuristics and the current trend is to add more and more layers on top. The vast majority of systems are built this way and it is by all accounts a successful strategy. That doesn’t mean I have to like it." This is a really valuable observation. "Smart" compilers seem great for letting you write code without thinking too hard when performance requirements are…
I think the opposite is true. Modern hardware is so complex[1], made even more so by its constant interaction with a complex OS, that any sense of familiarity with the actual performance model is illusory, unless you're doing something very controlled and very specific (like, say, DSP). Modern hardware itself is an abstraction, hiding its operation away from you. We can no longer hope to tame hardware with meticulous…
My aversion to piles of opaque heuristics is not because I'm against smart compilers, just that for certain projects I want to be form a mental model of what code I should write to get a certain effect. The trend of modern languages with heavy heuristic optimisations or complex JITs is towards less certainty and less stable optimisations, so that a program that runs fine today might be unusably slow tomorrow.
Staging and compiler-as-a-library is a promising compromise for projects that really care about stable performance eg http://data.epfl.ch/legobase . You can still have an LLVM-smart compiler underneath but you get to make the first pass.
Rust is actually very predictable in some respects eg generic functions will be monomorphised. I prefer it to wrangling GHC or the V8 JIT.
This is a super interesting read! Having come into Rust from an experience with mostly object-oriented languages (Python, Java, C++), what you seem to have taken for granted, I found surprising and new, and what you are surprised by (such as self parameters), I found quite normal. It's great to see the other side of this.
Manishearth cleared up most of my confusion - it affects namespacing and auto-borrow but doesn't interact with constraints. Traits are very similar to typeclasses and I was just thrown by the surface level syntax.