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

Rust 1.5

blog.rust-lang.org

Post reply on HN
Print view View original

91–100 of 159 posts

Re: Rust 1.5

#91

Post by nitrogen »

lambda wrote: post #67
Drdrdrq wrote: post #54

Earlier quoted context omitted.

One benefit: one could install latest version of Rust on any distribution. Debian stable for instance usually lags behind (with good reason, but still...). I imagine it is mostly useful for checking out Rust though, not for normal use.

The installer from https://www.rust-lang.org works fine on Debian stable. Right now, you can just use the upstream rustup.sh script for platforms that don't yet have it packaged (like Debian stable), or install from your distro for those that do (or use rustup.sh on those as well if you like). What I'm not seeing is the value of a Docker image. Rust doesn't have much in the way of runtime dependencies, which is where…

I'd attribute it to IMO bad devops habits encouraged by Docker. It's too easy in Docker to depend on someone's unofficial image ("FROM rustxyz" vs. "FROM debian + download deps + install rust"). Having official images would at least reduce the number of people building their infrastructure on unverified/unofficial images.

Re: Rust 1.5

#92

Post by issaria »

kbenson wrote: post #85
issaria wrote: post #79

Earlier quoted context omitted.

> . Period. This is not humour, this is aggressive.

You seem to think he is implying something about go. I'm pretty sure whatever you think is being communicated in the original comment was not the intention. Try asking for clarification rather than stating your interpretation of what someone said as fact. Try giving people the benefit of a doubt. To my eyes, the only one being aggressive here is you, when others are just trying to correct what appears to be your misi…

Well, for being someone from Go community and commenting in a Rust thread, your feeling that I misinterpreted the statement is legit.

But lets be honest, there are some attitude somewhere in the original comment, and I admire him being open.

Re: Rust 1.5

#93

Post by SamReidHughes »

dikaiosune wrote: post #89
lmm wrote: post #78

Earlier quoted context omitted.

Rust is immature in general. It will probably make a perfectly good language for web, comparable to e.g. OCaml, though the manual memory management is always going to add a little bit of overhead. IMO the web is a lot like anything else, and the best web languages are just the best general-purpose programming languages.

I haven't written a lot of Rust, but what manual memory management are you referring to? As far as I can tell, the whole point of the language is that you don't have to worry about that if you listen to the compiler.

You have to think about it. You don't have to worry about it.

Re: Rust 1.5

#94

Post by nitrogen »

issaria wrote: post #79
easytiger wrote: post #73

Earlier quoted context omitted.

It is called humour.

> . Period. This is not humour, this is aggressive.

> > . Period.

> This is not humour, this is aggressive.

In US English, at least, following a statement with "period" (I think UK's "full stop" is used similarly) indicates that the preceding statement is concrete and has few exceptions. It's not typically used to indicate aggression, unless spoken out loud with an aggressive tone.

Re: Rust 1.5

#95

Post by tangent128 »

rewqfdsa wrote: post #88
bajsejohannes wrote: post #58

Earlier quoted context omitted.

I would certainly welcome changing master/slave to leader/follower. It's no less clear, and it doesn't associate my software with something I'm deeply against. People might have different reactions to this thing so what's a stupid change to you might be a crucial change to someone else. (I agree that changing man is a little silly as it's obviously short for manual)

How about kill(2)? Why does the POSIX committee endorse murder?

"kill" as a term for the forcible cessation of life carries no baggage tying it to historical atrocities.

It can and is used to refer to deaths of stars, bacteria, plants, abstract concepts, and humans, without any connotation that these deaths carry equivalent moral weight.

genocide(2), on the other hand, would be in very poor taste.

Re: Rust 1.5

#96

Post by pzone »

dikaiosune wrote: post #89
lmm wrote: post #78

Earlier quoted context omitted.

Rust is immature in general. It will probably make a perfectly good language for web, comparable to e.g. OCaml, though the manual memory management is always going to add a little bit of overhead. IMO the web is a lot like anything else, and the best web languages are just the best general-purpose programming languages.

I haven't written a lot of Rust, but what manual memory management are you referring to? As far as I can tell, the whole point of the language is that you don't have to worry about that if you listen to the compiler.

It's sort of the opposite, it's that the compiler won't permit you to neglect any aspect of memory management until it deems your work passable. You think about memory management even more than you would in most languages. The result is you get some guarantees about correctness.

Re: Rust 1.5

#97

Post by ones_and_zeros »

lambda wrote: post #29
ones_and_zeros wrote: post #9

Earlier quoted context omitted.

Any plans to offer official Rust Docker images? Or is this it? https://hub.docker.com/r/jimmycuadra/rust/

What benefit would Docker images have over the existing upstream distribution or distro packaging? The Rust compiler doesn't have any particularly complicated dependencies, either installing the binaries directly from rust-lang.org or installing packages from your distro (if your distro has packages yet) should work fine. Container images are great for daemons with possibly complicated dependency sets that might have…

A few reasons:

- It is common for languages to have official Docker images (Java, Ruby, Python, Go, Erlang, Haskell, Julia, etc)

- In August the install process didn't work on my Debian system, eventually got guidance for workarounds from IRC

- Our build farm is docker based, application deployment environment is docker based

- Ensures development environments are identical

- Solves the multiple compiler issue

As much as I use Docker, it'd be tough for me to call it heavyweight. In terms of resource consumption Docker is just a neat wrapper over some functionality that is built in to the kernel, there is no "vm" of any sort, which is a common misconception.

Re: Rust 1.5

#98

Post by kbenson »

bajsejohannes wrote: post #58
kozukumi wrote: post #35

Earlier quoted context omitted.

I hope you are trolling. Would more women in tech be good? Of course! However there is some crazy SJW stuff going on at the moment in a lot of projects. People pushing for things like Master/Slave to be renamed to Leader/Follower. Wanting things like man (as in the man command on Linux) renamed to something non-gender-based. I mean fucking come on. I am all for a more inclusive environment but some things are just st…

I would certainly welcome changing master/slave to leader/follower. It's no less clear, and it doesn't associate my software with something I'm deeply against. People might have different reactions to this thing so what's a stupid change to you might be a crucial change to someone else. (I agree that changing man is a little silly as it's obviously short for manual)

I don't know, to me master/slave embodies teh relationship of the devices better than leader/follower, and also has less alternate meanings when viewed as a verb to confuse what is going on. Is the leader "out front"? Is the leader "first"? Is the follower doing the same thing, but delayed in some manner (which doesn't fit standby situations very well). A master controls. A slave is controlled.

Additionally, I think it's worth looking at the issue with a wider perspective. Slavery is bad, but really what most people in the west think of when thinking of slavery is racial slavery, which is a more recent issue (at least at scale), and is a much more pernicious problem,since it's not really slavery that was the base problem, but extreme racism. Historically slaves could be anyone, and as such it was much more acceptable to have people into and out of the ranks of slavery. Historical slavery is more akin to indentured servitude.

That said, I imagine with a few hundred years experience, assuming we can drastically reduce the still present racism we have in our societies, we might have an different response to the words master and slave, one more in line with historical context, and not the short but all to horrible period where it meant something worse. That's not to say it's good, just that we often use words that aren't pleasant in reality without thinking twice, such as steal, clobber, etc.

Re: Rust 1.5

#99

Post by ksherlock »

andyl wrote: post #38
rewqfdsa wrote: post #28

Earlier quoted context omitted.

Don't you have anything better to do than gender-troll? Like write some code, maybe? For god's sake, Rust goes out of its way to be modern and gender-inclusive. They have a god damn code of conduct, explicitly encourage participation from everyone, and actively seek contributors of all types. What the else should they fucking do? Posts like yours just demonstrate that you can never win by giving into SJW demands. No…

"Rust goes out of its way to be modern and gender-inclusive." And yet - epic fail. What is the reason?

Maybe someday we'll have enough datapoints for a meaningful study on whether having a code of conduct and being a SJW douchebag is effective.

Re: Rust 1.5

#100

Post by mahyarm »

moonchrome wrote: post #33
steveklabnik wrote: post #26

Earlier quoted context omitted.

There isn't a strong ETA, no. Everything about internals is basically waiting until after the HIR/MIR work lands, as it would end up changing a lot anyway, so that's where the focus is at the moment. That doesn't mean the _discussion_ about how it works has to stop in the meantime, though...

Well even a guesstimate would be nice :) I've been following Rust from sidelines before 1.0 and from my perspective there are advantages but I can also see a lot of pain in porting stuff and moving over and I right now the benefits don't outweigh the risk and cost for me - but having a fast build system (which implies incremental recompilation) along with a default package manager (which it already has) would be enou…

What would make you choose swift vs rust at this point? The compile speeds have been getting pretty close to objective-c levels, there is 1st and 3rd party package management and its been recently open sourced and is actually being developed in the open.

On top of that they have the financial backing of apple.

Post reply on HN