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

111–120 of 312 posts

Re: Two years of Rust

#111

Post by sqeaky »

goatlover wrote: post #97
brandur wrote: post #65

Earlier quoted context omitted.

> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto a…

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/

Re: Two years of Rust

#112

Post by eridius »

mmstick wrote: post #107
eridius wrote: post #94

Earlier quoted context omitted.

> It's not in my interest to request for Brotli support in products that I do not use. You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really…

> You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really don't care about software you don't use, then why are you so dead set against servin…

> 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 do not support non-SSL HTTP connections.

Why do you keep repeating this? That's completely irrelevant to the discussion at hand. Nothing about this discussion has anything to do with whether or not the HTTP protocol is wrapped in SSL.

> Naturally. I would prefer to not have anyone using these tools on my server.

So, you want a web site that completely breaks HTTP such that only works with a handful of browsers and doesn't work with the probably tens or hundreds of thousands of pieces of other software that speaks HTTP.

Why?

Re: Two years of Rust

#113

Post by eridius »

mmstick wrote: post #104
eridius wrote: post #90

Earlier quoted context omitted.

From your last paragraph I question whether you really understand anything you're being told here. Yes, I said HTTP instead of HTTPS, but that wasn't meant to signify that I was using unsecured HTTP, since HTTPS is supported virtually everywhere and generally understood to be a part of HTTP. More specifically, if I actually try and access http://mmstick.tk , I just get redirected to https://mmstick.tk anyway, without…

I'm not sure where your confusion is. It doesn't matter that HTTPS is an encrypted form of HTTP. I do not support HTTP, which means that I do not support HTTP without encryption! End of story. Attempting to access the site via HTTP will merely redirect you to the HTTPS service. Nothing is being hosted on the HTTP service. When you reach the HTTPS service, your browser will receive a HSTS header that will cause your w…

Your use of HTTPS is completely irrelevant here, but I've already addressed that in the other thread (https://news.ycombinator.com/item?id=14345695).

> You cannot use Brotli compression over HTTP.

This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Brotli-encoded response over unsecured HTTP.

My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.

Re: Two years of Rust

#114

Post by brandur »

lacampbell wrote: post #106
brandur wrote: post #65

Earlier quoted context omitted.

> It's beginning to get tiresome to continually hear the Rust community go on and on about how amazing Rust is and say, with a straight face, that eventually there will be no reason to write anything in not-Rust. Are you serious? The hubris is off the charts. So a few considerations here: (1) I really have no connection with the Rust community aside from curiosity, so it's quite dishonest to project my opinion onto a…

Having so few constraints on implementation (e.g. duck typing) was an interesting concept, but time has proven it to be a nightmare maintainability. Citation needed. Just because static typing is has been more fashionable for the past 10 years, doesn't mean it's a closed case. Before that people were extolling the virtues of dynamic languages. Some people deciding they prefer static typing doesn't constitute some kin…

Yes, I can't prove it. There's no quantitative way of doing so.

I've worked with very big duck typed codebases for quite a few years now (and largely statically typed in C# before that) and the above is my opinion. Duck typing is convenient early on, but it makes understanding code (especially where it gets complicated or you didn't write it) quite difficult, and any kind of refactoring downright scary. After a point you (1) start getting hugely defensive with tests because without close to 100% coverage you just can't know if anything works, and (2) stop making big changes and instead accept that small incremental deployments towards a greater end is the only safe way towards making progress.

I suspect that how much you agree with this statement is strongly correlated to the size of your codebase. I'd be surprised to meet people with codebases on the order of 100k lines or greater that don't largely share this sentiment.

Re: Two years of Rust

#115

Post by arwhatever »

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!

Rust is a simple, intuitive language that just gets out of my way and lets me focus on solving the problem at hand.

Re: Two years of Rust

#116

Post by derefr »

sillysaurus3 wrote: post #49
zzalpha wrote: post #43

Earlier quoted context omitted.

If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least . I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn…

I tend to agree, but being able to have a REPL at all is a symptom that your language is capable of an extremely fast compile-run-debug cycle. In other words, if you can't implement a REPL, that's the definition of "less productive language." It's not about the REPL itself but the capability of implementing one. Think about it like this: On your list of languages, which of them would you say is most productive? It de…

Why must productivity be measured in "smallest amount of time to write your feature"? Why not in "smallest Total Cost of Ownership [in man-hours] of the feature over the project lifecycle"?

Some projects are written as explorational prototypes or MVPs. I don't think anyone is saying Rust is much good for those.

But (numerous) other projects are written as "the first real Quality implementation of [well-known problem], using a decade's experience with other implementations." Much of the common software we use—{server daemons (HTTP, SSH, DNS...), parsers and encoding libraries (for XML or JSON; JPEG or PNG; MP4 or MKV...), databases, load-balancers, distributed queues, ...}—fits this paradigm.

If you're writing Nginx, or Redis, or djbdns, you aren't "adding features" out of some agile user-story kanban; you're carefully implementing a small, curated set of well-known, well-understood features, with much research done to ensure that you arrive at the best and least fraught implementation, the one that will make people prefer your software for its quality and reliability and set-and-forget nature.

Rust is for that kind of software. (Which makes sense, given that Mozilla's Servo rendering engine also has the goal of being that kind of software.)

Re: Two years of Rust

#117

Post by steveklabnik »

lacampbell wrote: post #103
tatterdemalion wrote: post #63

Earlier quoted context omitted.

> Is the Rust community claiming that the entire history of computing has lead up to this point, where Rust exists, and now nobody needs to write anything in not-Rust? Are people 200 years from now going to write Rust and nothing else? Let's be clear - the person who said there'd be no reason to write in anything else is an enthusiastic Rust user, but they don't work on Rust & don't represent "the Rust community." Th…

I'm no compiler writer, but presumably rust has some form of internal IR it compiles to before it gets turned into LLVM IR. Why not just write an interpreter for that layer and be done with it? The point of a REPL to me is to be responsive, not to run code amazingly quickly.

"Miri" is named such because Rust's IR here is called MIR.

It's a relatively recent addition though.

Re: Two years of Rust

#118

Post by nercury »

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.

Re: Two years of Rust

#119

Post by steveklabnik »

marcosdumay wrote: post #96
arianvanp wrote: post #59

Earlier quoted context omitted.

Do notation makes this stuff a whole lot more readable (See Haskell). Or Async-await (See C#)

About do notation, can't Rust get something similar with macros? (I still didn't get to making macros in it.)

There is a crate that does it in a duck-typed manner. It's not clear that the stronger typed version can work. We'll see.

Re: Two years of Rust

#120

Post by zzalpha »

derefr wrote: post #99
zzalpha wrote: post #43

Earlier quoted context omitted.

If your language doesn't have a REPL, your language is less productive. Deal with it. Oh hardly. As someone who's developed software in Perl, Python, C, Java, C#, Haskell, and a few others besides, a REPL is the one thing I use the least . I've honestly never understood the obsession with it. Is a rapid compile-run-debug cycle important? Absolutely. If I want to test something in isolation, being able to rapidly turn…

> 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 understand the machinery.

Other languages (like Haskell) may not have the IDE support but attempt to solve the problem with auto-generated docs so you can at least see the surface area of the API and can start prodding it.

Post reply on HN