Hacker News Reader

Comment by Manishearth | Hacker News Reader

> If you're fighting, you've lost.

I don't really get this attitude, it means that nothing new will ever overcome anything that's been established.

> Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move

You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.

> Blog posts wont pull me away from C, tooling and docs will.

Then you are not the right audience for this blog post :) I find that such blog posts are extremely helpful in convincing people who have a choice between starting to use C and starting to use Rust, not folks who are already invested in C or C++. But I have seen such overviews to have impact on invested C/C++ programmers too; everyone is different!

View on HN

>> If you're fighting, you've lost.

> I don't really get this attitude, it means that nothing new will ever overcome anything that's been established.

I think he's trying to quote Dan Saks' "extern c: Talking to C Programmers about C++" when he said "If you're arguing, you've lost." Saks, at least, meant that if you're striving with someone, you've already lost because your partner is already in a "frame" of mind set against your arguments that is unbreakably strong, even by logic. The talk is really good just for that aspect.

Ah, I see. Yeah. I read that post more as a demonstration than a "fighting".

But that's a valid point.

I would have linked the video had I remembered the talk but exactly. This is what I meant.

> You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.

This resonates well with me. I came from PHP and I decided to learn C in order to contribute to an existing PHP extension. I was doing well following a C tutorial. Until I arrived at string manipulation at which point I said, f* this sh.

So looked for an alternative systems programming language to learn, and found Rust. And its a pleasant language to work on. Its a low level language that feels like a high level language.

My only fear is that, if Rust becomes a popular language, the community will end up as toxic as the JS and PHP community. Right now, the Rust community is filled with the smartest and friendliest devs I know of among open source communities, and I kinda like it to stay that way.

>Right now, the Rust community is filled with the smartest and friendliest devs I know of among open source communities, and I kinda like it to stay that way.

I have yet to find a community that has gotten popular and hasn't turned into a sewage plant. I think it's just a reflection on what the general population is like... :(

The Rust community is as great as it is because of very deliberate decisions and investment in engineering structures to maintain a positive community at scale, so I'm pretty optimistic that it will stay really good. Arguably this work is as innovative as the language itself.

Emily Dunham of Mozilla has a talk about this Community Automation: https://www.youtube.com/watch?v=dIageYT0Vgg

The rust community is very small so it's easy to 'engineer it' at this phase. Once it gets so large that you have an eternal September it's effectively a complex system that will be very difficult to reason about with any changes resulting in lots of gnarly side effects.

Name a large programming community that is pleasant to interact with for newcomers and insiders alike.

One of the distinctive things about Rust community management is how much is literally engineered, and done with software and processes so that it can scale. All of the touch points are designed: the rustup tool manages the installation experience, Cargo the build process and 3rd party dependencies, the RFC process structures online discussion, the This Week in Rust newsletter provides a heartbeat for the community, bots like Bors handle routine interactions, all of the entry points for interacting with other community members display the Code of Conduct, and so on.

It's a level of purposeful design that only the .NET and Go ecosystems approach, and because it's unusual and largely unobtrusive, it's not obvious that this really good, highly productive community is not at all accidental.

I would say that most large programming communities split into multiple communities, so different kinds of folks don't interact as much: the people on the core developer mailing lists are mostly not the same people as on IRC, or on user mailing lists, or working on issues for 3rd party frameworks in GitHub. I can't think of a sub-community that I've had experience with that I would characterize as unpleasant.

"My only fear is..." - this is why I'm in the process of moving to Rust after 3 years of Go. I've come to the conclusion that a low barrier to entry leads to a bad state of affairs. Rust has a learning curve that I hope will help it avoid devolving into chaos.

I'm currently trying to learn Rust, but if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast (especially compared to something like Ruby!), the ecosystem is huge and tooling is extremely mature.

Java has not so great reputation about safety.

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

Well, I don't know about java's reputation, but there's this:

http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend...

http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...

Security exploits say nothing about the language's memory safety design. Java still qualifies as a safe language.

As a safe language from race conditions or memory leaks?

The Java VM is written in C though.

There are many java vms

The most popular(hotspot/openjdk) is written in c++/assembly

GC is not about safety at all, sorry. I'm not going to start flamewar, but just to answer your question: https://www.google.com/#newwindow=1&q=null+pointer+exception

You can't say NPEs are an example that Java is unsafe. The propegation is Nulls isn't Java's fault and Java's evolving currently to make use of Optionals as we speak to attempt to avoid this.

I can say it.

No sum types (the Java alternative to Rust enums is the horribly verbose visitor pattern, so a lot of the time people don't bother). null. A verbose and unabstractable "checked exception" system (that the standard library uses poorly in places) that leaves many users resorting to unchecked exceptions (panics) instead. Uninitialized field problems because methods are virtual even when called from superclass constructors. Excessive overhead to custom types that leads to using weakly typed Strings etc. rather than domain types. Poor abstraction facilities that lead to a culture of "magic" annotations and runtime reflection (or worse, proxies and bytecode manipulation) e.g. @Transactional, @Inject.

Java is safer than C, but it's a long way behind a modern functional language like Rust.

That's interesting because it is based on the same principles of not letting developers do harmful thing as a way to guarantee security.

Rust uses RAII for memory-safety, not just language constructions to raise some limitations.

Java's bad safety reputation comes mostly from the Java plugin, where many inventive ways to bypass its sandbox have been discovered. When used as a normal programming language, without depending on it for sandboxing (that is, when all code running in the JVM is trusted), its safety is quite good.

(Java also has a not so great reputation about speed. That one also comes from the Java plugin, which often took minutes to start up, while keeping the Netscape browser UI locked up.)

... and just to add to that, if you look at the other popular sandboxed client-side runtimes, i.e., Adobe Flash and various JavaScript-enabled browsers (all of them implemented in C++), you will find a similar number of critical vulnerabilities.

I see a lot of NPE in IntelliJ IDEA, especially EAPs. It's not browser's plugin.

NPEs are not a security issue in the same sense as a buffer overflow or null pointer dereference.

>It's plenty fast

Unless you need guarantees that can't be offered by garbage collection.

Java is pretty popular for HFT applications. I think most programs are less latency sensitive than that. But of course, Java is not for you if you have hard real time constraints.

In some cases those HFT installations are tuned not to run full Java GC within 8 hours during the trading day. Then they are rebooted.

That sounds interesting - have you got any more details on exactly how they set this up?

You can also use the Java Unsafe class to squeeze performance (every last bit) by recycling objects. I'm sad to say that I've had to do that at least once to make some vector math work.

Edit: Check out https://dzone.com/articles/understanding-sunmiscunsafe

A person on a conference has not mentioned details. The reason for Java is productivity and access to a bigger pool of developers.

> I think most programs are less latency sensitive than that.

Hardly, compared to anything that takes user input and aims at 60/120 FPS (where you inevitably end up bypassing GC if you can't force it to run when you want to).

https://www.quora.com/Is-Java-overtaking-C++-in-the-HFT-worl...

> One thing about HFT is that the speed of the language oddly doesn't matter much. You are talking about latencies of 20 milliseconds, and any language can do 20 milliseconds since CPU times are measured in nano-seconds rather than milisecond.

and

> If you are playing in the sub 10 microsecond range doing everything in C++ helps a lot. [..] A lot of high frequency strategies run in the 20-30 microsecond time frame. I think this is where a lot of diversity in terms of setup occurs.

and

> To lower execution costs, we need a low latency system that has good determinism in response times. You cant pause for hash table rebucketing or garbage collectors or the OS taking away your time slice or moving you to a diferent processor or whatever. There are guys who try this in Java, and spend most of their time trying to make Java work deterministically. Good luck

and

> If you are in ultra HFT then C++ is the only answer (besides custom hardware - FPGA & ASIC). You just can't afford garbage collector.

There's a commercial pauseless GC offering for java. It's pretty much aimed at HFT applications.

https://www.azul.com/resources/success-stories/

> if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast

Context is pretty important to the original comment:

> python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues.

they're not looking for a fast language in isolation, they're looking for a fast language in the broader context of their existing technological stacks. Java doesn't help that much when you're looking into ways to speed up your Ruby application, at least not easily.

Furthermore, Java has the issues that it's only fast when memory is plentiful and it has a long startup/running time, it's "eventually fast" if you will.

Java's FFI story is not as good as rust's though. So if you're interacting with the OS / native libs a lot then it might not be a good choice.

Although there's JNR and JNA and it might become a standard feature at some point in the future[0]. But for a good FFI experience you also need arrays-of-structs, which means you need value types in java. So it's a long journey to get there.

[0] http://openjdk.java.net/jeps/191

Do people choose languages based on blog posts? I've never done that, usually it was a combination of literature and mailing lists that convinced me. I also ignore conferences entirely.

I would love examples of writing about rust that didn't mention or assume any C/C++ knowledge before. So much of what I've run into assumes that knowledge.

I'd love to read tutorials or books that assume Rust is someone's first programming language, period. What would that look like?

The book doesn't assume any C/C++ knowledge.

There isn't any good "first programming language" material using Rust yet, IMHO.

Reply on news.ycombinator.com