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?)
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.
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.
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"
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.
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.
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.
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.
> 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?
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.
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].
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?
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.
> 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 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.
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.
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.
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.
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).
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 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".
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!
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
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)
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?
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.
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.
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 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.
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
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.
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.
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!
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.
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.
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.
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).
> 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.
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?
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.
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.
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.
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.
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.
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.
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.
> ...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.
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.
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).
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.
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
"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.
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.
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.
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.
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.
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 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.
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?
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)
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.
> 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 :)
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.
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 :).
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.
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.
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.
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?
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 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.
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.
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!
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.
> like – maybe Rust is not for people who are already C++ experts and who are happy with C++? I don’t know!
I think Rust is very good for C++ experts. Some key concepts like ownership / RAII and etc. are well known in C++, and they should be easy to understand.
Yeah, people with C++ experience have an advantage when learning Rust, since they're used to these concepts, and the Rust compiler enforces things they already know to be careful with (like not mutating a container while there's a live iterator to it). On the other hand, Rust lacks some things C++ has like being generic over values instead of just over types, so for instance implementing a trait for every fixed-size array of a type is currently AFAIK not possible (the usual solution is to use a macro to manually implement the trait for every size up to 32).
Sure, there are differences as well, and there is no point in always mimicking C++ approaches in Rust 1:1. But I think overall, coming from C++ to Rust should be one of the easiest transitions.
As someone who's extremely comfortable with C++, I've tried Rust multiple times but keep bouncing off. Ultimately my problem is just that it doesn't have enough exciting features to lure me away, especially with C++ improving every few years.
Compiler-enforced safety and a built-in package manager are really nice, but it doesn't quite make up for the loss of a lot of handy C++ features.
I'm learning Rust by writing graphical / glitch art software. Not too much exposure to 'systems' programming although color spaces are more complex than you'd think. Performance is important when you shuffle thousands of pixels around, and some of it is easy to parallelize.
Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why.
It is new, it is shiny but lets wait its 10th birthday before it can be taken seriously and pls provide a decent async io / http library before we even get started what else can be done in Rust.
pls provide a decent async io / http library before we even get started what else can be done in Rust
I have found Rust library coverage to be really good for my requirements. Hyper (https://hyper.rs/guides/client/basic/) provides an async HTTP client although I have never needed it.
Personally, if I had an application that was heavily using HTTP I would choose a different language -- Java, Scala and Go would be good choices.
Again what is your use case. Ours was to have a high performance compiled code that can be slower than Java by a factor of 10. Unfortunately Rust could cut it.
Using it at the moment and it's been great to use: documentation was good, API was straightforward, everything so far has worked practically first time.
Performance of what code was 30 times less? It would make a great project for someone to investigate in depth why Rust performs particularly poorly (or why Java performs particularly well) in a specific area - if only you could provide the necessary details...
Yeah I wanted to. I reached out to my Rust devs and everybody said that my code is perfectly fine. It means I have to dig into the library code but does not have enough knowledge about Rust performance and what tooling I am supposed to do or what are the knobs that I need to adjust for higher performance.
> It is new, it is shiny but lets wait its 10th birthday before it can be taken seriously and pls provide a decent async io / http library before we even get started what else can be done in Rust.
Have you not looked at it for a while or don't you think tokio/hyper is good?
So if a language can't do HTTP and async I/O (with state-of-the-art performance) then we shouldn't consider any other possible application for it? Rust is not Java, you have better languages to build webservers with.
Yes, if a language can't easily do async IO and HTTP in 2018, it is in deep shit with regard to long term adoption. The Rust devs realize this, otherwise they would be putting less effort into tokio.
I feel the same as OP in regards to spelling mistakes. It just erks me so much that I find it really hard to continue reading.
If someone hasn’t bothered to take the time to proof-read their work, what does it say about the topic they are writing about? I don’t mind if the mistakes are because they are learning English, but I’m talking about really obvious spelling mistakes.
The closing keynote at RustConf is generally someone who is new to Rust or has never used Rust but can bring in an interesting perspective. Last year we had Joe Duffy, who I don't think has done much Rust aside from perhaps basic experimentation, but has a lot of relevant experience from running the Midori (Microsoft's safe systems language) project.
It's interesting because when I read about how Rust can rewrite iterators code into more performant direct loops I thought about Joe's blog posts that mentioned the same efforts for .NET. Also Span<T>. It seems .NET will have similar abstractions like Rust (of course not all can be migrated).
> -- Functional style
> require "fun" ()
> -- calculate sum(x for x^2 in 1..n)
> n = 100
> print(reduce(operator.add, 0, map(function(x) return x^2 end, range(n))))
328350
> -- Object-oriented style
> local fun = require "fun"
> -- calculate sum(x for x^2 in 1..n)
> print(fun.range(n):map(function(x) return x^2 end):reduce(operator.add, 0))
328350
> Lua Fun takes full advantage of the innovative tracing JIT compiler
to achieve transcendental performance on nested functional expressions.
Functional compositions and high-order functions can be translated into
efficient machine code. Can you believe it? Just try to run the example
above with `luajit -jdump` and see what happens:
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.