Hacker News Reader

> smooth brain to text programming

This isn't a good thing, in my opinion. Brains make mistakes. I don't want smooth, uninterrupted coding. I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. It's a lot less painful to write code in fits and starts than to write a million tests or spend hours debugging.

It depends a lot of what you code and your constraints. Believe it or not they are a huge crowd of people making a living out of code that is easy to write but crashes. And they are happy about it.

E.G: one of my friend has a streaming website. He make banks with ads despite the site having problems all the time. He doesn't care the least. He is not an expert coder and just want to be able to build the features he needs, even if it's not perfect. Types are way too much for him. It took 2 years to master git basics.

Another example: my current clients are geomaticians. They code in Python a lot. They produce only small codes, and don't want something complex. They are experts in maps, not code, and love Python to have the balance of cost / reward they want.

HN is a bubble of expert devs, but the world is full of PHP plumbers, data manglers, sys admin and other professional that have a legitimate needs for "smooth brain to text programming".

And I think that's fine; Rust isn't trying to be the one language to rule them all. It's intended as a foundational language: your friend's streaming website survives despite his own code crashing often, but it won't survive if his off-the-shelf HTTP server crashes often (HTTP servers being the sort of thing one would write in Rust). Likewise, your mathematicians aren't going to be very productive if their Python interpreter crashes often (likewise, interpreters are the sort of thing one would also imagine writing in Rust).

Even in Rust's ideal future, very little of the code atop the stack is written in it. It's the code at the very bottom that underpins everything whose share it hopes to eat.

Dictatorial concepts in PL usually fail pretty badly. Rust may become the textbook example of a good idea too far. I'd certainly never use it or use anything written in it given a choice and/or time to rewrite in anything more accessible.

> or use anything written in it

As I often say on HN, I must be missing the sarcasm here...

I think "use" in this case is in the sense of a developer using code, rather than an end-user application.

Oh yeah that's fine. Both languages are actually very nice used together.

> I want the compiler to tell me when I'm making the mistake, even if it makes things choppier.

You don't think the OCaml type system would do this? OCaml gives you just as much safety as Rust does, it just doesn't also give you no GC like Rust does. And the price Rust pays for the absence of GC is the lifetime concept, which adds a very significant layer of complexity to the language. Much like OCaml, Swift and Scala also provide very safe type systems.

Again, if you can't have a GC, then Rust is an excellent option, and the only really safe GC-less language unless you use C with FramaC or similar static analysis (and FramaC also requires lots of training and time to use, just like Rust).

Ownership and borrowing are also useful for avoiding data races. OCaml solves the problem by not having any shared state at all, which is obviously a huge limitation.

Current OCaml needn't worry about data races since no state is shared. Unfortunately, current OCaml also only exploits a single core, but it's so insanely fast that usually doesn't matter.

Upcoming OCaml multicore solves the shared state and data races problem with algebraic effects[0]. It is working, it's just not yet been released in mainline OCaml. Supposedly, that will happen this year, but we'll see.

0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...

OCaml seems like the argument against Rust's claim to trade usability for safety. It's not true for everything, I wouldn't write embedded OCaml, but it's an easy disproof-by-example for "Rust's difficulty is the inevitable price for trustworthy code!"

Which isn't to say OCaml is trivial, or Rust is useless (GC and threading both being limitations). It just makes me skeptical of claims that Rust's difficulty is irreducible.

Rust's difficulty relative to OCaml might be irreducible if we consider the difficulty added by not providing a pervasive GC, which is part of Rust's design goal and not part of OCaml's.

But OCaml isn't intended for the use cases Rust is intended for: a replacement for C and C++

It depends on the use cases you mean.

OCaml is actually used for many systems programming tasks that can live with a tracing GC.

>I wouldn't write embedded OCaml

But you can run OCaml on a microcontroller:

http://www.algo-prog.info/ocapic/web/index.php?id=ocapic

I don't think they are any error classes that OCaml/F# will let you make that Rust won't.

Rust prevents data races, OCaml/F# don't provide such guaranties. Though it isn't so much of a problem in OCaml since it doesn't have concurrent threads.

OCaml has GIL, is normally single core, and shares no state, so current OCaml doesn't need to provide such guarantees.

Upcoming multicore OCaml will provide such guarantees through algebraic effects [0].

0. http://kcsrk.info/ocaml/multicore/2015/05/20/effects-multico...

First, Rust does not prevent data races, just makes them pain to write.

Second, Rust also prevents legitimate sharing in a bunch of cases where concurrency is not involved. (and a simple scoped allocator succeeds)

This would be fixed if there was an easy way to have typed memory that can be shared but cannot be accessed concurrently. There is none. You get at most full unsafe.

Rust does prevent data races, as long as you don't use unsafe. If not, it's a bug.

You can write arenas in Rust.

Just to be clear about the terminology (since I'm not sure if the grandparent knows about the difference): Rust prevents data races but not race conditions (although it makes it easier to avoid them). Here's an explanation about the differences: http://blog.regehr.org/archives/490

You can, but it is an extreme pain to do it, especially for any nontrivial data structure. That is because even if the arena is safe enough, say with copy on write semantics, you cannot specify that for the borrow checker easily (or at all)

You cannot implement many data structures in a decent performance way without unsafe, so Rust guarantee is weak.

> You can, but it is an extreme pain to do it,

It is not extreme, and it isn't even necessary: just reuse one of the many arenas others have already written, e.g. https://crates.io/crates/typed-arena .

Copy-on-write is fairly ease to write in Rust, e.g. the even core Rc and Arc types have a get_mut function that does copy-on-write.

> You cannot implement many data structures in a decent performance way without unsafe, so Rust guarantee is weak.

You can't implement anything in C or C++ without unsafe: Rust's main strength is the ability to write high performance code with a safe interface, so that only one library has to muddle through the `unsafe` problems (if they have to touch `unsafe` at all). Most code one writes is not implementing data structures.

As a demonstration of this strength, even very low-level projects like operating systems can get away with not using `unsafe` everywhere by packaging it up into safe interfaces, e.g. http://os.phil-opp.com/modifying-page-tables.html

Data races.

Give it time. Rust is brand new and has changed considerably during the last year. The rust team listen closely to the community and will smooth things up. But they can't do it all at once.

This is worth remembering. I'm technically on my "second attempt" to learn Rust, but the first one wasn't abandoned because Rust is fundamentally flawed. It was just new enough that the thing I wanted to build was drowning me in nightly builds and hypothetical features. After giving it ~1 year, things are already looking much more welcoming.

> I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time).

If you're not aware of it, scala-native looks very interesting... It looks to be active project.

https://github.com/scala-native/scala-native

FWIW, I've also enjoyed Swift development quite a bit. I think Swift will go deep into the C++ sweet spot.

A benefit that Swift has over Rust in regards to market adoption, is that an OS vendor has the power to say "My way or the highway" to developers that want to target their platform.

However Rust is already picking up steam in Firefox modules, hobby OS development, university CS degrees and GNOME modules, so there might be a path there.

The tooling for Swift is certainly miles better on iOS, but I do like Rust as a language. On Android the most comprehensive solution I've seen is Xamarin, but last time I tried it (which was years ago), I wasn't a fan of the GUI and the perf was worse than Dalvik. Hopefully that has improved now.

Rust seems really great as infrastructure level code, but the tooling still has a lot of rough dyes when it comes to mobile development.

I think Swift could play a decent role here if it ever gets good android support as it already enjoys first-class support on iOS. I also agree in that Swift feels very nice. :)