231–240 of 312 posts
Earlier quoted context omitted.
Your site does not works with Firefox ESR.
That's because ESR is a very ancient version of Firefox. Many things don't work on ESR. You need at least Firefox 52.
The current release of Firefox is only 53.0.2. If you need 52 to view a site, you're overdoing the new features.
I'm consistently blown away by just how good the project management for this language is. It's not just the forward progress that the language is making (which is considerable), but also just how well they package the information up into a form that the rest of us who are not involved day to day can digest, like has been done here. Another example is the "This Week in Rust" newsletter which takes progress that would'…
Tokio feels like something that needs its own funding and dedicated team... it feels like its development has been slower than what you would expect of a critical (to me) tool for elegantly handling async connections, which is particularly important for web servers.
Earlier quoted context omitted.
Is this based on benchmarks? I don't have any, but I can do a clean compile of 8000 java classes (> 2 million lines) in 3 minutes on my underpowered Mac mini. I wouldn't expect Rust would ever be as fast to compile, even if it weren't a younger language, because Rust is doing compile time optimization that Java defers until runtime. And that's ok: there may be times what Java does is better, but there are also times…
`cargo check` is pretty darn fast, and that's pretty much all you need while developing. I'd say it's generally 50% faster than a standard compile (not benchmarking, just a gut feeling). On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time…
Earlier quoted context omitted.
It's one of those things that's happened to so many people with so many C++ compilers on projects of any significant size that almost everyone says it. Happened to me with several where I moved from a Pascal-like language to find the compile time terribly slow even when I barely used the language. A lot of it is do to how the language's syntax, semantics, and esp templating are designed. Plenty of languages with even…
Oh totally agreed that C++'s compilation times are (quite infamously) a mess. I think that my parent was asserting that Rust's compile times are "usually ... far worse" (the "it" in the quote above is a reference to Rust). For all I know, that might be true, but it's one of those "citation needed" type things.
Earlier quoted context omitted.
Tokio feels like something that needs its own funding and dedicated team... it feels like its development has been slower than what you would expect of a critical (to me) tool for elegantly handling async connections, which is particularly important for web servers.
I'll happily fund one person full-time to work on that, but you'll have to convince the primary author to go for it :-)
Earlier quoted context omitted.
You're demanding the impossible here and elsewhere in the thread. Asking for the impossible is maybe ok, demanding it not so much. No one can demonstrate productivity gains because productivity can't be measured. Lines of code can, and those are often a bad thing. Some of our most productive efforts make programs smaller.
No one can demonstrate productivity gains because productivity can't be measured. So then the OP shouldn't have made the claim. It ain't my job to prove it. :) That said, I fundamentally disagree with the idea that one can't measure developer productivity. I agree that there are many potential measures, all of which have the potential to be flawed or distorted. But the idea that the productivity of a developer can't…
> So then the OP shouldn't have made the claim
Come now, it was you who moved those goalposts and you moved them half a field or more. OP claimed REPLs "have benefits". Your response was (paraphrased) "demonstrable measurement of productivity improvement or GTFO". That sort of ante-upping just isn't that nice for good conversation, and certainly not when you're demanding a standard none of us can meet about anything.
Earlier quoted context omitted.
We detached this ludicrous flamewar from https://news.ycombinator.com/item?id=14344760 and marked it off-topic. You repeatedly posted uncivilly in these comments. That's a bannable offense on HN, so please don't do it again, regardless of how wrong you think others are.
What a mess! Came to this thread to read about Rust and its progress and this has devolved into a useless discussion about some person's website, who seems to consider that he/she is doing all the right things and the rest of the technical community is stupid. Completely lost track of what thread I was reading.
One of these years we might implement a "More" link at the bottom of threads so you have to go to a second page to see them at all.
Earlier quoted context omitted.
In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc.
> In your opinion what are some of the things wrong with Rust? Genuinely curious as someone who operates at the higher level of the stack (web development) but is interested in learning something lower: C++, Rust, etc. I think the most classically cited problem is the learning curve. Understanding ownership and lifetimes, and understanding how to satisfy the borrow checker can be quite daunting. Here are a few that I…
To give one specific example, WinRT uses futures, and there you can write async code that flows from C++ through C# to JavaScript and back, with mapping to a common ABI type done transparently at the interop layers (https://docs.microsoft.com/en-us/uwp/api/windows.foundation....).
If and when we standardize on a higher-level ABI that includes fibers or something similar, then the other approach might make more sense. Of course, the problem is that there isn't a single consensus design to standardize on...
A few years ago I was a C evangelist. C++ was and more so now is a fine language with a lot of features I want. But Rust has that simplicity in a systems language that I crave that lets me do my own thing. That elegence. It's my favourite language by far. Keep it up!
Simplicity? Modula-3 was simple, fast, and safe. PreScheme was less type-checked but powerful and simple. You can learn how to use them in a day coming from an imperative or functional language. Rust looks like it gives users extra power/safety with quite a bit of a learning curve (most say weeks to months) due to extra complexity. Definitely not simple, though. https://en.m.wikipedia.org/wiki/Modula-3 https://en.m.w…
Earlier quoted context omitted.
`cargo check` is pretty darn fast, and that's pretty much all you need while developing. I'd say it's generally 50% faster than a standard compile (not benchmarking, just a gut feeling). On top of that `cargo watch 'test'`, runs fine on a 100kloc project, way better than my personal experience with Java. Now, when Rust compiles all dependencies from the ground up it is really slow, but that's only generally one time…
That assumes you're using cargo and it's "fuck the package manager" approach.