Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

131–140 of 312 posts

Re: Two years of Rust

#131

Post by goatlover »

sqeaky wrote: post #111
goatlover wrote: post #97

Earlier quoted context omitted.

But do you think the Go community agrees with this, just to name one of the popular newer languages? It's nice that Rust is doing well, and more power to the community. But there is an entire world of programming language communities out there that might not agree with the assessment that Rust is the future for them. Anyway, I was around for this kind of talk when Java was new and shiny, and there were people in the…

Depending on who you ask Java did replace everything. Consider the Tiobe Index [1]. Java Beats out everything, including C and C+++ when added together. All three are growing, but not nearly as fast as everything else is growing to the point it looks likes they are shrinking. There is an absolutely enormous amount of Java out there. https://www.tiobe.com/tiobe-index/

If you mean Java replaced C/C++ as the most widely used language, at least according to one index, then that's one thing. So if someday Rust became as popular, great for Rust. But that's not the same thing as claiming that Rust will be the One True Programming language in use that will cause all the other language communities to die out and convert to Rust.

That's what is being claimed above, and what some in the Java community were claiming in the 90s. Also, probably some in the Javascript community these days.

But it's never happened. If there was the One True Language to rule them all, then Lisp, C++ or Haskell would have done it by now.

The point with Java is that even though it was targeting the C/C++ crowd specifically, and it became widely popular, did not cause C/C++ to die.

Re: Two years of Rust

#132

Post by valarauca1 »

Animats wrote: post #72

The success stories are Mozilla's Servo, Dropbox's client and back end, and parts of Gnome. That's good. It's interesting that all the success stories involve mixing Rust and C/C++ code. Are there any pure Rust successes yet?

Alacrity is insanely fast OpenGL terminal emulator [1]. I use as my semi-daily driver for most VIM'ing

AgiData built a MySQL proxy [2] out of it... They manage sharding MySQL servers for enterprises. They claim their working it into production.

[1] https://github.com/jwilm/alacritty

[2] http://www.agildata.com/building-scalable-mysql-proxy-rust/

Re: Two years of Rust

#133

Post by fizixer »

nickpsecurity wrote: post #4
maplant wrote: post #2

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…

Looking at Modula-3 wikipedia page, no thanks. (If it's case-sensitive, I don't want to switch to uppercase everytime I use the language keywords. If it's not case-sensitive, don't even get me started.) I had enough of that for a lifetime through FORTRAN, COBOL, SQL, BASIC, ASSEMBLY, etc.

PreScheme sounds like an interesting idea.

Re: Two years of Rust

#134

Post by eridius »

mmstick wrote: post #129
eridius wrote: post #112

Earlier quoted context omitted.

> That I do not support web browsers that don't support Brotli should already tell you that I don't care if they support Brotli or not! If there is no support, there is no support! Doesn't effect me. You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed responses. You had to modify it to add always-on Brotli encoding. > I…

> You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed files. You had to modify it to add always-on Brotli encoding. I did not have to go out of my way to 'break support for these browsers'. All I did was replace the gzip-compression code in my page cacher with brotli-compression code. In other words, I went from always-…

Always-on gzip encoding is also technically broken, it's just far more likely to be supported out of the box by other HTTP clients.

> What does matter is that my website only supports the HTTPS protocol

No, that has literally no bearing on this discussion about your use of Brotli encoding. You're weirdly fixated with this, but it's completely irrelevant.

> This is nothing more than pure trolling.

Do you normally go out of your way to insult people who are trying to have a discussion with you? Because that's what calling someone a troll is.

> All major web browsers support Brotli over HTTPS

Why doesn't Safari count in your eyes as a major browser? Or perhaps more interestingly, why doesn't iOS Safari count? Are you really ok with your site not working for 100% of iOS users?

> In addition, as the web is moving to being HTTPS-exclusive, it's about time that you start getting used to it. You're wasting your time.

Why do I have to keep repeating this? HTTPS has literally nothing to do with this discussion. You keep bringing it up over and over again as if it's somehow meaningful, but all it tells me is that you literally have no idea what you're talking about.

Re: Two years of Rust

#135

Post by mmstick »

sqeaky wrote: post #124
mmstick wrote: post #70

Earlier quoted context omitted.

That would require that I cache both a gzip and brotli variant of each page and content that is requested. I see no reason to support gzip just because a single company has refused to implement support for Brotli. Firefox, Chrome and Edge all support Brotli. Safari is the one man out. Apple needs more complaints about the lack of Brotli in Safari. Using Safari? Don't. You have Firefox and Chrome on all of your platfo…

What about serving uncompressed content over https? What about serving up an error page when the user's browser odesn't have compressor you support? What about paying attention to web standards? What about people who are stuck with old software for one reason or another?

> What about serving uncompressed content over https?

I have limited bandwidth. I don't want to serve uncompressed content over HTTPS.

> What about serving up an error page when the user's browser odesn't have compressor you support?

I will do that once I figure out how to get the Request header from Rocket's API.

> What about paying attention to web standards?

I'm already complying with HTTPS web standards. I'm even pending for the HSTS preload list ( https://hstspreload.org/?domain=mmstick.tk ).

> What about people who are stuck with old software for one reason or another?

That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable.

Re: Two years of Rust

#136

Post by 3pt14159 »

brandur wrote: post #10
sillysaurus3 wrote: post #7

Earlier quoted context omitted.

I'm still on dabbling in Rust, but I'm fairly convinced that in another few years after this Tokio churn has gotten a chance to settle down and the async patterns are more broadly refined, there won't be many justifiable reasons to not write new projects in it, whether they're as low level as a Postgres extension or as high level as a DB-backed HTTP application. Not being hindered by the compiler telling you what you…

> Not being hindered by the compiler telling you what you can and can't do; freeing yourself from the write-compile-debug cycle, reducing it to repl-done; etc. Yeah, I certainly understand various language trade-offs, but in my experience any of these early wins of interpreted languages come back to haunt you at significant cost. I saw someone use the analogy of a credit card on here before: purchases are very easy t…

I fully agree with you, but I still start projects in Ruby.

Why?

Because returns from startups are exponential and the interest rate is higher than the interest rate on the technical debt.

It's why compiled is a great choice for an established corporation with a well defined need and a large user base, while interpreted is better for most other business contexts, especially with tools like Numpy.

Re: Two years of Rust

#137

Post by derefr »

zzalpha wrote: post #120
derefr wrote: post #99

Earlier quoted context omitted.

> I've honestly never understood the obsession with it. The true key to understanding REPLs is their role in consuming third-party libraries. While languages both with and without REPLs will have well-used packages in their package ecosystems that are well-documented ; languages with REPLs will also manage to have well-used, poorly-documented packages: packages whose "documentation" consists only of the de-facto abil…

For (most) languages lacking a REPL, it's very similar. Instead of a REPL you write compiled unit tests and/or test programs to poke around at the API. For languages with a reasonably sophisticated IDE, use the IDE itself to jump straight to the class/function declarations to understand the surface area of the API, and jump to the decompiled code for the implementation of those functions if you're the type to want to…

> What's your experience level with other languages?

~15 years experience across C, ARM assembler, Javascript, Lua, Ruby, Python, Erlang, Go, and Rust. Mostly doing Elixir these days.

Admittedly, I've never used an IDE; I write all my C in vim.

> ...you write compiled unit tests and/or test programs to poke around at the API.

That assumes you can get your tests to compile; or that the compilation errors are at-all helpful when they don't. If you've got a library that

1. ships as a binary blob + header files, and

2. most of its functions take handles to structs that are declared opaquely in the SDK headers; and yet

3. nothing you do with the badly-documented "create handle" parts of the API is giving you a struct that the "consume handle" parts of API will do anything with but crash...

...then you'll really wish that you had a REPL; or rather, a language runtime that enforced some level of introspect-ability on everything, so that a REPL could show you what's in the struct and whether your calls so far have failed to touch some obviously-necessary-to-fill-in part of it.

Without such support, you will have to rely on reading the decompilation results of both ends of the API to figure out what's really going on.

Re: Two years of Rust

#138

Post by mmstick »

nercury wrote: post #118
mmstick wrote: post #45

You might like to know that I've had great success with full stack web development using Rust. My website ( https://mmstick.tk ) is hosted with the Rocket ( https://rocket.rs/overview/ ) web framework and operates as a fully static binary with 100% Rust code. I've even got HTTPS and Brotli compression.

Please stop claiming to support HTTPS when your site breaks perfectly https-compliant browsers.

It supports HTTPS perfectly fine. I am even on the HSTS preload list. You can't get on this list unless you have a HTTPS website that meets standard requirements. https://hstspreload.org/?domain=mmstick.tk

Re: Two years of Rust

#139

Post by bluejekyll »

hyperpape wrote: post #110
vvanders wrote: post #71

Earlier quoted context omitted.

Oh please, it's plenty fast, at least on par with javac. There's also 'cargo check' which is blazing fast. If you're seeing very large compile time then it's a good sign that you probably want to break things into smaller crates anyway. I've been working on some pretty large stuff and compile speeds haven't been an issue(aside from the Emscripten linker, but that's not Rust's fault).

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 during development or after updating dependencies.

For me, the compile times are fine, and the end product generally doesn't need as much debugging as an interpreted language that requires no compilation at all, or has minimal validation, prior to running.

Re: Two years of Rust

#140

Post by lelandbatey »

I'm really excited by the new edition of the rust book mentioned in the post, from a brief look it seems that it covers all the areas I felt most needed improvement (for example what does a "move" mean?, a concept completely omitted from the first edition).

Also, I want to plug just how fun Rust is to write once you begin to learn how it works. It's totally awesome to write fast code that doesn't segfault, especially when it comes to things where tooling in other languages is lacking, such as doing parallel data processing. Speaking of which, I'll shamelessly plug some recent results from a Buddhabrot[0] renderer I wrote[1] in Rust:

http://lelandbatey.com/projects/buddhabrot/3k--mellowish-fra...

[0] - https://en.wikipedia.org/wiki/Buddhabrot

[1] - https://github.com/lelandbatey/rust_buddhabrot/

Post reply on HN