They’re clearly marketing to different audiences. Rust doesn’t need to sell as a technology to engineers anymore, it needs to sell as a product to businesses. Most tech marketing sites undergo this transition the more they grow, in my experience
I think that’s not true at all. What does it that even mean, selling as a product to businesses? The way you do that is by targeting their engineers, the people who make technology choices. Ground up is by far the best strategy for a language, top down feels ridiculous. If you are actually in a position where you’re talking to bunsinesses about funding you’ve already sold to their engineers and your website is irrelevant - at that point they’re going to want to hear about what the language needs in order to succeed because the org is bought in.
Beyond that, this website contains all of the things that the Rust site does, but also code. It’s proof that you don’t need a tradeoff here - literally just put a damn snippet of the language on the site, that’s it.
The reality is that language decisions are made almost exclusively when the company starts. By engineers. Companies only ever constrain their internal support languages in the future, and it’s engineers who push for language support when that happens. Selling a language to a business through the website is just a nonsensical concept on its face.
Roc makes it clear, in text, without code, “here is why you would choose Roc” but also it shows code, very concisely right at the top.
The idea is that rust has already captured he interest of engineers. Word of mouth, blog posting, conferences etc. “Everyone” knows about rust at this point. Engineers are building hobby projects and FOSS in jot already.
What I mean by selling to a business is that ultimately management aka business needs to approve and buy into rust otherwise it will remain in hobby project obscurity.
Some engineer or group of engineers says to their boss “we want to use rust for project X” and their boss loads up the landing page because while they’ve heard of Java and python they haven’t heard of rust. This is why the first words you see are ”reliable”, “efficient”, “safe”, and “productive”. They see big recognizable company logos and testimonials by well known or high-positioned leaders in the industry.
For what it’s worth I also think it’s a good idea to put code on the homepage. You can do both, but this is why you see tech marketing sites evolve to become less and less technical over time.
The idea is that rust has already captured he interest of engineers.
The reality is that Rust is something engineers have heard of but largely know nothing about, other than some high level stuff like “fast”. A small portion of companies actually use Rust, a small portion of engineers have ever touched it.
Some engineer or group of engineers says to their boss
By far the easiest way to gain adoption is through startups or smaller companies where the engineers are already the ones who decide on language. After a few thousand employees companies always end up with someone locking down the decision making process and tiering the language support levels - at that point, again, it’s up to the engineers to work through the process to gain support. I’ve never heard of a situation where a top level manager had to go to a language website and make the call to use or not use a language, isn’t that sort of an absurd idea? But, again, Roc shows that this is not an “either, or” situation.
This is why the first words you see are
Roc shows “fast, friendly, functional” - I’m not saying you can’t have words. Roc shows that you can have these great, high level blurbs here.
They see big recognizable company logos and testimonials by well known or high-positioned leaders in the industry.
Roc also shows this. Again, I am not against the idea of content other than code on the site, I’m saying it’s ridiculous to have literally no code.
For what it’s worth I also think it’s a good idea to put code on the homepage.
I think the point is that Rust is at a stage where it’s marketing itself as an industry-ready language and ecosystem that you can build actual products on without worrying about running into a horrible bug that dooms your start up. At that stage, showing code doesn’t make too much difference, because the “industry-ready” aspect of it has so much more going for it than the surface language syntax you can showcase in a landing page.
Roc, however, is at the stage where it needs to capture the interest of curious engineers that might be interested in the language itself, without worrying about the practical applicability of it too much. (BTW, I don’t want to imply that Roc can’t be used for anything practical at this point, I don’t know, but clearly I wouldn’t bet my start up on it and I doubt anyone expects that at this stage).
What does it that even mean, selling as a product to businesses? The way you do that is by targeting their engineers, the people who make technology choices. Ground up is by far the best strategy for a language, top down feels ridiculous.
Man, as a person who sells languages (mostly TLA+) professionally, I wish that was the case. Selling to engineers is way more fun and feels more comfortable. But I’ve had cases where an entire team wanted to hire me, and cases where the team never heard of TLA+ but a manager or CTO wanted to hire me, and the second case way more often leads to business.
I’m not saying that it literally never happens, I’m saying that by far language adoption at companies is driven by engineers - either through external forces (engineers building tooling/libraries in their free time, engineers starting companies with that language, etc) or through direct forces (engineers advocating for the language at that company).
I’m sure there are plenty of extreme cases like Oracle convincing schools to sell Java, or whatever, where this wasn’t the case.
It’s all moot since Roc’s language clearly shows that a website can have code and high level information, and meld them together well.
I’m not saying that it literally never happens, I’m saying that by far language adoption at companies is driven by engineers
The guy literally said he sells languages professionally, and he’s telling us it’s driven by management, not engineers. Do you also sell languages? Or better yet, have some source of information which trumps his personal anecdotes?
In what way is Oracle an extreme case?
I don’t disagree that you can still include code, but even the high level blurbs will be different when selling to businesses, at which point, if the copy isn’t selling to developers, you might as well better use the space to more effectively sell to businesses where the code would have been (even literally empty space for a less cramped, more professional looking page).
Engineers care more about “fast (runtime)” and certainly “friendly” than most businesses do, and businesses care a lot more about “safe” than a lot of programmers do; “fast (compile time)”, ”reliable”, “efficient”, and “productive” may be mixed. Engineers also care about technical details like “functional” a hell of a lot more than businesses do, because they can evaluate the pros and cons of that for themselves.
I guess it’s much more effective to be very targeted in who you’re selling to, unless both profiles have equal decision making power.
The guy literally said he sells languages professionally, and he’s telling us it’s driven by management, not engineers.
And? I know almost nothing about them. They’ve apparently been pushing TLA+, an incredibly niche and domain specific language that the vast majority of developers never even hear of and that targets software that lives in an extreme domain of correctness requirements. It’s nothing at all like Rust. Maybe they also sell Python, or comparable languages? I don’t know, they didn’t say. Is it even evidence that selling TLA+ this way is the most effective way?
Or better yet, have some source of information which trumps his personal anecdotes?
Years of experience in this field as an engineer, advocating and getting a large company to include languages in their accepted policies, generally just being an engineer who has adopted languages.
unless both profiles have equal decision making power.
I do not buy, at all, that for a language like Rust (frankly, I doubt it’s the case for any language, but I can imagine languages like TLA+ going a different route due to their nature and lack of appeal to devs) that it’s not wildly favorable to target developers. I’ve justified this elsewhere.
The current Rust website is not ideal, but I think the general principle of convincing devs vs businesses holds.
Developers are picky about surface-level syntax. The urge to see the code is to judge how it fits their preferences. I see lots of comments how Rust is plain ugly and has all the wrong brackets.
Business-level decision makers don’t care how the code looks like. It can look like COBOL, and be written backwards. They ask what will happen if they spend resources on rewriting their code, and that better improve their product’s performance/reliability/security or devs’ productivity, not just make a neat-looking quicksort one-liner.
Readability is subjective. Syntax must be functional and clear, but devs will care about details beyond that, and die on hills of which brackets it should use, and whether significant whitespace is brilliant or terrible.
Compare “The app is slower and uses more memory, but the devs think the code is beautiful” vs “The app is faster and more reliable, but the devs think the code’s syntax looks stupid”. If you want to convince product owners, the syntax is an irrelevant distraction, and you must demonstrate outcomes instead.
In web development there’s also a point of friction in developer experience vs user experience. Frameworks and abstraction layers have a performance cost (tons of JS), but not using them is harder and more tedious.
While readability is subjective to a certain degree, it stems from human psychology, which is based on how the real world works.
In the real world, things that are inside a container are smaller than the container, so if delimiters don’t visually encompass the text they contain, it looks counter-intuitive.
And things which are physically closer together are perceived as being more strongly associated, so a::b.c looks like it should be a::(b.c), while in fact it’s (a::b).c.
Performance and safety has nothing to do with syntax. It would be entirely possible (and not difficult) to create a language exactly like Rust, but with better syntax.
I think you’re confirming what I’m saying. You’re focusing on a tiny nitpick about a part of the syntax that doesn’t cause any problems.
And yet you’re prepared to bikeshed the syntax, as if it was objectively wrong, rather than a complex tradeoff. In this case the syntax and precedence rules were copied from C++ to feel familiar to Rust’s target audience. If you just “fix” the precedence, it will require parens in common usage. If you change the separator symbols, you’ll get complaints that they’re weird and non-standard, and/or create ambiguities in item resolution.
Showing code for a language invites such shallow subjective opinions, and distracts from actually important aspects of the language.
This is literally bikeshedding. Don’t you see the pointlessness of this? If you changed Rust to use your preferred sigil, it would still produce byte for byte identical executables. It wouldn’t change anything for users of Rust programs, and it wouldn’t even change how Rust programs are written (the compiler catches the <> ambiguity, tells you to use turbofish, and you move on).
Rust has many issues that actually affect programs written in it, e.g. bloat from overused monomorphisation, lack of copy/move constructors for C++ interop and self-referential types, Send being too restrictive for data inside generators and futures, memory model that makes mmapped data unsafe, blunt OOM handling, lack of DerefMove and pure Deref, lack of placement new for Box, etc. But these are hard problems that require deep understanding of language’s semantics, while everyone can have an opinion on which ASCII character is the best.
Even Rust’s syntax has more pressing issues, like lack of control over lifetimes and marker traits of async fn, or lack of syntax for higher-ranked lifetimes spanning multiple where clauses.
You’re thinking of physics, not psychology. Concrete syntax is one of the least important parts of a programming environment, and we only place so much weight onto it because of the history of computers in industry, particularly the discussions preceding ALGOL and COBOL.
There is also https://prev.rust-lang.org, linked (not prominently) from the bottom of https://www.rust-lang.org. It doesn’t have the “eating your laundry” footnote, but the code runner works, unlike in web.archive.org.
@rtfeldman, I recognise you from the Elm community! I used it professionally for a couple of years. This looks to have lots/all of the good parts from Elm. What’s the approach you’re taking to the language evolving? A BDFL like Evan (Elm) or like José (Elixir), for example?
The background is that I love Elm and wanted to get an Elm-like experience in other domains (domains other than browser-based UIs) - and not just servers, but also CLIs, native GUIs, editor plugins, database extensions, robotics…what I call the “long tail of use cases.” Elm is a very domain-focused language, and I knew it would never expand in scope to cover the long tail of use cases…and yet I wanted to have access to an Elm-like experience for that long tail of use cases!
Separately, I also had some language design ideas that I’d accumulated over the years, which would have been too radical a change for Elm, but which a new Elm-like language could try out. (Tag unions, no currying, and some syntax things were all examples of this.) At some point enough things came together that I decided to take the plunge and make the language!
If you’re interested in functional programming, but don’t want to learn any features that make functional programming useful, then the Roc language is for you!
Exciting stuff! I love the idea of platforms: It’s such an elegant way to take the ideas from Elm and transform them to other domains. However, there was one question that immediately popped up in my mind: What about composability? Do platforms compose (I don’t think so)? Could they? Are there any plans or ideas in this direction?
EDIT: I know you want to push your own editor for ROC, but are there any plans to provide a TreeSitter grammar and an LSP, so we can use Helix/Nvim/Emacs/… ?
Short answer is that the editor project has been deprioritized a lot (e.g. I don’t expect any work to be done on it in 2024) because we realized there’s a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors!
An initial tree-sitter grammar was created a few days ago, and there is a slightly flakey language server that integrates with one of the VSCode extensions. I think plans for the Roc editor have changed, but I haven’t kept up with what the new plan is.
Really happy with how the language design has come along since the last time I took a look. I was skeptical of structural typing for both records and tagged unions, but the combination of default structural typing and opt-in nominal typing seems like a really nice point in the design space.
It’s absolutely a better time to try it now! But as the website notes, it’s still a very young language - so you can still expect an early-adopter experience. 😄
The short answer is that it’s up to the platform what to offer in terms of FFI, including whether it’s allowed at all.
For example, the platform could offer a Task function which takes a path to a dylib, the name of a function in the dylib, and a payload of data to send to it - and then does a dlopen followed by calling the function. The Task’s success value would be set to the answer returned by the dylib function.
(Note that all FFI calls like this would have to be presented as tasks, because that’s the only thing platforms can offer. This also guarantees that side-effecting functions can’t end up making it into the application.)
It’s an intentional security feature that platforms are in charge of FFI, and that there are no workarounds to this - more details on https://www.roc-lang.org/platforms
The Platforms idea is very cool. Could a platform place execution time requirements on the executor? e.g. could you safely embed Roc in a system that can give user programs a 100ms budget?
I think what I’m trying to ask is, a platform may prevent them from typing Files.forall File.delete or while 1 {Memory.gimmegimme()} and if you’re careful enough Regex.execute "catestrophic backtracking rergex" giantstring, but is there anything that can keep them from typing while 1 {}?
I’ve been meaning to ask about the security aspect of platforms - what’s the intended practical workflow?
Like, say as a user I want to take advantage of Roc’s security benefits. How would I do so? Would I only download Roc programs off the internet and run them with pre-approved platforms that I know sandbox appropriately? It seems to me that it requires a lot of discipline and technical knowledge to actually benefit from the security provisions, and I’m not convinced that this is a better solution than a traditional application sandbox like macOS or Flatpak enforce. (I guess maybe if Roc gets big enough such that app stores start to treat Roc programs specially they could provide some context to the user? But before that, the problem is that from the user perspective, there’s no trusted authority on the program other than the developer - who is AFAICT by the definition of the Roc platform threat model assumed to be hostile.)
I admittedly haven’t read a ton of the docs other than the platforms documentation because I originally heard of Roc when someone asked me about the security aspect. So this might be a super dumb question - I apologize if so and please let me know :-)
Edit: from reading other comments I’m thinking maybe I’m just imagining the usecase too narrowly. Someone mentioned that it could replace Lua which helped me think about this - if you have something more language-constrained, like a plugin system, then this makes a lot more sense. “If it doesn’t run on this specific Roc platform, it’s nonsensical to try and run it” can be a good way to get to “loading arbitrary plugins is good and safe”. FWIW, it was the “make it safe to download and run an arbitrary script” example on https://www.roc-lang.org/platforms that led me down this now seemingly-incorrect line of thinking.
One note on this. We have a basic-cli platform that is the basis of most command line scripts in Roc. Let’s just imagine that years in the future, this is still the defacto platform for cli applications and it is pretty common to download and run roc scripts that use this platform.
It is very simple to fork the basic-cli platform and make a version of it that must explictly request every single permission from the end user. Let’s call it basic-cli-safe. It would pop up messages like The application is trying to read ~/Downloads/somefile.txt, is that ok?. As an end user, it would be trivial for me to switch an application from running on basic-cli to basic-cli-safe.
So if I download a roc script that I want to run but don’t fully trust, I can simply run it with basic-cli-safe instead of basic-cli and I will see exactly what io it is trying to do. Every file read or write, every web request, every single piece of io that the roc script does period. This is one example where a platform can gain security benefits outside of the world of scripting and embedded applications.
Though as a plugin system, it also has benefits. As a game author that loads mod plugins in roc, I would decide exactly what primitives the plugin can use. So I know they won’t be calling out to random webservers, installing viruses, or doing other crazy things. The plugin literally won’t have the primitives to even be able to do that.
Roc isn’t even at a numbered version yet (i.e. it’s pre v0.0.1), so it’s still in the experimentation phase. The biggest area of interest at the moment seems to be backend web development, but there’s also discussion around gamedev and scientific computing uses.
Very nice. I’ve been looking forward to this for a while :)
I think I quite like it so far. The design of tasks, platforms, no variable shadowing and so-on are really well reasoned. At $WORK we do a lot of “run some of your code on our platform” stuff and the design seems really solid for that. It would be so cool to use this instead of Lua for game scripting for example.
Some things like Num and Frac seem so non-standard that I wonder why they were considered (over Int and Float for example).
I’m having trouble figuring out how values other than Num are ordered and how to sort an array of strings… there is a global equality function but is there a global total order function? I may need to explore more than just playing in the web-based REPL.
So Num is the broadest, most generic “this is a number” type. Any function that takes an Int or a Frac can accept a Num. However, if you have a function that takes a Frac and you have an Int, you have to explicitly convert it from the one to the other (which can involve precision loss, etc.).
Similarly to how Num breaks down into Int and Frac, Frac itself breaks down into Dec (the default, a fixed-point decimal type), and also F32 and F64 (the floating-point number types we’ve all used to varying degrees). Dec is the default because it’s less error-prone, but you can easily use F32 or F64 if your use case warrants it.
For example, if you have a function that accepts F64, you can just call it passing the number literal 4 (because that’s a Num literal, which is less specific than F64), or also the number literal 4.2 (because that’s a Frac literal, which is also less specific than F64), but not the number literal 0x4 (because that’s an Int literal, which is incompatible with F64).
Similarly, Int breaks down into I8 (a signed byte, so values between -128 and 127), U8 (unsigned byte, 0-255), I16, U16, I32, U32, I64, U64, I128, and U128. We don’t have an arbitrary-sized Int because that’s much more complicated and astronomically slower than I128, and so far nobody has had a concrete use case where I128’s maximum value of several undecillion (I had to learn that word to be able to talk about how bit 128-bit integers can get) somehow wasn’t big enough. 😄
Ah - that makes a lot more sense to me now, I didn’t realize it was some kind of union or abstract type. (And thanks for reaching out! I may have to check out zulip)
What I haven’t seen before is the way the REPL leaves x in x = 1 without a concrete type, it says it’s a Num *. I assume in any “compiled program” every variable and literal (constant value) would have a concrete representation?
I am still quite interested in how you guys think about ordering of arbitrary values (<, >, etc), as I have this simple functional language at work with structurally typed tagged unions, records, arrays, sets & dicts, etc (so quite similar to roc!) and had to think a lot about how to make it easy to order everything (the sets/dicts are b-tree based and you can use any value as a key, so I ended up providing a total order across the entire type system much like roc has equality defined everywhere, and so far I don’t regret it at all because it’s so convenient as a user).
Yeah we’re planning to have ordering work like equality and hashing (which we already have), but we haven’t implemented ordering yet.
The repl isn’t any different from programs built in roc build. (The repl actually is compiled too; it generates wasm binary code based on your inputs and then runs it in the browser. Roc doesn’t currently have an interpreter, although we’ve talked about introducing one for compile-time evaluation of constants.)
If you don’t annotate the number or use it with something that would force it to take on a particular number type (e.g. passing x to a function that takes an F64 would make that 1 be a 64-bit float representation at runtime), and that works either in the repl or in a compiled program.
OK cool, that’s nice to hear. I am curious how you will order the records and variants (in our case the records have strictly ordered fields so we sort by first field first and so-on, and we sort the variants first by the tag as if the tag were a string since in code it’s not really practical for the user to “order” the tags).
How is an (abstract) number like 1 represented in the binary/generated WASM? E.g. if it were definitely U8 it could be a single byte, 0b00000001, but if it is Num I suppose you need to keep some kind of representation that can be dynamically converted. I could imagine such representations could be complex and maybe slow (the literal as a string, that gets parsed when needed? a type tag and a value, with numeric conversions done automatically?)
We sort record fields and variants by alignment, then alphabetically
We monomorphize, so if something still has the type Num * when we get all the way done with specialization, we pick a default type (currently I64 but we’ll probably change it to I128 at some point because basically the only place this ever comes up in practice is the REPL anyway; in real programs it always ends up becoming something more specific than Num *)
We started a discussion on Roc Zulip about this - if you have time to share more details about what you ran into, it would really help with tracking down the problem!
Excited to see Roc moving forward! I pick up bits and pieces about Roc when I listen to Richard’s podcast (Software Unscripted). It makes sense that they’re not on the landing page, but I think people here might appreciate two unique features of Roc:
“Platforms” as a first class concept (link). As I understand them, there’s a distinction between the language “core” and platform-specific functionality. For example, a browser app, a native GUI app, and a native CLI app are different platforms because they expose different functionality and have different interfaces.
SHA hashes for packages. Basically instead of “pip install typo_oopsie” package names include a hash, which is verified before installation. I like this because it enforces a thing I know I should do (verify the package is what I think it is) if only I wasn’t so lazy. There’s a brief mention of it in the tutorial here:
Once the file has been downloaded, its contents will be verified against this hash, and it will only be installed if they match.
Looks like this is using WASM 1.0. Is the REPL just passing strings back and forth between JS and WASM? I was a bit alarmed to see that the WASM binary was 6.35M uncompressed.
The REPL would include the entire Roc compiler, wouldn’t it? 6MB seems justifiable for that. How much WASM do you get from a statically compiled “hello world” Roc program?
Ah yes, seems like the web repl is not reporting the compiler error gracefully. (It’s correct to give an error for shadowing; Roc doesn’t allow declaring a new x when something named x is already in scope, which is why if you just define inc without first defining x = ... it works.)
Is that a shadowing issue though? I would expect the x in the lambda to not be part of the enclosing scope. Are you not able to use argument names that match a variable in the enclosing scope?
I love this website. First thing I see? Code. Amazing. It is insane how some languages hide their code from me.
And then I scroll down and… a repl? OMG. Yes.
And then I scroll down more and there’s more code??????? Did an actual developer build this website????
I remember when the Rust website was good and actually showed you code. Now it’s useless. https://www.rust-lang.org/ versus https://web.archive.org/web/20150317024950/http://www.rust-lang.org/
I feel like you’ve really hit the best of “simple, stylistic, and shows me the fucking programming language”.
They’re clearly marketing to different audiences. Rust doesn’t need to sell as a technology to engineers anymore, it needs to sell as a product to businesses. Most tech marketing sites undergo this transition the more they grow, in my experience
I think that’s not true at all. What does it that even mean, selling as a product to businesses? The way you do that is by targeting their engineers, the people who make technology choices. Ground up is by far the best strategy for a language, top down feels ridiculous. If you are actually in a position where you’re talking to bunsinesses about funding you’ve already sold to their engineers and your website is irrelevant - at that point they’re going to want to hear about what the language needs in order to succeed because the org is bought in.
Beyond that, this website contains all of the things that the Rust site does, but also code. It’s proof that you don’t need a tradeoff here - literally just put a damn snippet of the language on the site, that’s it.
The reality is that language decisions are made almost exclusively when the company starts. By engineers. Companies only ever constrain their internal support languages in the future, and it’s engineers who push for language support when that happens. Selling a language to a business through the website is just a nonsensical concept on its face.
Roc makes it clear, in text, without code, “here is why you would choose Roc” but also it shows code, very concisely right at the top.
Cool! I think it’s true at all :)
The idea is that rust has already captured he interest of engineers. Word of mouth, blog posting, conferences etc. “Everyone” knows about rust at this point. Engineers are building hobby projects and FOSS in jot already.
What I mean by selling to a business is that ultimately management aka business needs to approve and buy into rust otherwise it will remain in hobby project obscurity.
Some engineer or group of engineers says to their boss “we want to use rust for project X” and their boss loads up the landing page because while they’ve heard of Java and python they haven’t heard of rust. This is why the first words you see are ”reliable”, “efficient”, “safe”, and “productive”. They see big recognizable company logos and testimonials by well known or high-positioned leaders in the industry.
For what it’s worth I also think it’s a good idea to put code on the homepage. You can do both, but this is why you see tech marketing sites evolve to become less and less technical over time.
The reality is that Rust is something engineers have heard of but largely know nothing about, other than some high level stuff like “fast”. A small portion of companies actually use Rust, a small portion of engineers have ever touched it.
By far the easiest way to gain adoption is through startups or smaller companies where the engineers are already the ones who decide on language. After a few thousand employees companies always end up with someone locking down the decision making process and tiering the language support levels - at that point, again, it’s up to the engineers to work through the process to gain support. I’ve never heard of a situation where a top level manager had to go to a language website and make the call to use or not use a language, isn’t that sort of an absurd idea? But, again, Roc shows that this is not an “either, or” situation.
Roc shows “fast, friendly, functional” - I’m not saying you can’t have words. Roc shows that you can have these great, high level blurbs here.
Roc also shows this. Again, I am not against the idea of content other than code on the site, I’m saying it’s ridiculous to have literally no code.
Then we agree on the main issue here.
I’m not debating your tastes here? Just explaining why sites follow this trend. Hope this helps
OK and I’m explaining why the reasoning isn’t sound and it’s a bad idea.
I think the point is that Rust is at a stage where it’s marketing itself as an industry-ready language and ecosystem that you can build actual products on without worrying about running into a horrible bug that dooms your start up. At that stage, showing code doesn’t make too much difference, because the “industry-ready” aspect of it has so much more going for it than the surface language syntax you can showcase in a landing page.
Roc, however, is at the stage where it needs to capture the interest of curious engineers that might be interested in the language itself, without worrying about the practical applicability of it too much. (BTW, I don’t want to imply that Roc can’t be used for anything practical at this point, I don’t know, but clearly I wouldn’t bet my start up on it and I doubt anyone expects that at this stage).
Man, as a person who sells languages (mostly TLA+) professionally, I wish that was the case. Selling to engineers is way more fun and feels more comfortable. But I’ve had cases where an entire team wanted to hire me, and cases where the team never heard of TLA+ but a manager or CTO wanted to hire me, and the second case way more often leads to business.
Which is the norm. Because our peers unfortunately mostly have very little power to make decisions.
I’m not saying that it literally never happens, I’m saying that by far language adoption at companies is driven by engineers - either through external forces (engineers building tooling/libraries in their free time, engineers starting companies with that language, etc) or through direct forces (engineers advocating for the language at that company).
I’m sure there are plenty of extreme cases like Oracle convincing schools to sell Java, or whatever, where this wasn’t the case.
It’s all moot since Roc’s language clearly shows that a website can have code and high level information, and meld them together well.
The guy literally said he sells languages professionally, and he’s telling us it’s driven by management, not engineers. Do you also sell languages? Or better yet, have some source of information which trumps his personal anecdotes?
In what way is Oracle an extreme case?
I don’t disagree that you can still include code, but even the high level blurbs will be different when selling to businesses, at which point, if the copy isn’t selling to developers, you might as well better use the space to more effectively sell to businesses where the code would have been (even literally empty space for a less cramped, more professional looking page).
Engineers care more about “fast (runtime)” and certainly “friendly” than most businesses do, and businesses care a lot more about “safe” than a lot of programmers do; “fast (compile time)”, ”reliable”, “efficient”, and “productive” may be mixed. Engineers also care about technical details like “functional” a hell of a lot more than businesses do, because they can evaluate the pros and cons of that for themselves.
I guess it’s much more effective to be very targeted in who you’re selling to, unless both profiles have equal decision making power.
And? I know almost nothing about them. They’ve apparently been pushing TLA+, an incredibly niche and domain specific language that the vast majority of developers never even hear of and that targets software that lives in an extreme domain of correctness requirements. It’s nothing at all like Rust. Maybe they also sell Python, or comparable languages? I don’t know, they didn’t say. Is it even evidence that selling TLA+ this way is the most effective way?
Years of experience in this field as an engineer, advocating and getting a large company to include languages in their accepted policies, generally just being an engineer who has adopted languages.
I do not buy, at all, that for a language like Rust (frankly, I doubt it’s the case for any language, but I can imagine languages like TLA+ going a different route due to their nature and lack of appeal to devs) that it’s not wildly favorable to target developers. I’ve justified this elsewhere.
The current Rust website is not ideal, but I think the general principle of convincing devs vs businesses holds.
Developers are picky about surface-level syntax. The urge to see the code is to judge how it fits their preferences. I see lots of comments how Rust is plain ugly and has all the wrong brackets.
Business-level decision makers don’t care how the code looks like. It can look like COBOL, and be written backwards. They ask what will happen if they spend resources on rewriting their code, and that better improve their product’s performance/reliability/security or devs’ productivity, not just make a neat-looking quicksort one-liner.
Of course the one who cares about code readability is the one who is going to read the code. What’s wrong with that?
Readability is subjective. Syntax must be functional and clear, but devs will care about details beyond that, and die on hills of which brackets it should use, and whether significant whitespace is brilliant or terrible.
Compare “The app is slower and uses more memory, but the devs think the code is beautiful” vs “The app is faster and more reliable, but the devs think the code’s syntax looks stupid”. If you want to convince product owners, the syntax is an irrelevant distraction, and you must demonstrate outcomes instead.
In web development there’s also a point of friction in developer experience vs user experience. Frameworks and abstraction layers have a performance cost (tons of JS), but not using them is harder and more tedious.
While readability is subjective to a certain degree, it stems from human psychology, which is based on how the real world works.
In the real world, things that are inside a container are smaller than the container, so if delimiters don’t visually encompass the text they contain, it looks counter-intuitive.
And things which are physically closer together are perceived as being more strongly associated, so
a::b.clooks like it should bea::(b.c), while in fact it’s(a::b).c.Performance and safety has nothing to do with syntax. It would be entirely possible (and not difficult) to create a language exactly like Rust, but with better syntax.
I think you’re confirming what I’m saying. You’re focusing on a tiny nitpick about a part of the syntax that doesn’t cause any problems.
And yet you’re prepared to bikeshed the syntax, as if it was objectively wrong, rather than a complex tradeoff. In this case the syntax and precedence rules were copied from C++ to feel familiar to Rust’s target audience. If you just “fix” the precedence, it will require parens in common usage. If you change the separator symbols, you’ll get complaints that they’re weird and non-standard, and/or create ambiguities in item resolution.
Showing code for a language invites such shallow subjective opinions, and distracts from actually important aspects of the language.
Code readability is a problem, especially in a language that frequently features complex declarations.
It is objectively wrong.
<and>are comparison signs, not brackets. (And Rust does also use them as comparison signs, creating even more confusion.)I think using
\instead of::would be fine in terms of familiarity. Everyone has seen a Windows file path.This is literally bikeshedding. Don’t you see the pointlessness of this? If you changed Rust to use your preferred sigil, it would still produce byte for byte identical executables. It wouldn’t change anything for users of Rust programs, and it wouldn’t even change how Rust programs are written (the compiler catches the
<>ambiguity, tells you to use turbofish, and you move on).Rust has many issues that actually affect programs written in it, e.g. bloat from overused monomorphisation, lack of copy/move constructors for C++ interop and self-referential types,
Sendbeing too restrictive for data inside generators and futures, memory model that makes mmapped data unsafe, blunt OOM handling, lack of DerefMove and pure Deref, lack of placement new forBox, etc. But these are hard problems that require deep understanding of language’s semantics, while everyone can have an opinion on which ASCII character is the best.Even Rust’s syntax has more pressing issues, like lack of control over lifetimes and marker traits of
async fn, or lack of syntax for higher-ranked lifetimes spanning multiple where clauses.You’re thinking of physics, not psychology. Concrete syntax is one of the least important parts of a programming environment, and we only place so much weight onto it because of the history of computers in industry, particularly the discussions preceding ALGOL and COBOL.
And they actually explain what they claim with “What does X mean here?”.
There is also https://prev.rust-lang.org, linked (not prominently) from the bottom of https://www.rust-lang.org. It doesn’t have the “eating your laundry” footnote, but the code runner works, unlike in web.archive.org.
This is an absolute model for language websites. I love the annotated example.
Congrats on getting to the point of sharing widely @rtfeldman and co!
Is there an explanation of how Roc differs from various other languages? When would I want to use Roc instead of say Elm or Ocaml?
@rtfeldman, I recognise you from the Elm community! I used it professionally for a couple of years. This looks to have lots/all of the good parts from Elm. What’s the approach you’re taking to the language evolving? A BDFL like Evan (Elm) or like José (Elixir), for example?
Update: Just found this on the website at https://www.roc-lang.org/community#ideas! Very happy to see this.
I guess I’ve been living under a roc this whole time, but what’s the point of this language? Why was it written?
I talked about this on https://twitter.com/adspthepodcast although I don’t think the episode is out yet.
The background is that I love Elm and wanted to get an Elm-like experience in other domains (domains other than browser-based UIs) - and not just servers, but also CLIs, native GUIs, editor plugins, database extensions, robotics…what I call the “long tail of use cases.” Elm is a very domain-focused language, and I knew it would never expand in scope to cover the long tail of use cases…and yet I wanted to have access to an Elm-like experience for that long tail of use cases!
Separately, I also had some language design ideas that I’d accumulated over the years, which would have been too radical a change for Elm, but which a new Elm-like language could try out. (Tag unions, no currying, and some syntax things were all examples of this.) At some point enough things came together that I decided to take the plunge and make the language!
It’s part of the Elm exodus. Derw is another such language.
If you’re interested in functional programming, but don’t want to learn any features that make functional programming useful, then the Roc language is for you!
I don’t think that’s fair. Roc has immutability, managed effects, and pure functions; I think those are enough to make functional programming useful.
That seems rude and also contentless: what specific features do you feel are missing to make it useful?
Exciting stuff! I love the idea of platforms: It’s such an elegant way to take the ideas from Elm and transform them to other domains. However, there was one question that immediately popped up in my mind: What about composability? Do platforms compose (I don’t think so)? Could they? Are there any plans or ideas in this direction?
what if i want my webapp to have a nice cli?
Just started playing with roc last week and been having a great time!
The language feels pretty intuitive even though it’s young
Hope to see it grow!
I’ve been waiting for this for so long. Thanks!
EDIT: I know you want to push your own editor for ROC, but are there any plans to provide a TreeSitter grammar and an LSP, so we can use Helix/Nvim/Emacs/… ?
Short answer is that the editor project has been deprioritized a lot (e.g. I don’t expect any work to be done on it in 2024) because we realized there’s a way to build the editor plugin ecosystem we want to build in a way that works across multiple editors!
There already is a preliminary language server, and there are instructions in the VS Code extension for how to get it set up: https://github.com/ivan-demchenko/roc-vscode-unofficial#configuring-language-server
An initial tree-sitter grammar was created a few days ago, and there is a slightly flakey language server that integrates with one of the VSCode extensions. I think plans for the Roc editor have changed, but I haven’t kept up with what the new plan is.
Really happy with how the language design has come along since the last time I took a look. I was skeptical of structural typing for both records and tagged unions, but the combination of default structural typing and opt-in nominal typing seems like a really nice point in the design space.
Looking forward to using this in the future!
New website!
I remember what the old one said regarding its design. So now is maybe a better time to try Roc? :)
It’s absolutely a better time to try it now! But as the website notes, it’s still a very young language - so you can still expect an early-adopter experience. 😄
I can handle that, I’m a zig user. 😎
Hello, from the index: https://github.com/roc-lang/roc/blob/main/www/generate_website/main.roc not found. Probably https://github.com/roc-lang/roc/blob/main/www/main.roc
Thanks, fixed!
What’s the FFI story? I’ve been searching for a while and I can’t find anything on page about it.
The short answer is that it’s up to the platform what to offer in terms of FFI, including whether it’s allowed at all.
For example, the platform could offer a Task function which takes a path to a dylib, the name of a function in the dylib, and a payload of data to send to it - and then does a dlopen followed by calling the function. The Task’s success value would be set to the answer returned by the dylib function.
(Note that all FFI calls like this would have to be presented as tasks, because that’s the only thing platforms can offer. This also guarantees that side-effecting functions can’t end up making it into the application.)
It’s an intentional security feature that platforms are in charge of FFI, and that there are no workarounds to this - more details on https://www.roc-lang.org/platforms
The Platforms idea is very cool. Could a platform place execution time requirements on the executor? e.g. could you safely embed Roc in a system that can give user programs a 100ms budget?
I can’t think of a reason why not!
I think what I’m trying to ask is, a platform may prevent them from typing
Files.forall File.deleteorwhile 1 {Memory.gimmegimme()}and if you’re careful enoughRegex.execute "catestrophic backtracking rergex" giantstring, but is there anything that can keep them from typingwhile 1 {}?I’ve been meaning to ask about the security aspect of platforms - what’s the intended practical workflow?
Like, say as a user I want to take advantage of Roc’s security benefits. How would I do so? Would I only download Roc programs off the internet and run them with pre-approved platforms that I know sandbox appropriately? It seems to me that it requires a lot of discipline and technical knowledge to actually benefit from the security provisions, and I’m not convinced that this is a better solution than a traditional application sandbox like macOS or Flatpak enforce. (I guess maybe if Roc gets big enough such that app stores start to treat Roc programs specially they could provide some context to the user? But before that, the problem is that from the user perspective, there’s no trusted authority on the program other than the developer - who is AFAICT by the definition of the Roc platform threat model assumed to be hostile.)
I admittedly haven’t read a ton of the docs other than the platforms documentation because I originally heard of Roc when someone asked me about the security aspect. So this might be a super dumb question - I apologize if so and please let me know :-)
Edit: from reading other comments I’m thinking maybe I’m just imagining the usecase too narrowly. Someone mentioned that it could replace Lua which helped me think about this - if you have something more language-constrained, like a plugin system, then this makes a lot more sense. “If it doesn’t run on this specific Roc platform, it’s nonsensical to try and run it” can be a good way to get to “loading arbitrary plugins is good and safe”. FWIW, it was the “make it safe to download and run an arbitrary script” example on https://www.roc-lang.org/platforms that led me down this now seemingly-incorrect line of thinking.
This talk gets into specific examples of this, including a demo - should be helpful!
https://www.youtube.com/watch?v=cpQwtwVKAfU&t=75s
One note on this. We have a
basic-cliplatform that is the basis of most command line scripts in Roc. Let’s just imagine that years in the future, this is still the defacto platform for cli applications and it is pretty common to download and run roc scripts that use this platform.It is very simple to fork the
basic-cliplatform and make a version of it that must explictly request every single permission from the end user. Let’s call itbasic-cli-safe. It would pop up messages likeThe application is trying to read ~/Downloads/somefile.txt, is that ok?. As an end user, it would be trivial for me to switch an application from running onbasic-clitobasic-cli-safe.So if I download a roc script that I want to run but don’t fully trust, I can simply run it with
basic-cli-safeinstead ofbasic-cliand I will see exactly what io it is trying to do. Every file read or write, every web request, every single piece of io that the roc script does period. This is one example where a platform can gain security benefits outside of the world of scripting and embedded applications.Though as a plugin system, it also has benefits. As a game author that loads mod plugins in roc, I would decide exactly what primitives the plugin can use. So I know they won’t be calling out to random webservers, installing viruses, or doing other crazy things. The plugin literally won’t have the primitives to even be able to do that.
I remember really liking Roc when I looked at it a couple of years ago. Is there a killer app or niche yet for the language?
Roc isn’t even at a numbered version yet (i.e. it’s pre v0.0.1), so it’s still in the experimentation phase. The biggest area of interest at the moment seems to be backend web development, but there’s also discussion around gamedev and scientific computing uses.
Very nice. I’ve been looking forward to this for a while :)
I think I quite like it so far. The design of tasks, platforms, no variable shadowing and so-on are really well reasoned. At $WORK we do a lot of “run some of your code on our platform” stuff and the design seems really solid for that. It would be so cool to use this instead of Lua for game scripting for example.
Some things like
NumandFracseem so non-standard that I wonder why they were considered (overIntandFloatfor example).I’m having trouble figuring out how values other than
Numare ordered and how to sort an array of strings… there is a global equality function but is there a global total order function? I may need to explore more than just playing in the web-based REPL.These are great questions!
So Num is the broadest, most generic “this is a number” type. Any function that takes an Int or a Frac can accept a Num. However, if you have a function that takes a Frac and you have an Int, you have to explicitly convert it from the one to the other (which can involve precision loss, etc.).
Similarly to how Num breaks down into Int and Frac, Frac itself breaks down into Dec (the default, a fixed-point decimal type), and also F32 and F64 (the floating-point number types we’ve all used to varying degrees). Dec is the default because it’s less error-prone, but you can easily use F32 or F64 if your use case warrants it.
For example, if you have a function that accepts F64, you can just call it passing the number literal 4 (because that’s a Num literal, which is less specific than F64), or also the number literal 4.2 (because that’s a Frac literal, which is also less specific than F64), but not the number literal 0x4 (because that’s an Int literal, which is incompatible with F64).
Similarly, Int breaks down into I8 (a signed byte, so values between -128 and 127), U8 (unsigned byte, 0-255), I16, U16, I32, U32, I64, U64, I128, and U128. We don’t have an arbitrary-sized Int because that’s much more complicated and astronomically slower than I128, and so far nobody has had a concrete use case where I128’s maximum value of several undecillion (I had to learn that word to be able to talk about how bit 128-bit integers can get) somehow wasn’t big enough. 😄
Anyway, thanks for the question! Incidentaly, or future reference https://roc.zulipchat.com/#narrow/stream/231634-beginners is generally the best place to get quick answers to questions like this!
Ah - that makes a lot more sense to me now, I didn’t realize it was some kind of union or abstract type. (And thanks for reaching out! I may have to check out zulip)
What I haven’t seen before is the way the REPL leaves
xinx = 1without a concrete type, it says it’s aNum *. I assume in any “compiled program” every variable and literal (constant value) would have a concrete representation?I am still quite interested in how you guys think about ordering of arbitrary values (<, >, etc), as I have this simple functional language at work with structurally typed tagged unions, records, arrays, sets & dicts, etc (so quite similar to roc!) and had to think a lot about how to make it easy to order everything (the sets/dicts are b-tree based and you can use any value as a key, so I ended up providing a total order across the entire type system much like roc has equality defined everywhere, and so far I don’t regret it at all because it’s so convenient as a user).
Yeah we’re planning to have ordering work like equality and hashing (which we already have), but we haven’t implemented ordering yet.
The repl isn’t any different from programs built in
roc build. (The repl actually is compiled too; it generates wasm binary code based on your inputs and then runs it in the browser. Roc doesn’t currently have an interpreter, although we’ve talked about introducing one for compile-time evaluation of constants.)If you don’t annotate the number or use it with something that would force it to take on a particular number type (e.g. passing
xto a function that takes an F64 would make that 1 be a 64-bit float representation at runtime), and that works either in the repl or in a compiled program.OK cool, that’s nice to hear. I am curious how you will order the records and variants (in our case the records have strictly ordered fields so we sort by first field first and so-on, and we sort the variants first by the tag as if the tag were a string since in code it’s not really practical for the user to “order” the tags).
How is an (abstract) number like
1represented in the binary/generated WASM? E.g. if it were definitely U8 it could be a single byte,0b00000001, but if it isNumI suppose you need to keep some kind of representation that can be dynamically converted. I could imagine such representations could be complex and maybe slow (the literal as a string, that gets parsed when needed? a type tag and a value, with numeric conversions done automatically?)The short answers are:
Num *when we get all the way done with specialization, we pick a default type (currently I64 but we’ll probably change it to I128 at some point because basically the only place this ever comes up in practice is the REPL anyway; in real programs it always ends up becoming something more specific thanNum *)This talk has more details on how we implement things under the hood: https://vimeo.com/653510682
So
Numis a subtype ofIntandFrac? That’s the opposite of what I’d expect.It works the way you expect - my explanation may have been unclear on that. 😅
Every F64 is a Frac, and every Frac is a Num.
Also, if a function expects an F64 (or a Float, or a Num) I can pass it the number literal 4, or 4.2, but not 0x4.
If a function expects an I64 (or an Int, or a Num) I can pass it the number literal 4, or 0x4, but not 4.2.
Has anyone managed to install Roc in Termux? I like the language, but the inability to use it on my phone is a dealbreaker for me.
We started a discussion on Roc Zulip about this - if you have time to share more details about what you ran into, it would really help with tracking down the problem!
https://roc.zulipchat.com/#narrow/stream/231634-beginners/topic/installing.20Roc.20on.20Termux/near/403433941
Thank you, I added a comment to the GitHub issue.
This backpressing thing is very neat IMO. Enables monadic APIs in a very clean way.
Now if we can have an effects system we’ll be golden!
Excited to see Roc moving forward! I pick up bits and pieces about Roc when I listen to Richard’s podcast (Software Unscripted). It makes sense that they’re not on the landing page, but I think people here might appreciate two unique features of Roc:
Looks like this is using WASM 1.0. Is the REPL just passing strings back and forth between JS and WASM? I was a bit alarmed to see that the WASM binary was 6.35M uncompressed.
Is there a way to get it smaller? We’d definitely like to!
The REPL would include the entire Roc compiler, wouldn’t it? 6MB seems justifiable for that. How much WASM do you get from a statically compiled “hello world” Roc program?
Looks a bit like OCaml with implicit
doblocks. Nice to see the project still humming along.It’s heavily inspired by Elm syntax too. The creator of Roc is/was a big contributor to the Elm ecoystem.
Elm is OCaml dressed in a Haskell coat
I seem to have run into a bug with the REPL. Is there a place where I can file a ticket for it?
Here are the steps to reproduce it:
x = 1inc = \x -> x + 1inc 1You get the following error:
If you refresh the page and do the following, it works fine:
inc = \x -> x + 1inc 1edit: I would be remiss if I did not say that the new site is very beautiful. Well done!
Ah yes, seems like the web repl is not reporting the compiler error gracefully. (It’s correct to give an error for shadowing; Roc doesn’t allow declaring a new
xwhen something namedxis already in scope, which is why if you just defineincwithout first definingx = ...it works.)If you could open an issue at https://github.com/roc-lang/roc/issues that would be lovely!
Is that a shadowing issue though? I would expect the x in the lambda to not be part of the enclosing scope. Are you not able to use argument names that match a variable in the enclosing scope?
That’s correct! Here’s some more background on the motivation for that design: https://www.roc-lang.org/functional#no-reassignment