News for hackers. Stuff that matters.
Re:Dovecot audit complete by vetinari on Monday January 16, 2017 @07:17AM (#13409557)
There's currently going a discussion, whether Rust is ready yet for such a project. See http://esr.ibiblio.org/?p=7303
Re:Dovecot audit complete by uiri on Monday January 16, 2017 @10:47AM (#13410583)
ESR claims: But you guys have competition out there: Go, Nim, Swift, D, and maybe other languages that aren’t on anyone’s radar yet.

All those languages are garbage collected or use automatic reference counting. Rust is unique in using its type system to automatically allocate and free memory. For the use cases where the overhead of GC is too high - Wich are the same use cases that generally call for C or C++ these days - Rust has no competition. I think this explains why Rust is still in the explore phase.

Re:Dovecot audit complete by noselasd on Monday January 16, 2017 @01:32PM (#13411867)
Having a garbage collector is no showstopper for writing an email server though.
Re:Dovecot audit complete by nickpsecurity on Monday January 16, 2017 @12:31PM (#13411406)
That claim gets even stronger if one considers real-time GC's or ref counting. Like how they do with Java for embedded systems. The places where Rust is uniquely advantageous gets smaller.
Re:Dovecot audit complete by lobster_johnson on Monday January 16, 2017 @01:59PM (#13412029)
HN thread: https://news.ycombinator.com/item?id=13398068

It's hard to take Eric S. Raymond seriously. He starts by claiming to be responsible for the open source development model, continues to make some generic remarks about library quality that applies equally to many other established languages (including C), then has the gall to offer advice to the designers of a language that he is openly struggling with [1].

His arguments aren't all wrong, but it's weirdly presumptious to level them so unequivocally at a new language/community that is still finding its feet and whose adoption rate hasn't even reached the point where you can talk about library curation/fragmentation being a huge problem. One has to give Rust some slack just for being young and immature.

You also have to give Rust some slack for just being more different and complicated than the languages you are used to. If you read his previous post about Rust, it's clear that he's blaming Rust for his inability to grapple with its fairly advanced concepts, and his complaints mostly amount to knee-jerk reactions, not carefully reasoned criticisms.

While it's true that Rust doesn't offer a learning experience that's as friendly as Go, by far, Go has the benefit of having a head start of several years, a larger organization funding its development, and of being a much, much simpler language. Based on his skill level, it sounds like Go would be a better fit for him. (I use Go myself and see a huge benefit being that it's easy to learn for any developer, not just highly experienced ones.)

[1] http://esr.ibiblio.org/?p=7294

Re:Dovecot audit complete by msbarnett on Monday January 16, 2017 @01:39PM (#13411909)
"Discussion" isn't the word I'd use to describe that mess.

Criticizing a low-level language that makes it cheap and easy to directly call C APIs directly for not providing special syntax for select/kqueue/epoll when he could just call epoll if that's what he wants makes it clear that he wants to be writing some other, higher level language entirely.

It tells us nothing interesting about whether or not Dovecot, a project that wants low-level direct binding to POSIX APIs, is not suited for Rust.