Ask HN: Will Rust ever become a mainstream systems programming language? - <AUTHOR> <comment><USER2> I work for Faraday (.io, not the car folks), and we use Rust in production. I personally suspect that Rust will continue to grow in popularity.

We've been really happy with Rust. Our Rust programs tend to be fast and resource efficient, and they tend to have few bugs (and most of those are cases of misunderstanding the problem or the spec).

The learning curve tends to be pretty rough for the first week or two, but you can reduce that by pairing with a more experienced Rust developer. And after that, it's pretty smooth sailing. Certainly any C++ programmer should be able to make the leap fairly quickly--it helps to have used at least one non-GCed language.

The third party library situation is better than you might think for a young language (the database clients, RabbitMQ clients, HTTP clients, compression, etc., are all basically usable), but I normally expect to fill one or two library gaps per project.

Overall, I find it difficult to articulate why I like Rust. It's pleasant to write (now that I know how), it runs fast, the CLI tools are pretty solid, and has enough abstractions to keep the boilerplate in check. And I can throw cluster-sized workloads at it and trust it to work, and work fast.

<comment><USER3> Trying to articulate why I like it: it marries the low-level control and type safety from C++ to modern language features as found in Python/Ruby etc, and in doing so manages to hit a pretty sweet spot in terms of having the compiler finding actual bugs early. With enums and pattern matching and the borrow checker, there are a bunch of features that help make the type system expressive enough that you can generally express what you need and still allow the compiler to perform very thorough, important checking on it, with the effect that "it compiles -> it works" is true much more than for, for example, C++.

<comment><USER4> I agree and would add one more property that makes Rust likable - it's about two years old, so still a greenfield language and standard library. It's easy to overlook that.

</comment></comment></comment><comment><USER5> Whatever the answer is, you probably will not find it here. From an historical perspective, the success a language seems to have very little correlation with the vague notions of quality that we language geeks think are important. And it seems that the HN echo chamber forgets that.

</comment><comment><USER6> Rust has to stand the _true_ test of time -- the test where 5-10 years-old codebases written in Rust are still being maintained. Someone who's literate in programming language _theory_ can evaluate the design decisions in Rust and say "it looks good" (or not), but in order to determine whether Rust is actually good for building and maintaining large, complex software systems for long periods of time, there's no metric like really doing it.

I think at some point, Rust will have enough tooling that people will try to start using it for graphics and videogames -- the applications where C and C++ shine but their "safer" rivals Fortran and Ada can be a headache to work with. It's in this arena -- where Go is too slow -- that Rust will really sink or swim. And it has barely even started to make headway. Maybe GNOME 5 will be written in Rust, or maybe the GNOME 5 developers will try Rust and conclude it's not suitable. Whoever they are, they haven't even started yet.

<comment><USER7> > _I think at some point, Rust will have enough tooling that people will try > to start using it for graphics and videogames_

The game developer community is actually one of the communities that jumped onto Rust really early, well before it hit 1.0.

<comment><USER8> You mean hobbyist ? All the AAA games are still written in C++, none of the big studios is even considering to switch. Rust type system/restrictions would get into the way more than it would help in AAA game dev. Memory safety is not a problem in game development, they will just patch the bugs. Studios have whole ecosystems written in C++ that works for them. Benefits are really low compared to costs, that's why it's unlikely any major studio will switch any time soon.

<comment><USER9> Type restrictions aren't really a problem, but in fact really helps out game development in the long run.

> Memory safety is not a problem in game development, they will just patch the > bugs.

You must not have played any Bethesda titles. That said, there is much more to Rust than memory safety. That's just a side effect of the safe parallelism -- it's a minor story.

<comment><USER10> This is nonsense. I would love to use Rust in games (I currently work in games) but it's not clear that it would work out. That opinion is shared by game developers far more experienced and prominent than myself.

I (and I presume many others) would appreciate it if you would stop making grand, unfounded assertions about what Rust is good for. Games _do_ make very different tradeoffs from most software- type and memory safety aren't an obvious, uncontested win there.

<comment><USER9> There's already a few games written in Rust on Steam's Greenlight program. SHAR was even greenlit. Stating that it isn't clear that it would work out is basically stating that you are choosing to ignore that it has and is being done successfully.

> stop making grand, unfounded assertions about what Rust is good for

You are basically stating that everything that I have done in Rust is a lie. I will not stand for that.

<comment><USER10> There are vast gulfs between Steam Greenlight candidates and AAA.

Nobody here, least of all me, has claimed that Rust cannot be used for any game at all, nor have they disputed your own experiences. Grow up.

<comment><USER9> You clearly don't read what you write.

> I would love to use Rust in games (I currently work in games) but it's not > clear that it would work out.

There are many contradictions in your posts on here.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I had great hopes for Rust as the future of systems programming, but they've decreased over time. Parts of the language are just too cute.

The borrow checker was brilliant. Any future language that doesn't use garbage collection will have to have one. That was the big advance in Rust.

But the object system (yeah, they're called structures and traits) is too weird. The enum approach to variant records is too weird. The error handling is too weird. The half-functional style is too weird. The widespread use of closures for simple stuff is too weird. There's too much unnecessary originality. Trying to port something from another language to Rust is difficult because Rust's ways of doing things are so different from other languages.

I have the feeling that Rust is destined for a niche like Haskell - cool, but not mainstream. That's sad. I really thought early on that Rust meant the end of the decades of hell from the lack of memory safety in C and C++. But that's not happening.

The Go crowd knew when to stop. The Rust crowd didn't.

<comment><USER12> > But the object system (yeah, they're called structures and traits) is too > weird.

So you praise Go for having structures and interfaces, but you criticize Rust for having structures and interfaces because that's "too weird".

> The enum approach to variant records is too weird.

Why? Because of the keyword? Swift uses that keyword too!

> The error handling is too weird.

What would you rather see?

> The half-functional style is too weird.

I can't think of any way that Rust differs in this regard from, say, Ruby. Or JavaScript.

> The widespread use of closures for simple stuff is too weird.

Again, it doesn't differ from Ruby. (Actually, Rust uses closures/blocks quite a bit less than Ruby does, because of the pull-style iterators...)

> There's too much unnecessary originality.

Such as? None of the features you've mentioned are at all original.

<comment><USER5> >> The error handling is too weird.

>What would you rather see? Exceptions

<comment><USER12> We would lose lots of users from C and C++ if we mandated exceptions for error handling. The code size and complexity of unwinding is too much of a price for many to pay.

<comment><USER5> Not mandate them , use have them as an options where the monadic Errors types are not enough or are too cumbersome to use.

<comment><USER12> And thereby prevent people from writing code that needs to catch errors but can't use exceptions. Won't work.

<comment><USER5> I don't understand what that sentence means...

<comment><USER13> Some people don't want to use exceptions because of runtime overhead costs.

If exceptions are just "an option" that a library can choose when designing its interface, then you'll get a split ecosystem: a bunch of libraries that _do_ use exceptions for error-handling, and then a separate bunch of libraries that do the same thing, but _don 't_ use exceptions for error handling, which is wasted, redundant effort.

<comment><USER14> > then you'll get a split ecosystem

Agreed. Point in case: Have a look at D and the discussions about their GC.

I haven't kept up much about the last year, but my general impression runs down to: If you want to use their standard library. There's gonna be garbage collection. Period. If you want to avoid it, enjoy implementing its functionality all by yourself.

With rust and exceptions you would likely not have a problem with the main ecosystem, but the same problem is bound to pop up with _some_ big & famous library.

Edit: Similarly, exceptions are one of the reasons C++'s SG14 exists.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> The Rust ecosystem has lost sight of the forest for the trees in my opinion. I highly agree with Graydon's opinion in "Rust is mostly safety" [1] that it's raison d'être is memory safety and concurrency in the systems space. But strangely a significant amount of time is being put in to making it usable for other tasks. I think this has to do with the different cultures between C/C++ developers versus other developers, namely that developers coming from web development are younger and more used to jumping around to new languages and frameworks.

With it's borrowing semantics and steep learning curve, Rust will never gain significant market share in the world of web development. And why should it? Time to market matters more than speed. It's much easier to ramp up new hires on a C# or Go code base than on a Rust one. And the borrow checker will always create friction for people new to the language. As someone with a C++ background, it still took me over a month before I stopped fighting with the borrow checker and with lifetimes. I can't imagine how long it would take to get a completely new programmer up to speed.

[1] [http://graydon2.dreamwidth.org/247406.html](http://graydon2.dreamwidth.org/247406.html)

<comment><USER9> Web developers have zero issues with using Rust for web development though. The Rocket web framework is rather intuitive. I even built my website entirely in Rust with it.

[http://mmstick.tk](http://mmstick.tk)

<comment><USER16> "zero issues" is a bridge too far. Rocket, for example, only works on nightly Rust, and that might be a non-starter for a lot of people.

<comment><USER17> This has been my biggest issue trying to learn rust, there are too many projects that only support the bleeding edge.

<comment><USER16> Rocket is one big one. Just recently though, serde and diesel started working well on stable Rust. Other than that, unless you're doing embedded stuff or SIMD, you should be fine on stable.

Unfortunately, Rocket does not appear to be on track to work on stable Rust for the foreseeable future.

<comment><USER17> I was hoping with serde being on stable things would settle down. What's keeping rocket on nightlies?

<comment><USER18> Lots of things: [https://github.com/SergioBenitez/Rocket/issues/19](https://github.com/SergioBenitez/Rocket/issues/19)

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> I want to believe. I love Rust. I feel like Rust is the language I've waited for all my life.

Yesterday there was a story about Rust here on HN: "Programming ARM Cortex-M Microcontrollers with Rust." Among the replies was a complaint; someone couldn't figure out how to write a static buffer and was discouraged. Someone else provided an example of how to do this. Finally, another person noted how unfortunate the solution was. Here is the code, reworked by me just a little:

        use std::io::Write;
        use std::str::from_utf8_unchecked;

        static mut S1: [u8; 17] = [0; 17];

        fn main() {
            unsafe {
                write!(&mut S1[..], "Hi: {}", 5).unwrap();
                println!("string: {}", from_utf8_unchecked(&S1[..5]));
            }
        }

There are three distinct reasons why everything has to be "unsafe." Unless you have a lot of experience with Rust you are NOT going to figure that out until you've banged your head against the compiler for some time doing your level best to minimize the lines of code you've wrapped in unsafe, and then finally surrender.

That is a lot of friction. I know (as in I understand with precision) the reasons for this and they're entirely legitimate. But damn... the pain is just more than the bulk of the world is ever going to tolerate. You can do the same task with zero friction in C/C++ and go fast/be small, or you can do it with a "managed" language with zero friction and handwave at the bloat and cycle eating cache killing GC, or you can don the hair shirt, focus on your breathing to keep the panic at bay and use Rust.

It is inescapable human nature that the "mainstream" will avoid the latter.

<comment><USER20> I think you noted one of the problems Rust is going to have with adoption: its raison d'être is solving technical debt (specifically, security debt).

Unfortunately, the reason that's a problem is because most management doesn't even know what it means. And that's not likely to change.

So saying "We have a language that might take a bit longer but solves X" is a difficult conversation when the reply is "Wait, what is X?"

</comment></comment><comment><USER21> It does keep rising in popularity, but is that coming from folks actually using system languages like C, C++, Ada, and Forth? I'm guessing only a portion. There's a difference between a web developer using Rust enthusiastically for hobby projects and a seasoned C coder switching to Rust for a professional job. In fact, a lot of the projects I've seen in Rust (ex: Dropbox) are commonly being done in Go as long as the GC isn't an issue.

<comment><USER22> Rust is the first language since C++ that can improve/not hinder runtime speed while making development safer, so I definately see its future.

The only problem is that the compiler is very slow now, so it doesn't scale to large code bases, which is a no-go in my company. Hopefully the Rust team understands that this is not only a would-be-nice to have feature (I see learning the borrow checker as a smaller problem)

<comment><USER23> > The only problem is that the compiler is very slow now, so it doesn't scale > to large code bases

The way of working with that is use cargo check command which is much faster and splitting your problem into multiple crates so you don't have everything in one giant project. Which is what tends to happen in large code bases anyway.

Also they are putting quite a lot of work into making it faster. Before you get to that large code base it will be better.

<comment><USER22> While your suggestions work at some companies, it's not a good solution for every company:

[https://www.wired.com/2015/09/google-2-billion-lines- codeand...](https://www.wired.com/2015/09/google-2-billion-lines-codeand-one- place/)

<comment><USER23> A single repo can have lots of crates

</comment></comment></comment></comment></comment><comment><USER24> Most C++ developers won't easily develop systems in Rust because of lack of well-known libraries and a stable ecosystem(profilers, static analyzers, concurrency tools, many skilled and mediocre developers, etc). C++11 and subsequent versions have a good amount of memory safety(though not as safe as Rust).

Rust is a modern language with very good concepts and features. It's quite complicated to learn.

My answer is it will be a good language, but won't be a top language.

<comment><USER25> Like... Cobol... 'cause all those reasons are vanishing and will vanish.

<comment><USER24> Those who need Cobol use them(Core banking applications).

Rust is better than C++, but it's not extremely better than C++.

<comment><USER25> Extremely safer seems to me to be extremely better, these days.

</comment></comment></comment></comment><comment><USER26> System76 is using Rust now for automated testing and firmware flashing. I wrote these projects in rust, and I enjoy using it, can't say much about the other engineers.

<comment><USER27> Also, Redox OS is awesome :-)

<comment><USER26> Thanks ;-)

</comment></comment></comment><comment><USER28> My feeling is that Rust (and/or Go) will probably supplant Java (and/or C#) in the coming age, just on the basis of the user experience alone. This past week I wasted several hours trying, and failing, to get a simple Java app up and running. Rust (and Go) have such a better end user experience that I can't see them not winning. Firing up a single executable is miles better than installing a run time, then tweaking the config to make it work, then trying to find out where it stores log files, then tweaking it again when it fills up memory, etc.

Give me a single, self contained, executable any day!

</comment><comment><USER29> I think it's important to consider the implications if Rust _doesn 't_ become a mainstream programming language.

I'm not shy about my dislike of Rust. I like C, I don't think avoiding buffer overflows and memory errors is that hard, and I chafe at the idea of a language I dislike aesthetically taking over systems programming.

But even I have to admit the arguments for using C instead of Rust are niche. Sure there's probably always going to be some instance where C makes sense technically, but if we could wave a wand and convert the world's C/C++ code to Rust, we'd immediately fix millions of memory errors and data races. It's impossible to overstate that benefit.

Think of the things the Rust team has to deal with:

"Is Rust a good web language?"

Is C or C++? Is Ocaml?

"Is Rust a good language for an OS?"

Is Python? Is JavaScript?

"Is Rust too big?"

Is C# or Java? Rust is a pretty small language, both in terms of features and implementation size.

"Is Rust powerful enough?"

Is Go? Go deals with this all the time ("Go ignores decades of PL research"). Rust's feature set is pretty good, but more importantly it's well thought out.

"Is Rust fast enough?"

Is Java? Is C#? Is Go?

"Does Rust compile fast enough?"

Does C++? Does Clojure?

"Will your Rust program be memory safe and free of data races?"

It sure will be. This is a monumental achievement. Your options for a memory- safe language without GC are... Rust and Ada?

"Does Rust have a good concurrency/parallelism story?"

Rust has one of the best, actually. It doesn't use segmented stacks so it doesn't achieve the M:N performance of Go, but it has memory and data race safety, OS threads, and futures, so no problem.

"Is Rust too hard?"

Honestly, programming is hard, other languages just let you ignore it. There's an example about manipulating a string as a global array in this thread somewhere, which is not really something you should do, and the argument was "this was wildly difficult". It is, yeah, because safely managing concurrent access to a global, bounded section of memory is wildly difficult.

Again, I'm not a Rust fan and I sort of can't believe I'm writing this. But look at what Rust has:

\- memory and data race safety

\- scripting language ergonomics (after you internalize the borrow checker)

\- the speed and memory usage of C

\- a low surface area

\- advanced features

\- great community outreach and documentation

\- familiar structure (as opposed to something like Erlang or Haskell)

If a language like that doesn't succeed, you have to start wondering what will.

My personal belief is that it is succeeding, but I think success looks a lot different than most expect: new projects that need a systems language are far more likely to be written in Rust than in C/C++.

<comment><USER30> > It doesn't use segmented stacks so it doesn't achieve the M:N performance of > Go

Actually, if you use Tokio or similar approach, you achieve better performance than Go (no need to re-allocate stacks) while code is still quite readable and boilerplate-free.

<comment><USER10> They seem to be aware: ", but it has memory and data race safety, OS threads, and futures, so no problem."

However, futures are certainly not boilerplate-free. They destroy your ability to use native control flow the way you can with threads (M:N or 1:1). You can get some of that back with async/await, but Rust doesn't have that and it's still not boilerplate-free.

</comment></comment></comment><comment><USER31> If "functions as a service" (AWS Lambda) takes hold, I think Rust will be a popular server language since you'll need services with almost no startup/warmup time.

</comment><comment><USER32> I would say so far, yes. I would say it's pretty "mainstream" already with many companies using it in production, including Mozilla.

As big as C++/C? Too early to tell for that.

<comment><USER33> Also anyone big besides mozilla, who created it?

<comment><USER16> Microsoft in VS Code: [https://code.visualstudio.com/updates/v1_11#_text- search-imp...](https://code.visualstudio.com/updates/v1_11#_text-search- improvements)

/plug :-)

<comment><USER17> I don't think that counts. I'm not using c when I run grep.

<comment><USER16> They are shipping ripgrep with VS code.

<comment><USER17> But shipping a program using rust != using rust. If that was the case I've used Erlang despite never having written a single line of it because I've shipped rabbitmq.

<comment><USER16> This is a strange argument I find myself in. What do you expect me to say? They're shipping a Rust application I wrote. That's a fact. Do with it what you will.

<comment><USER8> No, it's not strange. What you wrote can be interpreted as manipulation. It's the same as replying to question "Who uses Go besides Google?" And you would reply that almost everyone use it, because everyone is shipping their apps with Docker. You see manipulation here? I don't know if intentionally or not but you did exactly the same.

<comment><USER34> FWIW, a common argument in favour of C and C++ is how it is used by pretty much everything that one runs on a computer, in exactly the same sense of "use". I think you're tilting at windmills: some people mean "use" to mean "ship" and others "write", and neither are that unreasonable.

<comment><USER8> I wasn't the first one that made that claim. And I don't know the author of the comment that made it and I am not involved with anything that author do - something you can't say yourself in context of person you are defending. I've asked couple of people about that question without suggesting the answer and all of them agree with interpretation that it's about writing software in language A, not using third party tools written in language A.

Example of usage outside of company like in question from arstechnica:

"Outside of Google, companies like Wrike, Workiva, Blossom and others have also been using Dart to develop their products, so there is definitely still a Dart user community outside of Google, too."

This is how everyone interpret that question.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER35> Not too sure what is meant by "mainstream" but I can see Rust getting a foothold in certain industry, such as medical, automotive or aerospace. To get there, it will need to be mature and be stable significant enough. It will also need a big player to take that first step and prove it in production.

Imagine if Ford mandates its suppliers to use Rust for the software in its car and it faced little problems after a few years out on the road.

<comment><USER36> I'm an aviation enthusiast and a CS undergrad. I've always wondered what's different about code written for airplanes. Anybody have any insight ? And is there a modern replacement for ADA?

<comment><USER6> Ada is still under active development and widely used in applications requiring extremely reliable software.

[http://www.ada2012.org/](http://www.ada2012.org/)

<comment><USER37> I've used Ada on satellite programs, it's still very popular for that sort of thing. Ada has managed to carve out a small niche for itself in aerospace and I don't think it'll be replaced by rust anytime soon.

Which is fine, nothing wrong with Ada.

</comment></comment></comment></comment><comment><USER38> I would say unlikely, for the simple reason that Rust is just really _hard_.

<comment><USER39> C++ is hard, too. So is C, to write correctly. Hasn't stopped either of them from literally powering almost every computer in use.

Rust's complexity is equivalent to, but distinct from C++'s. I prefer it over C++, and I'm one big fan of the latter.

<comment><USER22> I think C++ is much harder actually. Making sure that the system doesn't crash means writing a lot more unit tests than what would be needed, and sometimes these problems come out in production only. I would love to switch to Rust, but it takes many years in a big company.

<comment><USER7> I agree. Learning all of C++ is much harder than learning all of Rust. C++'s saving grace is you can easily get away with learning only a much smaller portion of the language.

</comment></comment></comment></comment><comment><USER40> Probably. But why do you care? If you like it then use it and build something. If you don't like it, use something you do like and build something.

<comment><USER41> Why you might care is that if you build something today, that something could reap some benefit in the future from the language becoming "mainstream".

Possible benefits:

* users not going "gack, this is written in an obscure language that we have to install to build it".

* the implementation quality being better: the thing I write now will benefit from the language being less of a moving target and with fewer bugs, better performance.

Maybe a lot of that is just psychological, but so is "I like it" versus "I don't".

<comment><USER42> For point one, it helps that Rust is one of the easiest languages I have ever worked with to install the compiler run-time, pull dependencies, build, run, and distribute. So at the very least, it won't get in your way if you just want to distribute a static binary, or give your users a few commands to compile it themselves, even if it is "some weird language".

On point two, Rust is not a moving target, in the sense that it has maintained back compatibility since release to an amazing degree, and the build system does a good job by automatically pinning dependencies for applications. Also, even if it is totally abandoned, you still have a pretty solid language with C-like performance that benefits from ongoing LLVM optimizations. But it is certainly true that there could be unfixed bugs in an abandoned Rust.

<comment><USER43> Unfortunately Rust uses an LLVM fork IIRC, so using it is non-trivial.

<comment><USER18> We can use (and have tests to ensure that it works) a stock LLVM as well.

</comment></comment></comment></comment></comment><comment><USER44> It is

<comment><USER45> Certainly more then Nim.

I'd say, before Rust becomes really mainstream, we have to wait for the current generation of sysdevs to die.

But I guess till this is the case, there will be new languages invented that may be better than Rust.

On the other hand, most new companies don't hire old devs, so maybe IoT will give rise to new companies and young sysdevs all using Rust before the old generation is gone...

<comment><USER46> > I'd say, before Rust becomes really mainstream, we have to wait for the > current generation of sysdevs to die.

Why?

<comment><USER45> Of old age I mean.

It's like with everything. Most people simply do what they always did, most never reinvent themselves.

<comment><USER46> > Of old age I mean.

Yeah I get that. I asked why they should die. Not how or by what means.

> It's like with everything. Most people simply do what they always did, most > never reinvent themselves.

Based on? And note that we're not talking about "most people", we're talking about a very specific subset of people. Considering the changes in popularity of programming languages and the recent surges in adoption of Go and Swift, I'd say there's at least evidence to support people do change in this domain when something comes along that excites them or opens up new possibilities.

<comment><USER47> It's a pattern that's been well documented in the scientific community. You generally get a burst of innovation when enough of an older generation of scientists dies off for their ossified cognitive habits to stop holding back the more correct of the theories that have arisen in the mean time.

(Don't ask me to cite it though. I don't have time to go digging back through the textbooks from my "scientific reasoning" course.)

</comment></comment></comment></comment></comment></comment><comment><USER48> I think it has a fair chance (Go is a "systems" language and grew very quickly). I also believe you'll see it pop up in unikernels as well. Why, you ask? Because there's always 1 person that starts a project that gets traction.

I don't see it growing and replacing C++ though. I don't think there's much incentive post C++11 to really consider porting anything (even small things) over. Most of the features Rust gets praised for are either: (1) Ridiculous - if you need segfault protection, you're a bad programmer (CLARIFICATION: if you act like segfault protection is some majorly useful feature, you're an imbecile who must also think writing C/C++ is like disarming a bomb - nonsense; give me a real argument for Rust that isn't: insignificant, badly contrived, already in C++, etc. - you can't convince a generation of systems programmers to drop everything to move to Rust without this). Let's be honest, you don't segfault unless you're doing something idiotic. I've not segfaulted in the past 8 years in anything but assembly. Or, (2), things I've been using in C++ for the past 4 years.

Rust will definitely end up in these areas I believe but I just hope that it's not some horrible binding to a C/C++ library or something. I think backwards compatibility and current dependencies is a big thing.

<comment><USER49> > if you need segfault protection, you're a bad programmer. Let's be honest, > you don't segfault unless you're doing something idiotic. I've not > segfaulted in the past 8 years in anything but assembly

 _sigh_ Please look at the "trophy case" here: [http://lcamtuf.coredump.cx/afl/](http://lcamtuf.coredump.cx/afl/)

<comment><USER48> My views are the responses you'll probably get from the people who've been doing systems programming in C for the past 20 years. I don't doubt lots of common applications have memory issues. Maybe not a definite segfault but it's incredibly disingenuous to act like it's a major issue (as if writing C and C++ are similar to disarming a bomb or something). It's nonsense and the same reason I have been learning C++17's stuff rather than bothering with Rust.

I want a better argument for: 1) A C++ developer who's been writing C++ for a long time and is skilled in modern C++ who is wondering why he'd pick up Rust for user application development? I await more superfluous bindings like "Rust-Qt". 2) Porting C/C++ to Rust code (with a rather large codebase).

Every argument I've seen for Rust is: out of context, disingenuous when they compare it to other languages, or just incredibly biased. I don't think it's ironic that the majority of people I've met who have started doing Rust are bad at C and C++ and have bought into the list of features on Rust's homepage without any knowledge of anything related to them.

<comment><USER49> You're being so rude and inflammatory, for no reason. What's so frustrating is how you're convinced that everyone else is an idiot.

> it's incredibly disingenuous to act like it's a major issue

I gave you a trove of real world examples of serious security issues in widely used software developed by competent teams. Quite a few of these would have not existed in a language with the kind of guarantees that Rust provides. How is this disingenuous?

Take a look at the OpenBSD bug - any user can kernel panic the whole host, a massive security issue. Are the OpenBSD maintainers, in your opinion, "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? Perhaps they're "bad at C"?

The truth is that as code gets more complex, writing safe code becomes harder. The above is evidence that even smart and experienced people regularly cause colossal bugs that have real life implications.

<comment><USER5> > I gave you a trove of real world examples of serious security issues in > widely used software developed by competent teams. Quite a few of these > would have not existed in a language with the kind of guarantees that Rust > provides. How is this disingenuous?

Genuine question : do we know that those bugs would have been avoided using rust? Maybe some of those part would have had to be done unsafe mode for some reasons.

> Take a look at the OpenBSD bug - any user can kernel panic the whole host, a > massive security issue. Are the OpenBSD maintainers, in your opinion, > "idiotic"? Or that Xen bug - privilege escalation. Are the Xen developers, > in your opinion "imbeciles"? What about all the OpenSSL / OpenSSH ones? > Perhaps they're "bad at C"?

When was this code written ? you are comparing old C code with (non existant/hypothetic) rust code. How do you know the rust wouldn't slower ?

> The truth is that as code gets more complex, writing safe code becomes > harder. The above is evidence that even smart and experienced people > regularly cause colossal bugs that have real life implications.

That we completely agree on, but we learn quite a bit on how to write better code. Some of that knowledge got embedded in compilers/compilers warnings and tooling, some retrofitted in the languages themselves , some through libraries design and coding guideline etc...

My main problem with your argument is that you saying that a code written in rust today would be safer than a code written in C/C++ decades ago...That's probably true.

I think a much more interesting question is how much safer a code written in rust today would be vs a C/C++ code written today , reflecting our current understanding and knowledge on how to build safe system.

<comment><USER12> > I think a much more interesting question is how much safer a code written in > rust today would be vs a C/C++ code written today , reflecting our current > understanding and knowledge on how to build safe system.

A lot safer, judging by browser exploits.

<comment><USER5> > reflecting our current understanding and knowledge on how to build safe > system...

<comment><USER9> Despite all the flashy tools that proponents of C and C++ claim that makes C++ as safe as Rust, it's not doing any good at stopping the exponentially- increasing amount of vulnerabilities and crashes that are being reported over the last few years.

<comment><USER10> You have no data at all to back this up. The vulnerabilities you speak of are, far more often than not, written in old-style C and C++. That doesn't make Rust a bad idea, but it does mean your claim is completely unsubstantiated.

Advocating for Rust by lying is not going to help anyone.

<comment><USER9> This is the same line of logic and statements repeated by C and C++ programmers that shortly thereafter get showed up with a list of CVEs in their 'modern C/C++' projects. Remember the recent Curl developer PR disaster?

<comment><USER17> I think it's too early to tell if rust will prove any better in the real world, which includes things like devs using unsafe sections to cope with time pressures.

<comment><USER9> Use of unsafe in Rust is not required or recommended in most, if not all situations. That said, auditing a handful of small unsafe blocks is easier than auditing an entire project.</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Ask HN: Do you talk about mood in your team? - <AUTHOR> After working in a number of different teams I have experienced a lot different ways of working. Many things are common across teams, e.g. most teams have some type of short daily team meeting.
But one area which differs a lot between teams is mood discussions. In some teams it was discussed every day as part of the morning meeting (everyone share their mood) while in other teams it was never mentioned.
My personal experience is that the mood discussions are very valuable, e.g. help unearthing frustrations early and thereby create a better team atmosphere. What are your experiences, do you discuss mood in your team? Do you find it useful or is it just oversharing? <comment><USER2> Interesting, I've never seen that. Can you give an example of such a discussion? What would you share specifically?

<comment><AUTHOR> Example from one of the development teams, "Frustrated as the testing server went down _again_ yesterday when I deployed the new code".

This would then be que for the team to really get to the bottom with the testing servers. In this particular organization the servers were handled by another team and it needed some management attention to really fix the issue.

Other topics could be more subtle, e.g. colleague feeling a bit low due to personal reasons. Would then allow team members to more supportive that day.

<comment><USER2> OK, the former yeah I've definitely seen. It's kind of common sense I guess to share very annoying things like that to make sure we take the time to fix them.

The latter, never done before. That's interesting though. I like the idea of letting everybody know that today you may behave like an a __hole because you have problems at home, or your car just died or something. I 'll absolutely try it :)</comment></comment></comment>


Show HN: Amium – A better way to collaborate - <AUTHOR> https://www.amium.com/ <comment><USER2> For organizations that require certain documents to remain internal only (no 3rd party server storage), are there any options besides Amium's AWS hosting?

<comment><USER3> Out of curiosity what type of companies see on prem being more secure still? Do they really have top noch security teams or is the reality akin to stuffing money under your mattress to keep it safe vs a bank?

<comment><USER4> There are NDA issues, as well as data protection laws in the EU that mean that if you don't store data locally you need to got though a bunch of red tape (and get the person who is storing the data to also get audited). Oh, and good luck if the company is not in the EU (or even in another country).

Not to mention that we should really stop increasing our reliance on "the cloud". It's someone else's computer which you have no control over.

</comment></comment></comment><comment><USER5> You might want to have a re-think about the favicon - it's pretty similar to InVision's ([https://invisionapp.com](https://invisionapp.com)) and, while they're not quite in the same space, they're also not worlds apart.

<comment><USER6> Not sure if they've updated the favicon in the time since your post, but they do not look remotely similar to me.

<comment><USER5> They're both pink (a similar but not identical shade); one has "iu" and one has "in", both in white; one is a circle, one is a square. When I clicked the link I was initially confused because I thought it had actually taken me to Invision (which we use a lot), until I squinted and realised it was something else. I'm not saying they're identical, and I'm sure it's just a coincidence, but they are definitely similar to my eye.

</comment></comment></comment><comment><USER7> Is this a feature that AeroFS customers will also get access to? Or is this meant to be a completely separate product line? Overall, this is amazing. Congratulations on the launch :)

<comment><AUTHOR> We're launching it standalone so you can run them side by side if you wanted to. It IS built on top of AeroFS, so down the road we may offer a migration path :)

</comment></comment><comment><USER8> Wow, congratulations. This is what google should have built for Google Drive and Docs. Best Show HN this year.

<comment><USER9> When I saw this I was actually surprised that there's a need for it. I assumed Office Online has this built in (never used it).

</comment></comment><comment><USER10> I am seriously excited to give this a try today. I've been frustrated by file sharing between my team (we mostly use google docs or dropbox) and esp file collaboration (currently using slack). If this turns out to be the perfect love child between slack and dropbox, Amium is an answer to my prayers.

</comment><comment><USER11> This is really slick. Played with it for about 15 minutes and fell in love. Now to just convince people at work to use it... and pay for it.

</comment><comment><USER12> Seems to be aiming to solve a lot of the problems that Quip solves. @yurisagalov, how do they compare?

<comment><AUTHOR> "Like Quip, but for any file" (not just doc/spreadhseets), would probably be a fair comparison (and one I was tempted to make :-)

</comment></comment><comment><USER13> This reminds me of Dropbox Harmony for its business users. [https://blogs.dropbox.com/business/tag/project- harmony/](https://blogs.dropbox.com/business/tag/project-harmony/)

Basically, every MS Office folder in your dropbox gets a chat box. Everyone on the team who has that file open can chat with each other and edit the document together.

</comment><comment><USER14> I am in academic research. I want to see if this will be good for my work setting. I tried to sign up and got a nginx bad gatewawy error page :(. I'll try again later if I manage to remember.

<comment><USER15> If you're writing papers in LaTeX, then [https://www.overleaf.com](https://www.overleaf.com) should be good for you. Almost all of our department has started using it.

<comment><USER14> I actually just finished a manuscript with overleaf and published it on biorxiv (shameless plug: [http://biorxiv.org/content/early/2016/07/25/065789.1](http://biorxiv.org/content/early/2016/07/25/065789.1)). Unfortunately, latex isn't used that widely in biological sciences. There is a bit of a learning curve that people just aren't willing to invest time in. During preparation of the manuscript, I had to convert latex to word to distribute to collaborators and then manually edit the latex file accordingly afterwards.

Maybe this type of service where it is more microsoft office based will be better when collaborating with non-computational inclined people.

<comment><USER15> I've had a similar experience. I'm in a hybrid field (medical physics) where half of the people are from pure physics and the other half from a more biomedical engineering background.

It's pretty funny to see the culture clash between the two when it comes to writing articles. We had to learn latex in our first year of undergrad to write lab reports whereas the biomed people really don't see any value in using latex over word (especially for collaborating).

<comment><USER16> Try Authorea! (Disclosure: I work there)

Authorea is for researchers to write and collaborate online. Multiple users can write across formats in the same document (including LaTeX, markdown, rich text) and you can push a button to export to different file formats, journal styles, or publish to the web.

</comment></comment></comment></comment></comment><comment><USER17> just tried it. so basically this makes microsoft office usable again? hallelujah.

</comment><comment><USER18> Discussing files "in-line" is a pretty natural way to collaborate. This should have existed a long time ago, and is a natural evolution of workplace collaboration tools. Bravo, Amium team.

</comment><comment><USER19> Is it an add-on for Slack?

<comment><AUTHOR> Hey Andrey,

It's not. We looked into that, but we needed the ability to create nested channels (e.g. threads) since any file can be a thread/feed.

<comment><USER20> Can you share a file that's anywhere on your computer, or does it have to be in a shared folder?

Also, how does Amium handle file renames? This is a tricky one so I wouldn't judge the product if it has trouble here.

<comment><AUTHOR> File needs to be in the Amium shared folder right now :)

File renames shouldn't be a problem. We'll also show you a message in the chatroom if the file is renamed :)

</comment></comment></comment></comment><comment><USER21> Curious if this will have the same issue that Google Wave had; attempting to change a paradigm that is well understood.

<comment><AUTHOR> Hopefully not! We've tried fairly hard to make it fit into existing workflows so that the learning curve is not too difficult.

</comment></comment><comment><USER22> Are there any plans to support batch upload from other services (like Google drive, Dropbox, etc)? It would be nice to be able to migrate lots of folders and files in one click instead of having to download every file and then upload each file directly to Amium.

<comment><AUTHOR> actually, yes! Can you ping us at firstname.lastname@example.com and mention that? It'll help us prioritize and make sure we reach out when it's ready.

</comment></comment><comment><USER23> Should we add it to [https://sameroom.io/chat- timeline.pdf](https://sameroom.io/chat-timeline.pdf) ?

</comment><comment><USER24> Huge potential if you nail this. Congrats! Buggy to the point of being hard to even play with as of right now though.

<comment><AUTHOR> can you shoot me an email at firstname.lastname@example.com? Would like to follow up

</comment></comment><comment><USER25> Very good product. Thoroughly impressed

</comment><comment><USER26> Super excited about this, especially for a future on-prem version.

</comment><comment><USER25> What is your tech stack? The UI is gorgeous.

</comment><comment><USER27> Do I really need to login to try it out?

</comment><comment><USER28> We changed the url to the site from the blog post, but anyone who wants the background can read it here: [https://blog.amium.com/a-better-way-to- collaborate-b33d9dc4c...](https://blog.amium.com/a-better-way-to- collaborate-b33d9dc4cb86).

<comment><USER29> Appreciated, especially since the site is quite unusable atm.

<comment><AUTHOR> fixed! our fault for doing anything live today

</comment></comment></comment><comment><USER30> TL;DR Amium vs. Google Docs (and others)..?

<comment><AUTHOR> Google Docs is a reasonable comparison, but, a couple of things:

First, we do discrete versions/snapshots, so you can revert back to a particular version in time (along with seeing the associated conversation). Thing something like Github but for non developers.

Second, we support literally any file type. We integrated with Microsoft Office Online to support co-editing live in browser (which is the "like Google docs" portion), but we also support literally any other file type for conversation and activity feed: Photoshop, InDesign, PDF, etc. For many of these files types we also provide live previews and so on.

<comment><USER31> so how does it compare to just Office.com/WordOnline/OneDrive/SharePoint

it has full versioncontrol for all filetypes and provides your coediting in the browser. Why would I use you as my version control over sharepoint, the thing built into Word Online?</comment></comment></comment>


Thesis about the pathfinding AI of my action RPG game written in clojure(lisp) - <AUTHOR> http://resatori.com/performant-real-time-pathfinding-and-cooperation-thesis <comment><USER2> The wavefront-expansion pathing algorithm described in the paper is very similar to the approach in the roguelike game Brogue [1], whose author refers to as using "Dijkstra maps". The game uses it for many purposes, such as seeking the player, fleeing, finding food and treasure, and even auto- exploring [2]. It was also one of the discussion topics when the game featured on the Roguelike Radio podcast [3].

[1]: <https://sites.google.com/site/broguegame/home>

[2]: [http://roguebasin.roguelikedevelopment.org/index.php?title=T...](http://roguebasin.roguelikedevelopment.org/index.php?title=The_Incredible_Power_of_Dijkstra_Maps)

[3]: [http://roguelikeradio.blogspot.com/2011/10/interview- brian-w...](http://roguelikeradio.blogspot.com/2011/10/interview-brian-walker- aka-pender.html)

</comment><comment><USER3> The mob motion reminds me of Liquid War. Details about their algorithm at <http://www.ufoot.org/liquidwar/v5/techinfo/algorithm>

</comment><comment><USER4> Seems pretty straightforward. The 'wavefront-expansion' algorithm does a breadth-first expansion from the goal node, to every other node. As this is done, the distance from each node examined, to the goal, is stored. Afterwards, in order to move towards the goal, an entity at a particular node, moves to its neighboring node that has the shortest distance to the goal.

</comment><comment><USER5> Have you seen this paper: <http://grail.cs.washington.edu/projects/crowd- flows/> ? It touches on many of the same issues.

</comment><comment><USER6> I wonder how this compares to using flocking algorithms? It seems less efficient from what I gather.

<comment><AUTHOR> I wrote about this in the thesis. I did not use flocking algorithms because they are much more complex.

</comment></comment><comment><USER7> I wonder how many people saw the video and wanted to make a WoW/Aggro/Leeroooy related comment but held back afraid of being downvoted.</comment>


The five "Next Big Things" in open source - SD Times: Software Development News - <AUTHOR> http://www.sdtimes.com/content/article.aspx?ArticleID=35058&print=true <comment><USER2> I'm so appalled by the design of this site that I'm not going to read this, although the topic is interesting...</comment>


The mysterious fairy circles of Namibia - <AUTHOR> https://www.bbc.com/reel/playlist/world-of-wonder <comment><USER2> ?

I click the link and it takes me to:

"Japan's mysterious 'Dragon Eye' lake"

</comment><comment><USER3> [https://www.bbc.com/reel/playlist/world-of- wonder?vpid=p07lp...](https://www.bbc.com/reel/playlist/world-of- wonder?vpid=p07lp75k) seems to be the intended link. also [Video]

</comment><comment><USER4> There is a video on Amazon Prime about these too, very neat!</comment>


Banks Looking at $100 Billion Legal Tab - <AUTHOR> http://online.wsj.com/article/SB10001424127887323466204578382261903001702.html

<comment><USER2> This story is behind a paywall.</comment>


Brain may not need body movements to learn virtual spaces - <AUTHOR> https://medicalxpress.com/news/2019-09-brain-body-movements-virtual-spaces.html <comment><USER2> Haven't people have been learning to navigate virtual environments since the original Doom? I was hoping this would be related to AI learning the _concept_ of 3D space without having a body to move.

</comment><comment><USER3> "You are in a series of twisty passages that all look the same."

</comment><comment><USER4> This doesn't seem shocking? People can map virtual environments seated with controllers just fine. Further, people paralyzed from the waste down manage to map environments just fine without walking</comment>


I tried Prolon's starvation diet so you wouldn't have to - <AUTHOR> https://www.technologyreview.com/s/614082/prolon-starvation-diet/ <comment><USER2> Why is this articled titled this way? It seems very negative to me, and if I had just read the headline and moved on I would have assumed the diet was a silly, maybe even dangerous, fad. The article explains why the science is sound and ends with the author happy with the results, planning on doing the diet again in three months.

Is it just me who interpreted the title this way?

<comment><USER3> I was also surprised by the interesting science. We both clicked, though, so maybe good title.</comment></comment>


Ask HN: Companies who want to outsource some analytics to a data science class? - <AUTHOR> We have a class that we want to migrate away from Kaggle's academic platform for various reasons.
Through a chance connection in our network, a startup was happy to let us use their datasets for the class in exchange for all of the reports that resulted from it.
We can't use any dataset easily found online because a significant portion of the marking will be based on the prediction results from the given training data evaluated on held test data. (We can obfuscate/simulate/transform the data but I thought I might find more such companies with unique datasets with prediction tasks that can't be reverse engineered)
If there's any interest, please shoot me an e-mail in my profile and I'll get back to you promptly. Thanks. <comment><USER2> Hi Steven, I'm interested in this (charity with data on young people's self efficacy) but I can't see your email in your profile.

Either email me (see profile) or I'll check back later today

<comment><AUTHOR> Hey, thanks for letting me know - I thought filling in the e-mail field made it visible to everyone on my profile. Sending you an e-mail now.</comment></comment>


Learning to Think and Argue: a path to automated theorem proving - <AUTHOR> http://paulispace.com/intelligence/2017/11/24/ATP.html <comment> c-cube So, not even referencing the decades of research in the field of ATP? :/

<comment><AUTHOR> I appreciate your feedback.

The paper I referenced by Josef Urban et al. is representative of the state- of-the-art. That said, this is a first draft and I will make a lot of changes. Adding more references on ATP being one of them.

If you have any other thoughts/comments, I'd be very interested in hearing them.

</comment></comment><comment><USER2> An underrated field these days

<comment><AUTHOR> That's a very good point. I also think there's a difference between Automated Theorem Proving and AGI since entities with high-functioning general intelligence(i.e. AGI) aren't necessarily good at mathematics. ATP is a specific form of AGI in my opinion.</comment></comment>


Learning to Decode Unstructured Indian Addresses - <AUTHOR> https://medium.com/@kabirrustogi/learning-to-decode-unstructured-indian-addresses-c80ffcda2e84 <comment><AUTHOR> The latest version of AddFix (v3) is able to correctly determine the locality/sublocality of >90% shipments that flow through Delhivery's network and predict geocodes for these addresses with a median precision of 200m. These results are guaranteed to improve with time, without any additional developmental effort. This has enabled us to discard traditional pin-code sorting of shipments in favour of a more granular locality-based sorting system.</comment>


ReactOS releases 0.4.8 with experimental Vista/7/10 software compatibility - <AUTHOR> https://reactos.org/project-news/reactos-048-released <comment><USER2> This has been one of my favorite software projects to watch, because it's such an insanely monumental undertaking and moves so damn slowly. There were people working on this two decades ago, putting in tiny fixes and little bits of code and whatnot, and they did it even knowing that basically nobody would see their work for decades.

Hell, I have never seen a ReactOS installation in the wild, and I'm the kind of person whose friends install Haiku, Nix and NetBSD as their daily drivers. And the second-hand stories I've heard about people who did install React was basically "I was bored, I put it on a drive, played around for 5 minutes, and wiped it."

But that doesn't discourage them. Meanwhile, work keeps going on in the background. So many untold man-hours of thankless work going into the project, and the vast majority of that "hard" work with no payoff for years.

And now it's finally getting close to actual Windows, after decades of work, and soon (well, years, but still) people will be using it everywhere as a replacement for Windows.

This is one of the most important software projects in history. My hat is off to the ReactOS developers, and congratulations on the latest release.

[edit] Here are the names of the 75 programmers that have worked on ReactOS: [https://github.com/reactos/reactos/blob/master/CREDITS](https://github.com/reactos/reactos/blob/master/CREDITS)

<comment><USER3> > soon (well, years, but still) people will be using it everywhere as a > replacement for Windows.

No they won't. It's a fringe OS that requires technical expertise to install. Not only that but it looks like "old Windows". Users won't want to work with a Windows from a decade ago. Not only that but it'll have bugs and no support.

You'll see tiny pockets of people using it but as Microsoft gets closer and closer to simply having a free OS it doesn't seem likely anyone would ever use this OS for anything beyond "hey, that's cool!".

<comment><USER4> > _Users won 't want to work with a Windows from a decade ago. Not only that > but it'll have bugs and no support._

Depending on the age group, I guess. I know plenty of people who would say that Windows had its peak usability around Windows 2000/2003 and only got heavier and more confusing later on.

If I know that ReactOS had a good chance of running most regular Windows applications, I'd install it on my mother's laptop in a heartbeat, and she would love to see the familiar, lightweight OS.

<comment><USER5> > * I know plenty of people who would say that Windows had its peak usability > around Windows 2000/2003 and only got heavier and more confusing later on.*

Given Microsoft's mostly successful effort to make Windows more friendly to the user, I find it hard to believe any of these people have extensive experience with Windows 7+

<comment><USER4> Oh, but they did. There was a series of problems with Vista that pissed people off, then there was the quite-ok Windows 7, and then Microsoft screwed everything up with Windows 8. The irony is, they've managed to fix a lot of Windows 8 UX problems in Windows 10, but then the telemetry stories and in- your-face pushing of the upgrade from 8 to 10 left some people I know stranded at 8 and afraid to try out 10. I guess this'll change in the next hardware upgrade cycle...

<comment><USER6> I've been windows power user for many years before I switched to Linux. I can say that WinXP was one of the best windows and Win7 was okay and usable. Win8 and Win10 complete shit. Everyone I know had issues with it and had hard times using it. Asking if it was possible to use at least Win7 again. Windows completely screwed up there UI thinking it would be easier for people to use and in process completely killing windows. Not to mantion Win8/10 security/privacy horror storries. The last usable windows was Win7. This is why I see many people switching to Mac OS X or Linux.

<comment><USER7> > _WinXP was one of the best windows_

On a somewhat more objective note, there was _a lot_ of criticism back when it came out. (Specifically, about "the bloat". Everything is relative, I guess; one can say that things continued to get worse and worse from Windows 2000 on, although some would swear that it was NT4 that was the best Windows ever - e.g. it ran in 16MB of RAM vs. Windows 2000 that raised the requirement to 32MB; for comparison, Windows 95 only needed 8MB.)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> What I like about this project, besides the dedication and professionalism of the team behind it, is that it offers PC gamers a possible way to play Windows-era games moving forward. In a decade or two, we likely won't be able to activate a Windows XP machine (and wouldn't want to with all of the security hazards either) so it's great to have a free and open source project to run our Windows stuff.

<comment><USER9> Recently I had an issue activating XP on Eee PC after a RAM/SSD upgrade (setting it up as a retro-gaming console, better performance than RetroPie). I had to resort to registry hacks and msoobe to suppress activation forever, despite having product key at the back of the netbook - XP CD wasn't accepting it at all. One more situation where legal owners have to waste more time than pirates... If ReactOS makes it far enough to run on Eee PC, I'll get rid of XP.

<comment><USER8> I've been fiddling around with my Eee PC 701 in the past couple of weeks. Is there still a community for this sort of thing? RetroPie supports Eee PC?

<comment><USER9> I have the next gen 901; you can use any of the 32-bit emulation platforms on Windows and the 1.6GHz Atom (that could be overclocked to 1.8) is significantly faster than any Raspberry Pi, so you have a larger pool of games you can play at a proper speed. I upgraded it to 2GB RAM/60GB SSD, and it really flies. It's only slightly larger than a handheld console, so I thought converting it to a retro machine would be perfect use for it ;-) I tried Linux Mint on it initially but it was much slower than XP, so I am sticking with XP.

<comment><USER10> The last time I was using my eeePC 901, I managed to put Windows 8 on it, and I remember it being faster than either the XP or Ubuntu/Mint varieties I tried on it.

<comment><USER11> Slitaz would blew both 8 and Mint. Try it.

</comment></comment></comment></comment></comment></comment><comment><USER12> I feel like ReactOS has gained more attention lately and hope some of it will spill over to support of this project. It's a bit like you need to reach a critical mass in features and usability, and until then it's an uphill battle to maintain enough traction. Haiku is another cool project, especially as someone who will always have a warm spot left for the Amiga. But until the long waited for beta is out, I think they have an ever more dangerously steep uphill path to climb.

<comment><USER13> Haiku OS[0] is a BeOS inspired OS, though I do see some articles about a port of it to Amiga hardware.

[0][https://www.haiku-os.org/](https://www.haiku-os.org/) [1][http://www.generationamiga.com/2017/09/03/haiku-os-for- amiga...](http://www.generationamiga.com/2017/09/03/haiku-os-for- amigaone-500-computers-68k-port-in-development/)

<comment><USER14> They must've meant AROS [http://www.aros.org/](http://www.aros.org/)

<comment><USER15> Within the Amiga community there's a certain level of admiration for HaikuOS, as BeOS/HaikuOS is seen by these individuals as a spiritual successor to AmigaOS. As you point out, AROS is the open-source reimplementation of AmigaOS, so it's worth mentioning it, I just wanted to clarify why the Amiga+Haiku link might have been made.

<comment><USER16> Those of you discussing Amiga might find this comment from skrzyp interesting:

[https://lobste.rs/s/vkpekg/morphos_3_10_released#c_ktgnn3](https://lobste.rs/s/vkpekg/morphos_3_10_released#c_ktgnn3)

It gives a huge, deep history lesson from author's perspective covering important events, hardware/software, and especially the culture. It was fascinating. Also made me hold off on MorphOS for one of my projects.

<comment><USER15> Thanks for sharing the comment, but it's got a number of inaccuracies. For example...

> "The problem was that OS wasn't completely prepared for that, but clever > people from Phase5 found a way - they made their own microkernel (called > PowerUP, later WarpUP)"

PowerUP and WarpUP were competitors, and were the seeds for the later Red vs. Blue civil war.

If you'd like a clearer history of the Amiga, I'd recommend this series of articles on Ars Technica (it doesn't mention AROS, but is otherwise a good introduction):

[https://arstechnica.com/series/history-of-the- amiga/](https://arstechnica.com/series/history-of-the-amiga/)

</comment></comment></comment></comment></comment></comment><comment><USER17> One day when Windows drifts too far away from its golden age functionality, it will be great if ReactOS can fill the gap. However, I feel like MS could one- up them overnight by providing a sandboxed 32-bit XP VM as part of current windows. We'd get back DOS support and compatibility with old programs would be better. Call it Windows Subsystem for Windows or whatever. That would also pave the way to removing a lot of Win32 cruft from the main codebase, which MS seems very itchy to do.

<comment><USER18> It was already a thing in Windows Vista - at least in Enterprise, you could download a "windows xp " compatibility package, right click on any application and start it in windows XP - it would silently start XP in the background and render the app the same way as a native Vista app, while running on the XP kernel in the background. I have no idea if it exists in newer versions of Windows however.

<comment><USER19> No it doesn't, unfortunately.

The best option they suggest is moving it to a VM under Windows 10's Hyper-V:

[https://social.technet.microsoft.com/Forums/windows/en- US/1f...](https://social.technet.microsoft.com/Forums/windows/en- US/1f6e73ad-b3f0-4c05-9fb4-0f0237420f6b/how-to-legally-run-xp-mode-vm-with- windows-10-host?forum=w7itprovirt)

</comment></comment></comment><comment><USER20> > Several bugs have been squashed in the ReactOS CC and Freeloader, allowing > it to boot in 96MB hardware (smaller RAM need than our 0.4.7 release).

This is an impressive update when most projects, and not necessarily wrongly, always move in the opposite direction. Good to see.

As a free Unix user I'm primarily interested in ReactOS in order to test certain Windows things such as cwrsync over ssh. I tried installing ReactOS about a month ago but didn't have the right hardware to make it through the installer. I will definitely try again.

</comment><comment><USER21> Windows 10 is still not a good option for embedded x86 systems even in its proper supported embedded mode. Once I've replaced the shell, turned off all the services and junk programs and opened the one port on the firewall my industrial touchscreen application requires I would really rather windows take the hint not to change anything and leave things be.

I have been keeping an eye on Reactos for over 10 years, it is still a promising candidate for my legacy systems, USB Install would still be good to have as it is painfully hard to get it on to newer systems which don't have Optical drives.

It took me a while but I can now compile my gui applications for Linux, so going forward that is my strategy, but lots of factories out there still scared to move off windows XP and Reactos would be ideal.

</comment><comment><USER22> Seen ReactOS pop up a few times and always thought it was something to do with the Facebook Javascript library. This is really amazing, I'm looking forward to seeing where it goes.

<comment><USER23> Yeah, I've been confused too. The website itself doesn't help: no "About" or "What is ReactOS?" in the main nav. I ended up looking it up on Wikipedia to find out what it is: an open source OS that is intended to be binary compatible with Windows.

This does actually ring a bell for me - I seem to remember mention of it very early in the century. That perhaps cuts to the heart of the issue: it's been going as a project since 1996, yet it's still only considered alpha. In other words, I'm not so sure it's going anywhere fast, and I'm not sure what you'd really use it for.

<comment><USER24> I bet in 20 years no one will know what ReactJS even is, but ReactOS very much will preserve NT regardless of Microsoft's successes.

ReactOS is a usable Windows NT 6+ clone, with kernel ABI ( driver ) compat, that runs real software. What are you comparing it to, to be able to qualify the speed of its development?

<comment><USER25> > I bet in 20 years no one will know what ReactJS even is, but ReactOS very > much will preserve NT regardless of Microsoft's successes.

Don't be sure about something in the tech on such a long time frame. Just to put things into context. Andoird is less than 10 years old and already close to windows market share territory. Facebook is only 14 years old.

I can't even imagine to comprehend what will happen 20 years from now.

<comment><USER26> The JS ecosystem is as of now still a rather ... fast paced environment. There is a lot of churn in there. I don't think ReactJS will survive ReactOS.

</comment></comment></comment></comment></comment><comment><USER27> With the US Court of Appeals for the Federal Circuit ruling that API's are copyrightable I wonder what type of impact it could have on open source projects, such as ReactOS, if the copyright holder ever decided to take action.

<comment><USER28> 1\. The ReactOS project's implementation of Windows APIs is purely for compatibility reasons; on the other hand, Android's implementation was not meant as a compatibility layer for existing apps. (In fact, that Android _didn 't_ implement a compatibility layer was a huge sticking point for the Sun contingent within Oracle—although if we're honest, we know the motivations for Oracle proper are the dollar signs.) It wouldn't be a good idea to try and draw direct parallels between the two.

2\. _Oracle v Google_ still isn't over, so even drawing any inferences about _Oracle v Google_ itself would be premature.

3\. The copyright holder here is MS. Any action on their part to go after ReactOS now be the undoing of all the goodwill they've built in the Nadella/MS-on-GitHub era. The result would be (a) a bunch of I-told-you-sos from the leery folks still holding on to their grudges today, and (b) a massive, _massive_ , innoculating "fool me once…" reaction among the folks who'd actually been made suckers for not heeding the grudgeholders' warnings. All in all, it would be a spectacularly bad idea for MS at this point, especially given how much weaker their empire has already gotten in the last decade.

</comment></comment><comment><USER29> One of the most interesting changelog that I have read in a While. Well written, thoughtful and gave me good insight into the project.

<comment><USER30> Indeed a great read to catch up with the project.

> Talking about the notification tray, due to Ged's work, icons of killed and > finished process are now automatically removed, even when apps crash. This > is something that Windows doesn't even provide with Win10, and many Windows > users may have noticed.

Made me chuckle. This has bothered me since forever. It seemed like such a low hanging fruit to fix, I wonder why Microsoft never did.

<comment><USER31> > I wonder why Microsoft never did.

I'm assuming it's because of the size of the codebase, available engineering resources, return-on-investment calculation, and a business prioritization of new features over refinement.

Most engineers can look at their own work or codebase and think, "well, that's a bit shit but it works well enough." I can't imagine their backlog. I'm sure it's lurking in an issue queue somewhere.

<comment><USER32> One notable thing is that in Windows the behavior of taskbar changed around the time of Windows 98SE/2000 (I'm not sure in which version exactly). Originally the "orphaned" tray icons just were there and you could not cause them to go away, "new" behavior is that first event (ie. hover) causes them to be destroyed.

<comment><USER33> Guesswork: once you hover over an icon in the taskbar, later Windows checks if the process (or, rather, window, as the icon will be tied to the window handle you get from CreateWindowEx) handle belonging to it is still alive. If not (aka it cannot find a target window to send the message to) the icon gets destroyed.

ReactOS, another guess here, does either a polling check if all taskbar icons have valid process handles or a check whenever a process exits.

<comment><USER32> AFAIK the taskbar forwards the window messages destined for the icon to window that owns the icon and in the "new" Windows' behavior simply notices that such window does not exist. ReactOS behavior probably works on the basis of hooking destruction of the owner window (although I suspect that on Windows windows owned by killed process will not get WM_DESTROY message, but it's wild guess as I'm completely out of my rudimentary and rusty knowledge of WinAPI there).

</comment></comment></comment></comment></comment></comment><comment><USER34> I've submitted non-clean-room reverse engineered code to ReactOS years ago when I was younger and it was accepted with no questions asked. But since that day, I can't bring myself to believe all of this is clean-room reverse engineered.

I hope it was an outlier event and that external contributions are better audited today.

<comment><USER35> As long as nothing can't be proved, why bother? I don't think one could raise a good point about ethics in favor of Microsoft. DMCA is shit.

</comment></comment><comment><USER36> Genuine question: What advantage does ReactOS provide over Wine?

[https://www.reactos.org/wiki/WINE](https://www.reactos.org/wiki/WINE) explains a bit but still doesn't answer the question.

P.S. oh by the way, the developers of both projects are apparently collaborating and ReactOS uses Wine's DLLs for their userspace, so my question is not meant to criticise the "double-effort" or anything like that.

<comment><USER37> I've wondered this myself, anyone know if ReactOS can run anything wine can't?

I tried wine-develolment a few days ago and 3D performance is still rather spotty (amongst all the other usuall hiccups). That being said is has helped me play a few games with a decent experience.

<comment><USER38> Drivers for one - reactos can be used for Windows driver testing, wine cannot.

</comment></comment></comment><comment><USER39> The USB support isn't quite there yet (major rework didn't make it this release) but otherwise this is a pretty good release with massive progress in actual usefulness.

<comment><USER7> For why USB is hard, see [http://www.usbmadesimple.co.uk/](http://www.usbmadesimple.co.uk/).

<comment><USER24> Ugh. This website saved my ass trying to make HID devices work on top of the completely non-conforming Linaro DwUsbHostDxe driver (look at [https://github.com/andreiw/RaspberryPiPkg/commits/master/Dri...](https://github.com/andreiw/RaspberryPiPkg/commits/master/Drivers/DwUsbHostDxe) for a laugh). I did end up having to hit the USB spec in the end, but it's a legit resource to get a birds-eye view of the whole USB1 and USB2 thing. It doesn't make USB simpler, but sure makes it more approachable.

<comment><USER40> Offtopic: What's the end goal of all this UEFI work you're doing for the Pi?

<comment><USER24> No concrete goal beyond having a reasonably useful UEFI development environment (more so than the 96boards one).

It's been useful to be able to run the same Ubuntu and SUSE images as VMs and servers do, but that's only really possible because the built kernels have RPi3 support (but at least you now don't need a custom image with U-Boot).

</comment></comment></comment></comment></comment><comment><USER41> Tried the livecd in a VM and a couple of niggles sprang up.

First of all, no driver for the network card in Virtualbox, though Vmware worked fine.

Second, no web browser...

Third, the mouse sometimes freaked out and got stuck in a corner.

<comment><USER42> It should be obvious enough, but perhaps you missed: you can install a browser, such as an old version of opera, by fetching its installer over the internet via ReactOS builtin "program downloader" (I do not remeber its name).

If you meant lack of default browser preinstalled though, I agree with you its lacking.

It's necessary to change the network card in VirtualBox for internet connection to work IIRC.

<comment><USER41> Ah, i missed the program downloader while poking around.

I'll take another look.

<comment><USER24> Firefox 48 worked, but the autoupdate crashed.

If you install 7Zip, you should know that 7Zip does not associate itself with file extensions by default. This is 7zip behavior. You need to run 7zip, go to options, and set associations by clicking on the '+' button.

</comment></comment></comment></comment><comment><USER43> I'm curious - so now that the ReactOS guys are picking up bugs in Windows, does this mean they have a comprehensive test suite of Microsoft Windows proper?

<comment><USER44> They've had for a decade at least.

</comment></comment><comment><USER45> I'm willing to bet, this will be very useful in a few years time, and the primary use will be 'fixed function' devices (in industries that are very slow to change) that currently require Windows. (ATMs, POS, Announcement Screens, Equipment controllers, SCADA systems, etc, etc)

</comment><comment><USER46> I think their site is getting the HN hug of death, loads extremely slow/doesn't load at all...

<comment><USER47> yep it's currently fully smothered for me

</comment></comment><comment><USER48> I think Windows will just keep breaking compatibility faster then they themselves and others are able to keep up. Forcing users to keep upgrading and buying the same software over and over again.

</comment><comment><USER49> I wonder if the planned Vista/7/10 support will extend to kernel mode drivers, especially for WDDM2 and up graphics drivers.

Currently, the supported graphics drivers is pretty sad for modern-ish hardware on ReactOS, because they are limited to drivers for Windows Server 2003 / Windows XP, which aren't available for a lot of modern cards (or integrated chips, for that matter). Additionally, a lot of the older XP drivers don't work well on ReactOS today.

</comment><comment><USER50> I love ReactOS, especially in VM. Windows requires separate license for each VM. If I maintains 10 VM for testing, it's a problem.

</comment><comment><USER51> In case you are dismissing this as a fringe project, remember, what is ridiculous today is commonplace tomorrow.

</comment><comment><USER52> I'd be curious if ReactOS runs the Oculus Rift drivers, runs docker and is more performant then Windows 10.

<comment><USER53> > more performant

Do you mean _faster_?

<comment><USER52> More resource fficient, which ususally means faster in execution or runs better on resource constrained machines. For example how well does it run in 2G compared to Windows 10?

</comment></comment></comment><comment><USER54> Can anyone comment if I can install old Windows 2000 games on this, like C&C Red Alert? Would it work?

<comment><USER55> And simtower?

<comment><USER56> \- Version 1.0: Game saving is broken, everything else works: [https://appdb.winehq.org/objectManager.php?sClass=version&iI...](https://appdb.winehq.org/objectManager.php?sClass=version&iId=789&iTestingId=36712&sAllBugs)

\- Version 1.1b (retail): Copy a DLL over for working sound, then everything works: [https://appdb.winehq.org/objectManager.php?sClass=version&iI...](https://appdb.winehq.org/objectManager.php?sClass=version&iId=28003)

</comment></comment></comment><comment><USER57> What Kernel does this OS use? What's its history? Is it a unix fork such as Linux?

<comment><USER33> No, it's a reverse engineered Windows. I believe that due to copyright issues it even is a fully clean-room developed implementation, which means that it's _not_ based on MS documentation or on decompiled source code.

<comment><USER58> > _which means that it 's not based on MS documentation_

I think looking at MS documentation is okay. You're allowed to look at MSDN for Wine development[1]. Since the projects share code, you're probably allowed to do so for ReactOS as well.

[1]: [https://wiki.winehq.org/Clean_Room_Guidelines](https://wiki.winehq.org/Clean_Room_Guidelines)

</comment></comment></comment><comment><USER59> appears to work well, including old photoshop 5.5 from a windows cd [https://youtu.be/Ne88Is2cymQ](https://youtu.be/Ne88Is2cymQ)

</comment><comment><USER60> Does Starcraft run?

</comment><comment><USER24> So I'm a ReactOS fanboi, but... but...

\- You need to fix your flaccid dev community. Your forums have a terrible S/N ratio. IRC may be great and all, but I don't see any hard documentation behind any design discussions or development. I do see crazy shite like "can I run ReactOS on Playstation 2". The forums make your project seem dead, which it clearly isn't.

\- You need to fix your flaccid dev community. It needs a larger presence. It needs to be tangible (who is doing what? who are the people? do you have conferences?)

\- You need to fix your flaccid dev community. There is a bunch of really useless, out-of-date, confusing and out-right self-inconsistent information on building ROS, and the Git move didn't help (but kudos on the move, it is long overdue). I've tried 4-5 times to do something, but the directions I followed on Win, Ros or Linux all ended up breaking somewhere.

\- You need to fix your attitude problems (or your forums). There are people asking reasonable questions, who get actively or passively aggressive answers. Not good.

\- You need to fix your toolchain problems. This whole SEH thing is getting out of hand. Does Clang support SEH yet? It might - [https://clang.llvm.org/docs/MSVCCompatibility.html](https://clang.llvm.org/docs/MSVCCompatibility.html). So maybe you need to bail on GCC, or maintain your own fork of it (yes, it's ridiculous that GCC still doesn't have SEH support, and the patents have long expired).

\- You need to get a grip on x64 support. Your toolchain problems cannot be a gate (and you can clearly use MSVC for building... so...). IA32 support is great and all, but needs a back seat to x64.

\- You need to get a grip on UEFI booting (note UEFI booting does not /necessarily/ mean you need improved ACPI support, in practice)

\- SMP?

\- Forget Xbox, NewWorld PowerMacs (those were BE anyway) and 32-bit Arm chips (which outside of the Pi are too varied and too few). Targeting 64-bit Arm chips does make sense, though, now that Microsoft has released a client build of Win 10 on laptops and an Arm server vendor demoed Windows Server at OCP'18 ([http://www.opencompute.org/assets/Uploads/18150J-Ampere- PPT-...](http://www.opencompute.org/assets/Uploads/18150J-Ampere-PPT- OCPSummitKumar-final.pdf)). You will need UEFI and reasonable ACPI support to support ARM64. You can target SBSA and SBBR compliant systems and this will give support for the entire server ecosystem (and qemu VMs, har har).

\- You might wish to minkernel-ize ROS as well, so you can boot without a GUI.

\- You might wish to update Wiki (and build a list of links to relevant pages) for active subprojects.

<comment><USER43> Wow, aggressive much?

<comment><USER24> I dunno dude. I just pointed out the obvious, and all I get is a passive- aggressive minusing. Most people won't care enough to even give you "a rant", they'll just move on.

If you don't want feedback, don't ask for feedback by posting publicly. My "rant" is a collection of issues I've seen for at least the last 7 years of actively paying attention to the project.

</comment></comment></comment><comment><USER61> Every time I see this I briefly think it's a Linux distro with a React-based window manager</comment>


Ask HN: Searching for Functions via Type Signatures - <AUTHOR> I just came across an old paper discussing searching for functions via type signatures. How prevalent is this kind of search perhaps in code search systems? Does anyone else know more about this kind of work?

    - https://github.com/theSage21/sigsearch
    - https://www.cs.cmu.edu/~wing/publications/ZaremskiWing93.pdf
 <comment><USER2> There's Hoogle, for Haskell: [https://hoogle.haskell.org/](https://hoogle.haskell.org/)

I don't know if it implements any techniques from that paper, but it does let you search for definitions by type signature. Of note, it also does a pretty good job of finding results with different-but-compatible types, which is very valuable in a Haskell context given all the polymorphism.</comment>