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

Rewrite Everything in Rust

robert.ocallahan.org

Post reply on HN
Print view View original

221–230 of 242 posts

Re: Rewrite Everything in Rust

#221

Post by alexnewman »

wspeirs wrote: post #35
justinmk wrote: post #27

Earlier quoted context omitted.

This is why I personally think the OSS community should be more encouraging of "salary" style funding. There is a loud, poisonous minority of advocates that seem to think that asking for money is just plain evil. That attitude is a material disservice to OSS in general: it makes OSS weaker and less capable, for the sake of some weird puritan reflex. N.B.: I have never and will never ask for, nor accept any income fro…

Do people think companies would pay for a closed-source glibc if it were shown to be 100% compatible with the current glibc, but written in Rust?

no

Re: Rewrite Everything in Rust

#222

Post by JelteF »

rspeer wrote: post #121
make3 wrote: post #106

Earlier quoted context omitted.

I don't know that people don't choose C++ for performance reasons or for easy manipulation of low level stuff. Games, high performance computing, embedded and legacy software are the main applications of C++, aren't they? Some people on this website seem to blow the python 2/3 transition fairly out of proporotions.. Python 3 is really extremely similar to Python 2, and there are great tools to convert Python 2 code t…

Is there a great tool to convert Python 3 to Python 2? I've tried Pasteurize (part of python-future) but it just leaves the "yield from" statements in place, giving syntax errors. And 3to2 does even less, and seems to mostly be a framework for building tools like Pasteurize. I know this isn't easy, but JavaScript people do it with ES6 transpilers, and ES6 is more different from ES5 than Python 3 is from Python 2.

The two libraries I've created both use a combination of 3to2 and pasteurize to convert the python 3 code to python 2. The only issues I've run into are new error types that I could not use. But there seem to be quite some issues open: https://bitbucket.org/amentajo/lib3to2/issues?status=new&sta...

In case you want to see the scripts I use to change the python3 code to python 2 and make it work with pip:

https://github.com/JelteF/PyLaTeX/blob/master/convert_to_py2...

https://github.com/JelteF/PyLaTeX/blob/master/setup.py

Re: Rewrite Everything in Rust

#224

Post by daurnimator »

kibwen wrote: post #169
daurnimator wrote: post #141

Earlier quoted context omitted.

Rust's OOM handler calls abort(). This kills the process, and cannot be caught. i.e. to run rust code that uses the standard library without the chance of abort() on low memory, you need to run it in it's own process.

> you need to run it in it's own process Assuming that you can detect OOM in userspace at all, which usually isn't the case on Linux (or any other system with overcommit).

huh? you'd notice your child process was exited with SIGABRT.

Re: Rewrite Everything in Rust

#226

Post by gnu »

Manishearth wrote: post #211
gnu wrote: post #201

Earlier quoted context omitted.

Great. They all look great. The ones like higher kinded types are the ones that I am highly suspicious of. The typical C programmer who pokes around hardware data sheets and writes drivers and stuff will likely not pay much attention to Rust if such complex features are added. Also features like that makes me wonder if you folks are really targeting C/System programmers. Sorry if I sound negative, that isn't my inten…

Systems programming does not preclude a language from having a good type system or higher level abstractions. A good example is Phil's OS. http://os.phil-opp.com/ . He's designing an operating system in Rust, and it has surprisingly few "unsafe" parts. The rest of it is made safe using some neat zero-cost abstractions. Higher kinded types isn't going to happen anytime soon. It's something that crops up often in discu…

> Systems programming does not preclude a language from having a good type system or higher level abstractions.

I didn't say that system programming does not need a good type system. I am also not saying that it is impossible to design operating system software with Rust.

As someone who had been on both the sides of the abstraction and having closely interacted with the system programmers, I think it is just too hard to convince them to use Rust. It is not just about the language alone, it is about what minimum you need to bootstrap a system (among many other things).

Anyway.. good luck to the OP in "rewriting everything in rust" and also getting it to the same quality/feature parity as others in the game and also get others to use it as well.

Re: Rewrite Everything in Rust

#227

Post by Manishearth »

gnu wrote: post #226
Manishearth wrote: post #211

Earlier quoted context omitted.

Systems programming does not preclude a language from having a good type system or higher level abstractions. A good example is Phil's OS. http://os.phil-opp.com/ . He's designing an operating system in Rust, and it has surprisingly few "unsafe" parts. The rest of it is made safe using some neat zero-cost abstractions. Higher kinded types isn't going to happen anytime soon. It's something that crops up often in discu…

> Systems programming does not preclude a language from having a good type system or higher level abstractions. I didn't say that system programming does not need a good type system. I am also not saying that it is impossible to design operating system software with Rust. As someone who had been on both the sides of the abstraction and having closely interacted with the system programmers, I think it is just too hard…

> does not need a good type system

Yeah, I'm just saying that "higher kinded types" (which, again, Rust isn't getting anytime soon), does not make Rust something that isn't targeting systems programming; in response to "you folks are really targeting C/System programmers".

Many of Rust's designers are experienced systems programmers. A _lot_ of effort goes into making it systems-ready.

> it is about what minimum you need to bootstrap a system

Rust works on any target LLVM compiles to, and you can opt out of the standard library if you're writing baremetal things. There already are people writing low level Rust things.

But yeah, I know the skepticism you refer to; seen it in action before. But in the case of Rust I've rarely seen any concrete points being brought out (aside from perhaps "LLVM doesn't target enough things", which is fair). The language developers do try to take input from everyone and make it more systems ready; but there really isn't much that can be done when there isn't any input other than a strong preference for C.

Re: Rewrite Everything in Rust

#228

Post by dpc_pw »

pjmlp wrote: post #129

How I wish people understood this when we were comparing Ada, Modula-2, Modula-2+, Modula-3, Pascal dialects, Oberon, Oberon-2, Active Oberon, Component Pascal,... to C. Apparently we were the fools. But this will never happen in UNIX OSes. The culture is married to C, regardless how many memory corruption exploits per days might get a CVE entry. However I hope to be proven wrong.

The syntax is killing these languages. Sure it's superficial, but programmers are human beings and I doubt most people find it appealing to voluntary stare at and type PROCEDURE BEGIN END and other LONGCAPITALIZEDWORDS...

Re: Rewrite Everything in Rust

#229

Post by dpc_pw »

wangchow wrote: post #73

Just gonna throw this out there: what if instead of working on creating the myriad of "better languages" we focus on actual mastery of simpler languages like C. And with that mastery: what about writing some machine-learning software that detects vulnerabilities as part of the build/release cycle. For instance: http://news.mit.edu/2016/faster-automatic-bug-repair-code-er... To detect vulnerabilities people need to be…

Mastering C over using Rust is like mastering abacus, over using computer.

Re: Rewrite Everything in Rust

#230

Post by pjmlp »

dpc_pw wrote: post #228
pjmlp wrote: post #129

How I wish people understood this when we were comparing Ada, Modula-2, Modula-2+, Modula-3, Pascal dialects, Oberon, Oberon-2, Active Oberon, Component Pascal,... to C. Apparently we were the fools. But this will never happen in UNIX OSes. The culture is married to C, regardless how many memory corruption exploits per days might get a CVE entry. However I hope to be proven wrong.

The syntax is killing these languages. Sure it's superficial, but programmers are human beings and I doubt most people find it appealing to voluntary stare at and type PROCEDURE BEGIN END and other LONGCAPITALIZEDWORDS...

Most programmer friendly editors for those languages supported formatting as you type, gofmt isn't the first of its kind.

Also it makes very easy to recognize reserved keywords.

Post reply on HN