Hacker News new | comments | show | ask | jobs | submit login
Rust in 2018: easier to use (jvns.ca)
462 points by OberstKrueger 10 months ago | hide | past | web | favorite | 293 comments

I expect a "it's easier to use" evangelism push around the upcoming epoch release. There are a bunch of mostly completed but still feature flagged changes that should remove a lot of the borrow checker toe stubbing. Getting rustfmt (formatter) and clippy (linter) on stable Rust would ideally be part of the push.

Aside from the almost completed features in the pipeline, I only see procedural macros (macros 2.0) and whatever happens to make async code easier to write[1] really impacting day-to-day code for most people.

[1] I'd really like to see F# Computation Expressions instead of async/await. I know the language experts have said Haskell-like do notation doesn't work in Rust but I'm not sure if the F# tweaks would make it work or not.

> [1] I'd really like to see F# Computation Expressions instead of async/await. I know the language experts have said Haskell-like do notation doesn't work in Rust but I'm not sure if the F# tweaks would make it work or not.

I'd prefer a systems-y, zero-cost take on algebraic effects, similar to what OCaml is going to get. Could be much more extensible, and open things up to annotating whether functions panic or not, access global state, etc. Alas it's still a tricky research problem, even after all these years. There were some nice discussions from ICFP here - the comments strayed into talking about how effects might be implemented without a GC: https://www.youtube.com/watch?v=DNp3ifNpgPM

Is there a paper or writeup anywhere on what the algebraic effects system coming to OCaml is going to be like? (Does it have a name that can be googled?)

It's part of the Multicore OCaml [1] effort.

[1] https://github.com/ocamllabs/ocaml-multicore/wiki

You can already get “Monad comprehensions” through the mdo and mdo-futures crates.

Why anyone would name anything "clippy" again is beyond me.

One of clippy's authors and maintainers here (though I didn't choose the name); why would you name such a program "lint"?

For me clippy evokes the image of a well-meaning, if at times clumsy helper that tries to nudge you in the right direction. I find that very fitting for a tool that...well...tries to nudge you in the right direction of writing good, fast, idiomatic code.

Clippy is reborn from its ashes into a cultural icon; it made you react, therefore it's a fun name to choose. Kakoune uses a clippy ASCII art for its immediate help, it's nice.

> Kakoune uses a clippy ASCII art for its immediate help, it's nice.

Had to look this up - very cute!



Their choice of executable name is slightly unfortunate in Dutch, where 'kak' basically means 'shit'.

I think “kak” would be better translated as “poo”. Parents will routinely talk to their kids about “kak”, similar to the way US parents will use the word “poo”. The word “shit” generally has a much stronger meaning (and is therefore often obscured, as “s..t” or something similar.

I think "kak" still would be translated better as "shit", you wouldn't curse with "POO!". But in Dutch you can curse with "KAK!", just as 'SH*T!' in English.

Eastern Slavic languages like Russian also give a similar vibe to this word ('shitter').

Какаю would the translated to "I poo" (hence Кака would be "poo"). Срач would be the stronger word in Russian [1].

[1] https://en.wiktionary.org/wiki/%D1%81%D1%80%D0%B0%D1%87

What's wrong with this name?

Probably trademarks and copyrights.

Copyright doesn't apply to names, and the only US trademark for "clippy" is for medical equipment (and thus doesn't apply here) [1]. There doesn't seem to be any EU trademark for "clippy"

1: http://tmsearch.uspto.gov/bin/showfield?f=toc&state=4805%3At...

This is going to sound weird, but I would like to see a garbage-collected Rust. Take away the borrow checker, and you still have a modern language with UTF-8 support out-of-the-box, algebraic data types, pattern matching, a focus on performance, and great tooling (cargo + rustup = <3).

OCaml almost fits the bill (Rust is inspired by OCaml after all), but the tooling around it is lacking to put it mildly.

You should know that rust always intended to have owned/shared references, Rc<T> reference counting, and Gc<T> garbage collected pointers. It turns out that LLVM made precise garbage collection a hard thing to add on to the language inside of it's standard library. I believe recent changes to LLVM make this easier and it's still a planned feature in the future.

It still doesn't really meet your idea you probably have in your head. When people can choose between different types of pointers, people will choose rust's normal lightweight lifetime references 99% of the time. Gc<T> will probably only be used in those rare cases where an object has no clear owner. They figured this out in the early days of rust.

F# sounds like it fits the bill. ADT, pattern matching, performant, great tooling (multiple amazing IDEs, a REPL, etc.), and a huge ecosystem of software packages to use with it (all of .NET). It's my favorite general purpose programming language (can be used for frontend programming, server, mobile apps, etc.).

F# has hit a huge sweet spot for me in productivity, strong typing, inferred typing, multi-paradigm and syntactic sugar. The tooling just gets better and better. I struggle to think of a language that's so well rounded.

Couldn't agree more. My only wish is more people would use it.

My wish too! I have no issues with F# on Windows or Linux using .NET Core I use F# as my general high-level language and Zig as my C replacement/Rust alternative for low-level work. I can gradually re-write C stuff in Zig, and be productive.

  [1] - ziglang.org

I wanted to get into f# but had a hard time with tooling, cross platform. For example, I'd see a great library and the instructions assume VS while I'm on Linux. There are a variety of build tools and package managers.

As Python dev since 10 years I can't point fingers -- Python is probably worse though I've memorized the idiosyncrasies -- but I couldn't justify my way up the tooling learning curve in addition to the language curve.

(I work on F# at MS)

Do you remember the library? The landscape has changed dramatically in the past ~6 months with .NET Core 2.0 support. For example, I can use Fable[0] and Giraffe[1] with the .NET CLI[2] to build full-stack F# apps on my machine which runs .NET Core. The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support, but we're quite close to finishing that.

[0] http://fable.io

[1] https://github.com/giraffe-fsharp/Giraffe

[2] http://dot.net/core

> The big remaining blocker for most people to just jump wholesale onto .NET Core and forget anything Windows-based is the lak of Type Provider support, but we're quite close to finishing that.

Is there a viable cross platform ui option for f# on core?

Yup! Fable. In fact, a web app written in fable will even run in more places than a .NET Core app due to the reach of browsers.

I was looking at Brahma.FSharp and something else with type providers, both with Nu Get instructions, and I didn’t see how to get it working with VS Code.

Ah, yes, this is using Code Quotations to generate code into OpenCL. Useful, but unfortunately, not something that is likely to work on .NET Core for a number of reasons today.

Do you have a good learning guide and a development guide (setting up ide, vim, tools etc)? I want to jump start into f#

For learning the language, there is no better guide than F# for fun and profit. Start here[1], then maybe check out this series[2] and this one[3]. If you want to learn about monads and such, go through this series[4]. Look through this[5] page for other good stuff.

Unfortunately, the fsharp.org site is kind of out of date. I think that's mostly a function (heh) of the MS F# docs becoming much better (can be found here[6]). These instructions for getting a dev environment set up are pretty good[7]. If you hunt around, you can also find blog posts which may be a little more comprehensive[8][9][10].

[1] https://fsharpforfunandprofit.com/why-use-fsharp/

[2] https://fsharpforfunandprofit.com/series/designing-with-type...

[3] https://fsharpforfunandprofit.com/series/thinking-functional...

[4] https://fsharpforfunandprofit.com/series/map-and-bind-and-ap...

[5] https://fsharpforfunandprofit.com/site-contents/

[6] https://docs.microsoft.com/en-us/dotnet/fsharp/

[7] https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/

[8] https://atlemann.github.io/fsharp/2018/01/13/fsharp-on-ubunt...

[9] http://www.prigrammer.com/?p=363

[10] https://medium.com/@edgarsanchezg/four-easy-steps-for-instal...

Also a weekly roundup of F# news can be found here[1].

[1] https://sergeytihon.com/tag/newsf-weekly/

The problem is that it turns out that cyclic garbage collection is essentially useless, except for running existing code that expects a garbage collector to be present (e.g. JavaScript code if you are writing a web browser).

Since it's useless, not having it is great since you no longer have to worry about it and the problems it causes like random pauses, sawtooth-shaped and excessive memory usage and inability to use swap properly (although you have to worry about heap fragmentation, but usually that's not as terrible).

Also you'd need lifetimes and borrowed references anyway to have static guarantees like that there are no remaining references to mutex-protected data after you unlock the mutex, so having a GC as well actually increases complexity.

If i've understood you properly, i would phrase this slightly differently: because Rust doesn't have GC, it has evolved a lot of language and library features that make it practical to not have GC, and so adding GC doesn't make Rust easier to use.

I think there's a lot to that. I'd be really interested to try it, though, to see how it pans out.

There are plenty of language choices fitting nearly every feature set.

What I’d like to see is for one language to be possible to use “vertically” through a stack. That is - for example a C# systems version with manual memory that you can use instead of C interop for the small core of your app. Or, the opposite, a dumbed down version of Rust that works well for classic reference heavy UIs and similar.

rust at one point had garbage-collected references. And there's still Rc/Arc types for reference counting.

I get what you're saying though. Another poster mentioned Swift and indeed Graydon Hoare, Rust's creator, is now working on Swift at Apple. And I believe some kind of notion of borrow checking/lifetimes is supposed to be coming to Swift in the future?

Yes, the initial support is already there in Swift 4, it is called enforced exclusive access to memory in Apple documentation.

Not all that familiar with Rust's history or anything but why would he leave to work on Swift at Apple? He creates a language which is getting a huge amount momentum and praise around it, and decides to do something else? Must have been a lot more money, because a situation like that don't come up very often.

He didn't leave to work on Swift; he left, then got a different job, then left that job eventually to work on Swift. I'm being vague because well, it's his personal life, and he'd generally prefer people not talk about it too much or read too much into it.

This sounds a lot like Nim to me. Give it a go if you haven't already. It's a systems programming language that primarily uses a garbage collector.

> Ocaml almost fits the bill, but the tooling around it is lacking to put it mildly.

I know the Reason guys want to tackle project setup / build / deps in addition to their syntax changes. I've found the current release's bsb toolchain to work pretty well for js targets but I haven't tried to set it up for native compilation.

I've built several toy projects with ReasonML. I found the overall experience fairly positive, so please take this comment kindly.

I'm concerned about the ReasonML -> OCaml -> Bucklescript -> JS compilation chain. The laws of leaky abstraction pretty much guarantees this is not a robust way to do things.

I also wished the ReasonML folks started from scratch, instead of inheriting OCaml's baggage (no forward references, a plethora of file types to deal with, no UTF8 strings without bringing in an external lib, and so on).

No builtin utf-8 strings is a good/bad thing is debatable.

You don't need to use bucklescript toolchain to write Ocaml, it has a very good package manager, the build-system tooling is getting better, already has great editor support for many years now(merlin).

I think the tooling scene is much better than Haskell. Not sure what you mean by "no forward references"?

> Not sure what you mean by "no forward references"?

I'm guessing they are talking about having implicit mutual recursion between items in a module, like Haskell has.

> Not sure what you mean by "no forward references"?

I probably got the name wrong, but it's the ability to use a function before it is defined.

In OCaml/ReasonML, you'd have to use the rec keyword and structure your codebase in a particular way to define mutually-recursive functions. It is a small but noticeable papercut, especially since recursion is so common in a functional language.

May be the word I’d “hoisting”

There's a similar chain for F# running with Fable:

F# code (with a catch) --> F# AST --> Bable AST --> JS

The big thing here is that the F# code you write has slightly different semantics than "normal" F#. That's because the runtime environment is different, and so you can't escape that. Rather than attemp to gloss this over, the Fable creators are pretty explicit about this, including documenting each of the (small) differences. The result is pretty good. Abstractions don't seem too leaky from my vantage point.

There ist no ReasonML -> Ocaml compilation step in that chain, ReasonML is just another syntax for ocaml.

There is still a necessary syntactical transformation sstep via `refmt`, and that transformation step does occasionally break.

Yep, that's exactly what I would also like to see.

AFAIK there is some work on a GC in Rust, but it doesn't take away the borrow checker like you wished ;) So you will still need to use `.borrow()` and `.borrow_mut()`.

A language similar to Rust but with GC (and no borrow checker) could be quite useful for a lot of applications out there. Basically Go but a more "modern" language.

Just seeing this. You might be interested in my previous comment here: https://news.ycombinator.com/item?id=16145940

That's easy, just change your program so that every value of type T is now a value of type Arc<Mutex<T>>.

Reference counting does not handle cycles.

Use Arc::downgrade() to get a Weak<Mutex<T>> as needed. Weak<U> is like Arc<U> but does not affect the value's reference count.

This sounds like Swift :)

(ARC, not tracing GC, but still.)

If Arc counts, then it juste sounds like Rust actually ;).

ARC, not Arc.

ARC is automatic reference counting. Arc is Atomic reference counting.

In Rust you still have to manually .clone() to addref an Arc. In swift you don't. This is a major difference ergonomics-wise.

I dunno if I agree, the borrow checker in Rust requires a lot more active thinking and intervention to get memory right. Objective-C and Swift ARC is really straightforward and there are few gotchas. Kinda like GC.

If you use Arc everywhere you just end up with the same behavior than Swift (except for closures I guess).

Small note: Swift's ARC and Rust's Arc are different: Rust's Arc is atomic reference counting, while Swift's is automatic reference counting.

The acronyms are different, but at runtime they're pretty much the same: the only difference is the Swift compiler inserts the clones that a Rust programmer has to do manually (that is, Swift retain/releases are atomic too).

Yes, I should have elaborated more, thanks :)

I would like to see a different GC rust... an ability to integrate into an external GC system that it is embedded in, like Javascript or Java or whatever else. In other words, `Gc<_>` would mean "owned by the other runtime". I think there was a proposal like this, though I am not sure what happened to it.

I agree. Part of whats kept me going is the language is very nice, even though I don't always need borrow checking.

I wonder how threading would work without the borrow checker though. It would be cool if you could still have the "fearless concurrency part".

I have a similar desire. OCaml and others push heap-allocated reference types by default (limiting your options for controlling allocations), and many have weak tooling and library support. F# looks neat, but it seems to have a lot of baggage relating to C# interop. F# also doesn't compile static binaries yet. I think I decided the best shot is to build a language that compiles to Go, since it has the right semantics, great libraries and tooling, and a world-class runtime (GC, painless async IO, lightweight thread scheduler for real parallelism). Obviously this is still a huge effort and probably a pipe dream, but its the path of least resistance to get a "Rust with GC".

Scala Native may sort of fit the bill

I am surprised no one already mentionned Scala. It perfectly fit the bill ans is even more mature !

The main problem of Scala is that it brings in the whole JVM. That's awesome for certain kinds of apps, but not so great for other things like small tools. I have high hopes on scala-native, though!

Java 9 / Jigsaw should make small self-contained executables possible. Startup time could be an issue, though.

The biggest difference is that Scala requires JVM (or JS).

But if you are willing to accept runtime GC, a JIT runtime like JVM/Node might also not be out of the question.

So Scala Native would be spot on, if it were ready for production use.

Garbage collected allocation is coming. There's even an rfc I think. Manishearth is working gon it

The error messages are indeed _mostly_ marvelous (and there's an ongoing effort to make them even more marvelous). Often working with `rustc` feels like pair programming for introverts. But here's a question: `rustc` often gives _actionable_ advice - how far can can you get just following that advice? You can make `rustc` happy by following suggestions, but may end up puzzled as to the reasons for the changes it suggests.

> But here's a question: `rustc` often gives _actionable_ advice - how far can can you get just following that advice? You can make `rustc` happy by following suggestions, but may end up puzzled as to the reasons for the changes it suggests.

Not-crazy suggestion: add a `--why` option to rustc that doesn't just shout (helpful) error messages at you but actually explains the architectural theory of why the error is occurring and provides documentation links that help outline the canonical "right way" to do whatever it is you're trying to do.

The idea being that rustc applies a ton of heuristics and intelligence (perhaps by analyzing nearby code) to guess what your high-level goal is.

There have been a couple of "programming helper" AI-type apps float past here recentlyish; that's what I'm getting at.

The reasons I think this would be a good idea is that

a) this would be really really hard to get right, but AI R&D is pretty much at the point where you could put something like this together and build it into the compiler and pull it off really well

b) rust seems to have a ton of energy behind it so if any language was going to implement this, it looks like rust has a fighting chance to actually get it done

c) rust hasn't stabilized yet so _now_ is exactly the time to fold something like this in. it would need to be integrated as early as possible as a bolt-on afterthought would never work the same way

I like the idea but Rust has so many issues in front of it I’m not sure it has the energy to invest in something like hay.

Yes, the compiler is a permanent construction zone and there can only be so many projects on site, let alone workers. So this feels like something that _should_ be doable outside the compiler, but using its metadata. (BTW, "rustc --explain <error-code> does at least give you some nice text)

Sounds like having --why output --explain for each error might be the 80% fix?

Having some understanding of difference between value and reference types types (from c or c++) and reading documentation a bit might be necessary. Error messages sometimes also contain links to documentation in case you have no understanding of the topic. The most common problems I had so for was due to incorrect level of indirection. In such cases the cause is quite clear function returned/expected reference/value/Option<val>/Option<&val> and you tried to assign it to something else. Suggestions help learning how standard library API behaves without opening API reference. In case of unwrapping Option or limiting borrows lifetime the code may get a bit messy. In such case I recommend reading documentation/searching internet as there might language or standard library feature (sometimes even in the link given by error message but not message itself) that helps writing it cleaner without brute forcing the code. Due to type checking it is difficult to mess up worse than making ugly code or moving away object you didn't want(which will be pointed out by compiler if you try to use it afterwards).

Oh yes - there will be some explicit type like std::vec::Vec<&std::string::String> in the error and that all-important '&' gets lost in the verbosity. Definitely necessary to learn to see the needle in that haystack. (Some have proposed simplifying the explicit types if no confusion results, but this could always done by a post-processor. I saved some of my sanity when doing C++ this way)

> and that all-important '&' gets lost in the verbosity

Perhaps some console colouring could help as well. I'd really like some type diffs on type mismatch errors (I think Dotty has this?). That could be super handy for quickly diagnosing errors - speaking as a reasonably experienced Rust user here.

Well, we already have a christmas tree colour issue. I think rustc could do better here - check whether types differ by only '&' and put out a hint. That is, by adding/removing &, could the error have been resolved?

> value and reference types types (from c or c++)

Applies to other languages as well.

Many languages handle this internally; essentially all functional languages and all dynamically typed languages.

And many others handle this externally, including some functional languages, in case you want a list, I can provide it.

I'm interested in functional languages with a C/C++-like distinction between values and pointers!

Common Lisp (make-array, dynamic-extent, make-pointer, incf-pointer, ...)

F# (nativeptr, struct, nativeint, fixed, byref)

ATS (ptr_succ, ptr_prev, lam@, addr@, ...)

I've seen at least a few articles to the effect of "I wrote the code I wanted, then kept running rustc and changing whatever it told me to until it finally compiled, and it worked."

> You can make `rustc` happy by following suggestions, but may end up puzzled as to the reasons for the changes it suggests.

This is how I felt, but it wasn't bad: I think you start to pick up on the patterns. In other words, learning isn't short-circuited after you've made rustc happy, even though you're still a bit puzzled - you'll carry the experience along with you and continue to learn from it later.

https://github.com/killercup/rustfix is an experiment in exactly this.

Elm is like the next level of this.

Agreed. I've played with Rust on and off since ~v0.8. I tried to get through the Matasano crypto challenges a few years ago and gave up after hitting a few language hiccups. I recently gave it another go, and it's much easier to use now.

I must have written around a thousand lines before needing a lifetime annotation, vs. something like 30 lines two years ago.

The Matasano crypto challenges seem interesting and remind me of Project Euler. I used the latter to help learn Python a little, and I think the former would be even better for Rust!

Out of curiosity, how is the embedded story (for both bare-metal and RTOS) in Rust nowadays? I took a look early last year, and I remember feeling that the ecosystem still wasn't as mature as I liked.

There's svd2rust [0] and dslite2svd [1], which is basically "bindgen for hardware". Please do correct me if I'm wrong, but from what I understood [2], most SVD files leave out a lot of information so a lot of what svd2rust generates is unsafe. Seems like the only way around that is to patch the SVD files. Is this still the case?

In addition, what about compiling with no stdlib? And how does that interop with existing Crates (ie. do new "embedded-specific" Crates need to be created?)

Super excited to see Rust gain traction! I'll definitely take another shot in my free time and see how the ecosystem has matured.

[0] https://github.com/japaric/svd2rust

[1] https://github.com/m-labs/dslite2svd

[2] https://www.reddit.com/r/rust/comments/687b3l/embedded_in_ru...

I tried exploring no_std Rust recently, and found it to be quite frustrating. After just using a Result type I was getting errors of things like `eh_unwind_resume` being undefined. Toggling LTO rectified my problems but didn't give me much confidence in reliably using no_std

`-C panic=abort` compiler option should have fixed the problem. If you want to be able to intercept panics, you need to provide implementations for `eh_unwind_resume` and `eh_personality`.

Perhaps it's just an issue of me not being educated enough with this kind of low-level Rust. Setting panic to abort in the cargo config did indeed fix `eh_personality` being undefined, but `eh_unwind_resume` still seems finnicky. Building in release will work, but building in debug will still complain

I'm a little rusty on the topic, but it seems ([0]) that adding `#[no_mangle]` before `panic_fmt` should fix it.

[0] https://github.com/rust-lang/rust/issues/38281

Even specifying `eh_unwind_resume` as a lang item gives me a linking error in debug builds.

Did you define them exactly the same way? Every aspect has to be identical; extern, no mangle, function name, arguments, lang item.

If this happens to be open source, I can take a look at it.

I just whipped this up yesterday to test if I was still having the same issues. Debug fails to build with a linking error "undefined reference to `_Unwind_Resume`". Release build works fine.

I'm using rustc 1.25.0-nightly on Ubuntu 17.10


The lang item symbol names need to be prefixed with rust_ like this: https://gist.github.com/steveklabnik/5abd59a8fe7e5abda3db58b...

This didn't fix the compilation errors for me. I can set my own no_mangle pub extern `_Unwind_Resume` function (without declaring it a lang_item) and fix the undefined reference that way, but I'm pretty sure that's not how one's supposed to solve this

Hm, it compiled for me. Well, it didn't know about the C functions that were being linked in, but it didn't complain about the lang items.

You should file a bug, maybe.

For low level code, do you really want to abort on panic? Rust error handling is easily my least favorite part of the language, combining the disadvantages of exceptions and return codes.

Many do, yes. Panics are non-recoverable errors, and aborting produces leaner code, which is important on embedded.

Panics are recoverable though

They’re not guaranteed to be, so you can’t rely on it. You can say that you do, but then you may cut yourself off from the rest of the ecosystem. Libraries generally can’t rely on either behavior, applications choose.

And that's why I think the Rust has a worst-of-both-worlds error handling strategy.

Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018.


Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position

Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs.

Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.

Thanks to Rust's great C interoperability, hybrid can be a great approach. I've really been enjoying re-writing sections of node.js applications in Rust. It fits fairly seamlessly and can really broaden the scope of what is possible.


Writing GUI with rust is totally possible: http://gtk-rs.org/

It is possible, but far from productive, which I learned exactly by trying to use Gtk-rs to port an old basic Gtkmm demo, that I used for a C/C++ Users Journal article.

Wasn't Rust invented to write a GUI? A webbrowser can be regarded as a kind of GUI.

There aren't any good GUI libraries available for Rust at the moment. GUI libraries are huge and take an enormous amount of work to get right. It's typically only the most popular three or four languages at any given point in time that have satisfactory GUI libraries. Rust has the additional burden that it is far from trivial to wrap Gtk, Qt or other C/C++ toolkits in a safe manner.

Didn't Mozilla write a GUI library before they wrote Firefox? It would strike me as odd if they didn't.

There is no mature GUI library for Rust that I'm aware of. I believe the servo project is focused on writing a browser rendering engine, not a browser GUI. It certainly has not so far yielded a GUI toolkit that can be straightforwardly used in other projects.

No, it was invented to write a generic (web) rendering engine.

So, even if we consider a web app as a GUI, Rust wasn't invented for writing that (you still use CSS, HTML, JS etc for that part). It was invented for writing the backend for that UI.

In other words, Rust is not GTK (a UI library), it's C (the language the UI library itself is written in).

Ok what is the GUI of Firefox written in/using?

Until recently-ish something called XUL, a markup language for UI (similar to HTML, or even better XAML). Not sure if they've moved on since.


Rust was invented for low-level parsing/rendering code. The high level GUI in Firefox is not implemented in Rust for all I know.

Yes but "possible" and "pleasant" are very different :(

Yeah, but the parent point is that "possible" is a very low bar.

gtk-rs needs a macro package to parse a HTML or a XML snippet and generate GUI, with embedded rust code in appropriate place. Look at Yew for example: https://users.rust-lang.org/t/yew-a-framework-for-client-sid... .

> Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity

There is nothing in Rust that makes it inherently unfit for APIs or the web. To dismiss the entire language is simply lazy. Having GC also doesn't necessarily make one language superior to another.

While http ecosystem is still in active development, if there was really a choice between Rust and JS for e.g. writing an API I would go with Rust in a heartbeat.

The thing is, the choice isn't between Rust and JavaScript, rather between Rust and a list of other languages.

Having a GC means having easier ergonomics to write data structures and distributed algorithms.

I do like a lot Rust's type system, just the ergonimcs aren't quite there yet.

> just the ergonimcs aren't quite there yet

You're correct, but "Rust isn't easy to use for purpose X just yet" is substantially different from "Rust is inherently unfit for X"

Except it takes 10x time to write anything backend related. Why would you choose Rust over Java / C# / Go ect ...?

I don't buy this claim. I've written many services with Rust and I'm not slower with it that I am with GC'd languages I also need in my work, such as Clojure, Scala or Python.

Please explain me where is this idea of slow development time coming from? Is it only because people try Rust for two weeks, cannot get the lifetimes and decide the development speed is slow?

Except that number is completely made up. Why do believe it takes ten times as long?

What Rust framework replace Java spring or equivalent, none of them so you have to write everything yourself. Rust doesn't have any ecosystem to write service side services so you're going to spend time by just re implementing a framework.

While Rust doesn't have many full-stack frameworks, many ecosystems don't favor full-stack frameworks. Rust has tons (arguably too many!) microframeworks/libraries.

I do agree that there are holes, and that's part of being a young ecosystem, but I think you're being a bit too pessimistic. I understand this deeply, as I was once too! As things have evolved, my opinions have changed, though.

> any GC language is a better fit in terms of productivity

But that's not the only constraint. If you want to save memory, due to the environment you run on, or your workload, a non-GC runtime can be pretty awesome.

Just because a language has a GC, doesn't mean it doesn't have language features to have more fine grained control over how memory allocation takes place, or even when the GC has to run if at all.

In that case it's no different from Rust, Rust has a GC option (ref counting). It's limited and opt-in then you still carry the cognitive burden of memory management, you have to think when to use it. But if you need that level of control, you'll need to think about memory anyway.

And in my experience, it's way easier to reason about allocations in Rust that it is in Java (automatic type erasure if you want to use generic code) or Go (how will escape analysis behave in that case ?) for example. Rust traits are way better than C++ interfaces in that regard also.

UWP has ref counting, garbage collection (via C#), and stack allocation. It does native compilation to boot, unfortunately it isn’t quite universal.

And is built on an improved COM, thus requiring first class support for it, by any language targeting UWP.

Ya, that’s right. But I think this is only C++ and C# at the moment.

JavaScript on Chackra's engine, VB.NET, C# and C++. F# support is still to be done, due to how .NET Native handles MSIL.

Borland was in the process of doing it for Delphi and C++ Builder, but I don't know the current state. Originally they were only replicating the Metro UI, back on Windows 8.

Isn't it universal windows? :)

Yes, runs universally on all Windows 10 versions.

Java and Go are just two examples, and surely not those that I had in mind.

Rather languages in the Oberon and Modula family, D, Nim, Eiffel, C# as of 7.2, Common Lisp, and a few MLs.

If you do RC everywhere, using library types, it is slower than a tracing GC, and still not as productive.

You're comparing a language to an OS and three GUI frameworks.

I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them.

Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolkit would look like, particularly because the traditional tree-of-widget-objects design of C++ GUI toolkits appears a bit inconvenient to realize within Rust's stricter semantics.

IOW, "are we gui yet?" might depend on some sort of new written-in-Rust GUI toolkit to appear. There's 20 years of work by many hundreds of people in Qt, many of whom rallied not just around Qt specifically, but around projects using it. Getting that many people moving isn't easy. Alternatively, major progress has to be made on bindings and bridging to the semantics of other languages in Rust.

That said - of course C++ was around quite a while before being adopted by Qt.

Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.

> a sane electron type library

There's no version of that concept that's sane at this time, though. Wrapping full-fidelity APIs the browser engine has access to in a lossy abstraction layer of shoddy web platform APIs isn't a practice Servo can improve upon. It takes improving those APIs.

There's a project called Limn trying to do this. I doubt it has solved the ergonomics issue though.

Anyone pinning hope on limn should take a look at the activity on the project since start of December.

You're talking about just over a month. I think it's a little unfair to expect people to maintain hobby projects every week of every year. Particularly over Christmas and the new year when our lives are often busier than usual.

To use a personal example, an open source project I actively maintain only yesterday saw it's first commits since the end of November. But I am still very much committed to that project.

I wouldn't be too pessimistic about a project just because the main author stopped pushing changes for one month in the holliday season. It also happened in August for the same project and work resumed later at a fast path.

If the project has only one main author, I would be. Even more so if they are on and off and not paid for it. Heck, TextMate and somewhat Sublime Text had such issues with 1 single dev, and those are projects that actually make them money...

That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute (and the community did want to contribute when it looked like development had stalled). Where as limn is open source so if it does prove worthwhile but development stalls it would be trivially easy for any number of other developers fork the git repo and carry on the work.

>That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute

It is fair, as whether it's possible for the community to contribute is a moot point if the community wont contribute.

Heck, GTK+, which is used by millions, had just one person working on it full time a few years ago (not sure if changed since), and lamenting how there's no community help in the project's blog. And that's for a hugely used and know project. I doubt a Rust UI lib would get more than that.

> It is fair, as whether it's possible for the community to contribute is a moot point if the community wont contribute.

Well as I had already said in my previous post, the community did want to contribute to Sublime Text but couldn't. Hence why I posted my rebuttal stating the original examples weren't really fair.

Your revised example is far more apt however in a roundabout way it just reinforces my original point. Since, by your own admission, any Rust UI lib is unlikely to see many dedicated contributors; it would be daft to criticize limn for a trait that you have just acknowledged would be typical for any Rust UI library.

To put things another way: if the project had stalled for months at a time then I could understand people's skepticism trusting the maintainer. However a brief period without commits during the holiday season seams more than reasonable for an active project. Particularly when you even comment afterwards that any similar project isn't likely to see more active development anyway. So why single this one out as being less trustworthy? It feels very much like your applying double standards here.

> Heck, GTK+, which is used by millions, had just one person working on it full time a few years ago (not sure if changed since), and lamenting how there's no community help in the project's blog. And that's for a hugely used and know project. I doubt a Rust UI lib would get more than that.

This is not true for GTK+ 3. GTK+ 2, however, has been in maintenance mode since the introduction of GTK+ 3 and has been in that state since.

> it would be trivially easy for any number of other developers fork the git repo and carry on the work.

Expecting that is wishful thinking. The fact of the matter is making something like that is an insane amount of tedious work and 99% of the time it is started up by people playing around with the concepts and abandoned once the initial fun problems are tackled. Something I am sure will happen with limn.

I agree however that could equally happen with any similar Rust UI library that isn't backed by a corporate entity. And seeming as there isn't any corporate backed UI libraries for Rust (at least that I'm aware of), you're literally no worse off with limn than you are with anything else.

Qt uses way more than vanilla C++ though, it practically has its own dsl for a whole host of things.

This often gets over-reported; old memes die hard.

There's a small number of macros that a custom preprocessor expands to (very pedestrian) generated code, but they are optional to use (though it's certainly uncommon not to use them) and these days there's template-based versions of some of them that are preferred and steadily finding adoption over the macro ones because they're superior. Beyond that there's a few more normal preprocessor-based macros that are entirely optional.

In that sense Qt also tracks vanilla C++ very closely and has adopted features from newer language versions at a fairly steady pace and swiftly for such a large production library set.

None of this matters much to my point though - that was about much more basic language semantics like classes-based OOP and the absence of ownership rules.

No, I am comparing the selection of a specific programming language, given the existence of tooling for a specific purpose.

I need to fulfil task X, with tool Y, then I choose language Z among those supported by Y.

Not I chose language Z, then try to find some kind of Y, that helps me solve X somehow.

When C++ came into the picture we got Turbo Vision on MS-DOS bundled with Borland compilers, Apple adopted Metrowerks tools and used PowerPlant, OS/2 promoted CSet++, UNIX guys were into Motif.h++.

Then came Windows, Borland pushed forward with OWL followed by VCL. Microsoft created MFC, adopted by Symatec and Zortech compilers.

Apple eventually went Cocoa, and Microsoft UWP as of latest.

And then there is Qt, literally the only game in town for C++ GUIs not related to any OS vendor.

Followed by what in possible in Java and .NET eco-systems.

All with good visual tooling support, allowing for productive workflows between developers and designers.

I am not saying that Rust some day won't catch up, and offer something similar in terms of productivity.

I hope it does, but right now in 2018 it doesn't.

Isn't Rust perfect for severless?

Since cloud providers do all the plumbing, Rust would only have to deliver a tiny Linux binary for the function.

I do not think it will be tiny after including all the required and atm non existent SDKs

> Nobody with a sane mind would write C or CPP micro-services

why? I do this all the time. Maybe I should check into a nearby asylum.

The point isn’t that no one does it, its that its hard to do right.

...and that is flat out the case for c++, unequivocally.

In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at.

Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services.

Its definitely a good goal for the year~

> ...and that is flat out the case for c++, unequivocally.

Arguably, this is why Google made go.

But I'm not sure c++ micro services are a terrible idea. I think the real problems come with a) feature creep as opposed to writing new micro services, and b) the temptation to write "fast" c++.

Just writing plain obvious c++ should give you a leg up on most languages (esp for micro services). But then, rather than refactor and think about the algorithm and data structures (and get a 10x performance benefit from a simpler solution), you could probably get a 2x improvement from a more convoluted, "special" c++ implementation.

And that's where you're likely to encounter elder horrors lurking.

[ed: I'm however more and more convinced there's no such thing as "plain obvious c" that doesn't have a number of serious issues along the lines of not checking mallloc return values, to utf8 string handling etc.]

I also do this. I make use of Capsicum/seccomp-bpf and jail/chroot to a ro mountpoint, use SSP, ASLR where possible, ... But I still use C as my primary programming language. I've also written code in golang professionally for a year or two.

It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.

Even using C++ in embedded is an issue, mostly cultural.

A common theme in the C++ community is to advocate C++ to devs that only see Assembly and C89, and don't see any reason to move beyond that.

Most recent example "Embedded & C++ - Meeting 2017 Keynote"


It must depend on what you're building with it. I haven't seen any reason why it couldn't be used for serving up data for an api.

But as far as using it as a full featured web framework, a la Rails, Django or even Laravel, I can see why people say it's got a long way to go.

That said, I haven't built anything production or large scale in Rust, so I can't claim to be an expert.

Because your code has bugs and/or security vulnerabilities. It's pretty safe to assume this without looking at your code

Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.

Of course. Code is hard.

Using a safer language makes it easier and less prone to out-of-bounds memory accesses.

By using C/C++ you're choosing to make a hard problem harder.

And slower or impractical even for some things. Maybe we should write a real-time media codec in python 'cause security. I don't understand why you, like the OP, make these sweeping generalizations as though all of engineering is black and white. Sometimes, I reach for a higher abstraction, sometimes not. It depends on the problem domain.

Oh and btw, "out of bounds memory accesses" are not the primary source of security vulnerabilities at all. In fact, such out of bounds access is more likely to just make your program crash (which is a good thing).

C++ does have a practical, memory-safe subset[1]. Recommended for anyone writing internet facing C++ code.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

I wouldn't be so sure lower level code necessarily has more vulnerabilities. It's certainly easier to find the vulnerabilities because the attack vectors are well-known.

Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a simpler language.

What complexity adds up?

>Maybe I should check into a nearby asylum.

If you do, make sure it says "believes in micro-services" on the referral ;-)

I just mentally edit "micro-services" to "services" any time I read it hehe.

What, do you edit the "web" out of "webscale" too? Certifiable.

And "REST" to "HTTP"

I get the impression Go runs the microservice space. It's built for it and is incredibly fast despite the GC. I don't see Rust claiming that position anytime soon.

Where I live and work, golang is only used at one major client (because they’re US based, the decision must have happened elsewhere.)

Everything else is Spring Boot (java), Akka (Scala) or Nodejs. Apparently nobody wants to embrace a language designed for offshoring, so no Meetups, noisy user groups and so on... even Clojure is more popular

Golang is a language designed for offshoring? It was invented at one of the largest engineering orgs to be used in house

In the words of Rob Pike:

"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. – Rob Pike 1"

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"

So a language that makes it quite easy for enterprises to deal with developers as cogs.




I don't see what that has to do with offshoring. Developers of the kind Rob Pike is referring to exist everywhere in the world.

I do enterprise consulting, in projects which happen to always have some kind of offshoring involved.

Projects where the languages are easy to pick up and anyone can do it, are always the first on the pipeline to give away.

Are you really saying that Rob Pike is part of some kind of conspiracy to offshore all the coding that's currently being done at Google SF? Golang has been around for a while now, and there's no sign of that happening.

No, I am just stating that the goals of having the language designed for such target audience, can have that as side effect.

Just like it happened with Java.

Your responses to K0nserv and singhrac suggested that you were defending the claim that golang was "designed for" outsourcing.

If you're making the weaker claim that Go's design "can" have the effect of triggering outsourcing, then that's speculative and consequently rather difficult to refute. But you haven't provided a single piece of evidence that this has actually occurred, so far as I can see.

I was making the claim that can be a side effect of its design and the way the community is against common features in modern languages, deemed too complex.

Lets see how it looks a few years from now, given that it is becoming a mainstream language thanks to Docker and K8s adoption.

Many of those features (e.g. generics) are in Java and/or C#, which are nonetheless widely outsourced.

True, however Go is like a Java or C# 1.0, they did not start as they look today.

So Go is in the right track to follow their path.

It's pretty bad that people outside the SV can code /s

Exactly. :)

Software is more than just language features. Rob undoubtedly meant that he wanted it to be quick to be understood by a vast majority of Googlers, so that they can focus on writing good software.

Yet Google is known for having one of the hardest hiring processes, where they even give the candidates CS subjects to study before the interview.

He really said they're not capable?

Rust's USP over Go isn't more speed, it's better abstraction, and better correctness. Go is definitely a good tool for microservices, and it isnt going anywhere. But writing Rust is a joy, and I wouldnt be at all surprised if it also carves itself a niche in this area.

I'm actually writing a lambda function in Rust at work right now! Whilst I could do it in Python, it was straightforward enough to be a good first thing to try with Rust and it's actually been easier to write than I anticipated.

Plus the performance benefits will be nice.

Thanks for mentioning the page. I'm about to write a simple JSON/HTTP service and decided to use Rust but I was wondering why the author would not use Rust for web services.

Just out of curiosity, how many web framework platform are originally written and compiled in C? CPython, udev, node, v8, ... rust?

IIRC, the rust compiler started out as an OCaml project, but is now self-hosting.

This is true.

The platform may be written in C. The OS you're running microservices on is written in C/C++.

It doesn't mean that your services are written in C/C++.

It is not about languages. It is mostly about frameworks. I want to write my next web project in a mature framework.

Just an idea: I wish there was an official wiki in the lines of Arch Wiki that shows how to do things with Rust with lots and lots of examples.

True there is the Rust Programming Language v2 book and several other learning resources online, but they all carry redundant information and pass it on the user to discover what they want to learn. A legendary wiki which acts like a cookbook of all things Rust could be awesome and anyone can pick what they want to learn about and go at it.

I would happily contribute and do it, but I'm just starting to learn Rust. Perhaps it is easier for other experienced Rustaceans to do it right.

Thanks for the link.

I thought it was a small effort to show around the language features. Like a live(runnable code) version of the Rust programming language book. Very useful for someone trying learn the language feature by feature.

What I'm writing about is a how-to style wiki. For example,

How to do things with Rust:

How to read from stdin?

How to read and write from a text file?

How to make a REST API call from Rust?

How to parse JSON content in Rust?

How to connect to PostgreSQL in Rust?

How to issue Unix commands to a remote host via SSH using Rust?

How to create threads for parallel work in Rust?

You get the idea..

The Rust Cookbook has made a start on this too! https://rust-lang-nursery.github.io/rust-cookbook/

Thanks for posting the link. Precisely what I was talking about! They are very useful to play around with the language ecosystem.

If I learn something new, I'll try to add to their repo.

IMHO stack overflow was meant to be exactly this.

Perhaps this is not exactly what you are looking for, and I don't know if the examples are idiomatic, but you can check http://rosettacode.org/wiki/Category:Rust (follow the links in the section 'Pages in category "Rust"', there are almost 400 examples)

Surprised no one mentioned the long compile times yet.

For me, while I'd really like to try Rust, these are a deal-breaker.

Looks like incremental compilation has been enabled in nightly: https://github.com/rust-lang/cargo/pull/4817

That's a welcome improvement from last time I looked at it.

Does anyone know a ballpack figure for how many LoC/s you can expect on a beefy workstation?

It really depends. That is, thanks to monormorphization, 1 LOC in your source doesn't necessarily mean 1 LOC compiled by the compiler.

Furthermore, this is the start of incremental: we have more stuff coming down the pipeline.

Anyone has suggestions on learning rust for a python programmer who is also not strong on systems concepts?

Read the books, write code. When you'll encounter lifetimes, it's good to remember that lifetime annotations are descriptive and not prescriptive. You can't change lifetime of a variable by adding lifetime annotations.

For example, local variables of a function get destroyed on function exit no matter what and you can't prevent it by adding lifetime annotation to a local variable reference you are trying to return.

That was a stumbling block for me.

You summarized it so well ! It was also a huge source of confusion for me in the beginning.

Would you mind if I made a pull request to the Rust book adding your explaination to the lifetime chapter ?

While it doesn't have this literal text, it already does have the equivalent: https://doc.rust-lang.org/book/second-edition/ch10-03-lifeti...

> Lifetime annotations don’t change how long any of the references involved live. In the same way that functions can accept any type when the signature specifies a generic type parameter, functions can accept references with any lifetime when the signature specifies a generic lifetime parameter. What lifetime annotations do is relate the lifetimes of multiple references to each other.

Cool. I haven't read the second version of the book, and I read the first version about two years ago I think. Glad to see this difficulty is now covered. Carry on with the great job Steve :)

Ah ha! Yeah, it's quite different.

Thanks :)

I wouldn't. Feel free to use it. But I have the impression that the Rust book contains something to that effect.

"Descriptive and not prescriptive" part probably comes from stackoverflow. I don't remember exactly.

I'm not sure where I heard it, but I certainly repeat it. It's not literally in the book though, I'll also reply to your parent about this.

Read the rust book and actually build something with it. There's a lot of stuff in Rust that you just never have to consider in Python so there's no easy way other than diving in. Actually, Programming Rust might be better, but it's not free.



Upvoted for Jim Blandy's book. That man can teach!

For a python programmer some parts of Rust might feel too low-level and out of reach. However that is not a big issue. I would suggest you get comfortable tooling first, intellij rust plugin was awesome when I last checked it out. It comes with autocomplete, on-the-fly syntax checking etc. out of the box. The Rust compiler has very sane and understandable error messages (at least for basic tasks) so that will guide you a lot. I would also advise you to get on #rust-beginners on irc.mozilla.org, if you have any questions you will get instant help, which is a huge benefit :).

Lastly, I would first advise you to work through https://learnxinyminutes.com/docs/rust/ to get a feel of the language (like dipping your toes into the water). If you like what you see, then continue from the Rust book: https://doc.rust-lang.org/book/second-edition/ .

And most importantly remember to have fun!

a big part of the early Rust community comes from Ruby, so Rust as an entry to systems programming is really common.

Mozilla's IRC server has a #rust-beginners channel that is like, overwhelmingly helpful. Go and ask stupid questions.

"The Rust Programming Language" is good:


Knowing the difference between the stack and the heap, and having a picture of it in your head and understanding which variables go where, and what happens to the stack when calling and returning from functions, is pretty important. (Python wouldn't give you this intuition, although programming in something like Java might.)

I half-assed learned to code in C++ for scientific purposes. Later I got deeper into Rust, and it's made me a better, safer C++ programmer when I run into C++ code.

Hopefully I am not overstepping bounds by mentioning my book, but I encourage you to take a look at Rust in Action by Manning. It's written for current programmers who want to learn Rust as well as enough of the systems programming concepts that seem to sneak into Rust docs and discussion.

I appreciate your hard work and sacrifice.

Really looking forward to learning from your material, when it's ready.

The best thing you can do is to start! Your background sounds similar to mine. V2 of the docs are really good. I've called them my favorite piece of technical documentation somewhere on HN before.

Anyway, the other comments about reading the docs and building things are correct. I'd just point out two things in addition.

1) Don't feel like you have to go write some impressive low level application just because the language is lower level - fizzbuzz works fine too.

2) Don't worry too much about whether you're strong enough on systems concepts. It's not a class you fail if you show up unprepared for; it's (presumably) play time you're engaging in to scratch your own itch. You'll make mistakes but that's not something to be avoided, it's the only way to learn.

> learning rust for a python programmer

You might give Nim[1] a try.

Coming from Python, you might find Nim's syntax (and significant whitespace) familiar. It took me (also a Python programmer) a week or so before I was able to write small programs in Nim.

(Don't let "not yet v1.0" to turn you off)

[1] https://nim-lang.org/

Depends what is your goal. Learning a language with decent type system? Learning a language with lower level access to operating system features? I would suggest to learn OCaml because it got really popular in 2017 thanks to Facebook & Bloomberg, it has an amazing type system and you can use it to build CLI tools and web pages (Reason/Bucklescript) with an insanely good tooling (utop, jbuilder, merlin) and the community is probably the best community of software engineers I have encountered recently. If you are interested in lower level coding there is Mirage as well.


I used OCaml a few years ago and I thought it was an excellent language. Despite being powerful it was really easy to learn.

One thing that put me off in the end was that it didn't support native OS threads (I have the same problem with Racket). Has threading support improved over the years?

> Has threading support improved over the years?

The main push in this area is Multicore OCaml[1]. I don't track OCaml closely enough to know how getting this into the main compiler is going.

[1] https://github.com/ocamllabs/ocaml-multicore/wiki

I am not sure what exactly you are missing, isn't this a native OS thread either POSIX or Win32?


The documentation that you linked to is not describing native OS threads. I am sure that the OCaml implementation is good for a lot of applications.

However, because I am used to writing multithreaded code using pthread or std::thread, I find the standard OCaml model uncomfortable and limiting. Its mostly a matter of personal taste but this is the reason I stopped using OCaml.

I tried it too; after I realized I that every struct had to have unique field names, I gave up. This was too much craziness for me, although I did think the module/functor concepts were very cool.

>I that every struct had to have unique field names

Nope, different structs could have fields named the same.

Are you sure Racket doesn't support native threads? I thought it had something called "places" for that.

I did not know about places, but after reading about them [1], I can see that although they are implemented on top of OS threads, it is not a conventional threading model.

For instance there is an instance of the Racket VM per place and this makes them heavier than it would be in a standard system programming language language such as C, C++ or Rust.

I am not saying it is better or worse -- just different.

[1] https://www.cs.utah.edu/plt/publications/dls11-tsffd.pdf

I have always been interested in OCaml, but I have a genuine question though - last when I looked at seriously at it, the standard library seemed to be a bit of a mess lacking a lot of features. A lot of modern resources seemed to focus on using Jane Street's Core(?) which I would not like to use - I'd rather depend on the standard language for standard features. Is this still a thing, or am I mistaken, or both? Please help! I really would like to use OCaml for a variety of hobby projects, including toy compilers. Which books/resources would you recommend?

You don't need Core, the shipped stdlib is good enough for toy projects. There are other stdlibs like containers and janestreet has split their stdlib into smaller pieces. What's your issue with having to use alternate stdlibs?

Regarding books, Real World Ocaml is very well written, although some examples might need tweaking.

Thanks for the reply!

Mostly wondering how people ship stuff if there are different variants of std libs? Say you write your code entirely using one std lib and then try to share it (the code that is) with somebody who uses a different std lib, then the onus of learning the new std lib is entirely on him, right? How does that work for teams then? I know that Jane Street is a big user and so they have considerable influence. That being said, does the std lib (the one bundled with the distro) have enough features (like all the necessary data structures, for instance) to make using it viable in a non-trivial project (off the top of my head, say writing a very simple web server)? If so then, I suppose that's good enough.

Any recommendations for learning material? I have a copy of "Practical OCaml", don't really like it. INRIA's materials seem quite substantial, but more like reference.

The standard stdlib has all useful data structures, mostly the differences are in providing more convenient functions and monadic interfaces that you might have to write yourself, if you didn't use the alternate libraries. There is nothing to "learn" about using another stdlib since most signatures are the same. And they can use a different stdlib if they want.

The migration from standard stdlib to alternate ones is fairly trivial(some signatures might differ but typed language means the compiler will catch them for you), so you can start using the stdlib and if you feel like writing some trivial things that should be in the stdlib or you need some advanced data structures you can use the alternate ones.

Also you need `lwt`(most people prefer this)/`async` library for writing concurrent programs like a webserver. `Cohttp` is a good library for doing http based client/servers. I strongly recommend `Real world ocaml` and the reference manual is excellent at looking up some new type-level features. Also reading well-known libraries code is an excellent way to learn a language.

Excellent. Thanks for the detailed answer - that really helps. To be honest, I want to use OCaml for writing some toy compilers to begin with, and I'm sure that that'll require only the core language, but I would like to use it for more serious projects after that!

I'll start off with "Real world OCaml" and see how it goes!

Here is some resource for you to learn from: http://plzoo.andrej.com/

You could also take a look at F# wich is also a ML derived language so the syntax is very similar to OCaml.

I did consider it seriously (especially after watching Scott Wlaschin's Parser Combinators video), but it seems a bit too MS-centric for my liking. Who knows, maybe if learning OCaml doesn't pan out that well, it might be F# for me! :D ... the community seems to be focused, so that's one big advantage.

I'm a Python programmer with no prior experience to systems outside university.

Browse Python projects on github and find some that strike your fancy. Especially those which may run slow, like puzzle solvers, image manipulation apps, etc. Bonus points if they have few external dependencies. Rewrite them in Rust.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact