Rust 0.11.0 Released(mail.mozilla.org)
mail.mozilla.org
Rust 0.11.0 Released
https://mail.mozilla.org/pipermail/rust-dev/2014-July/010655.html
12 comments
Providing Go code as a shared library that is linkable from other languages is not technically infeasible, it is merely difficult. In 1.4 we aim to be able to load Go programs into a host process (on Android this will enable a Go process to live in the same memory space as a Java process), and also have a more general plan for Go shared libraries.
Brad Fitzpatrick has suggested in one of his talks that Go is interested in being embeddable as well, so I'm excited to see that. I have no doubt they'll do an awesome job.
It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.
It's really designed to be a first-class citizen from the ground up in Rust, though. Having no GC, precise control over stack vs. heap allocations, support for native calling conventions, a pluggable runtime, and a very fast FFI helps with that.
Now that "embedded" is being redefined to include ARM processors, we have already seen Go in such contexts. This is a great talk: https://www.youtube.com/watch?v=a4BQRUpQoe8
We'll never see Go on 16-bit architectures or smaller, though.
We'll never see Go on 16-bit architectures or smaller, though.
Embedded and embeddable are different things. Embeddable refers to the ability to call code written in your library from any other environment (and these days, over a C FFI).
> (I think!)
You are correct. The third production deployment of Rust is a Ruby gem written in Rust.
You are correct. The third production deployment of Rust is a Ruby gem written in Rust.
> Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom.
I do bash Go a lot, but it would be possible if the designers took the same approach as Cedar, Oberon and Modula-3. A few GC enabled system programming languages.
- Expand the capabilities offered by the unsafe package
- Offer more control over the GC behavior
- Add a kind of untraced pointer or a GC API for allocating them
I do bash Go a lot, but it would be possible if the designers took the same approach as Cedar, Oberon and Modula-3. A few GC enabled system programming languages.
- Expand the capabilities offered by the unsafe package
- Offer more control over the GC behavior
- Add a kind of untraced pointer or a GC API for allocating them
Aside from the removal of the ~ and @ sigils (an enormously impressive effort, btw), I'm actually much more excited for the next Rust release. 0.11 contains at least a few long-awaited and hugely-important features which are only half-implemented. Specifically, both DST and by-value closures should be ready for use by the time 0.12 rolls around. We also have some very exciting RFCs in the pipe, such as https://github.com/rust-lang/rfcs/pull/141 , which would make it possible to remove 90% of the lifetime parameters from our function signatures. Also, with Steve Klabnik now working full-time on documentation and Yehuda Katz's team working on our package manager, our ecosystem will soon be much more potent.
Great job, Rust developers! As ever, the challenge is to keep it up. :)
Great job, Rust developers! As ever, the challenge is to keep it up. :)
> DST
This appears to be "dynamically-sized types", for people who aren't in the know: http://blog.babelmonkeys.de/2014/03/18/dst.html
This appears to be "dynamically-sized types", for people who aren't in the know: http://blog.babelmonkeys.de/2014/03/18/dst.html
> at least a few long-awaited and hugely-important features which are only half-implemented
I look forward to a Rust release that doesn't have these. :) I've been tracking the language since the 0.5 (ish) timeframe and the language is a lot more ergonomic than it used to be but the frequent major shifts in how day to day Rust code is written make it tough to follow for a casual observer like myself (I follow /r/rust and write toy code every point release). Salute to the Rust devs and for those of you that work at relating the language to the rest of us. The language looks better every release.
I look forward to a Rust release that doesn't have these. :) I've been tracking the language since the 0.5 (ish) timeframe and the language is a lot more ergonomic than it used to be but the frequent major shifts in how day to day Rust code is written make it tough to follow for a casual observer like myself (I follow /r/rust and write toy code every point release). Salute to the Rust devs and for those of you that work at relating the language to the rest of us. The language looks better every release.
I agree with you, but AFAIK this is the first time we are part of a real "open development" of a programming language backed by a big company. It's very rare see clever coders change their mind when someone suggest a different approach. I'm glad this is happening and I wish more could follow.
Now that the ~ sigil has been retired, maybe it would be used for the bitwise NOT operator like C instead of the ! operator.
I keep seeing a lot of 'Rust vs Go' discussions, including in this thread. To me they seem to be targeted at different use cases. i.e. Rust is a C level replacement for low level direct memory access coding while Go is a garbage collected Java replacement for infrastructure level programming. I'm curious to hear what similar use cases people are using as a basis for directly comparing them.
When the Go team introduced the language, they used the phrase "systems language", and the meme has stuck, even though Rob Pike has since expressed some regret about having used the phrase so carelessly. Now he thinks the phrase "cloud infrastructure language" would be more apt.
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...
(approx 6 minutes 45 seconds into the talk)
I think it will take about a decade for everybody to readjust their frame on this one, alas.
P.S. Rust's own Niko Matsakis is one of the 4 people in this panel discussion, by the way, and it is well worth watching – even though they burn maybe a little too much time struggling with the question of what does/doesn't constitute a systems programming language.
http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...
(approx 6 minutes 45 seconds into the talk)
I think it will take about a decade for everybody to readjust their frame on this one, alas.
P.S. Rust's own Niko Matsakis is one of the 4 people in this panel discussion, by the way, and it is well worth watching – even though they burn maybe a little too much time struggling with the question of what does/doesn't constitute a systems programming language.
I blame Stroustrup, who likes to throw "systems programming" or "system language" into every discussion about his baby.
It is a bad meme, it even doesn't fit for C++ given it's main application as an application language (cue Torvalds rants about C++)
It is a bad meme, it even doesn't fit for C++ given it's main application as an application language (cue Torvalds rants about C++)
I wouldn't blame Stroustroup. “Systems programming” is vague because originally “systems software” was what came with your system — ranging from OS drivers (which you could write today only in a very carefully restricted subset of C++, amounting to “C with classes”), up to compilers, which can be expressed more cleanly using the larger generally-regarded-as-sane subset (e.g. STL, RAII) of C++.
I think Go fits decently for the latter, and reaches up to higher-level (or lazier) code that others might write in Python or Ruby or Haskell. Rust seems to reach as far down as C, which would be nice, though I worry that LLVM lacks any target smaller than ARM to keep them honest.
I think Go fits decently for the latter, and reaches up to higher-level (or lazier) code that others might write in Python or Ruby or Haskell. Rust seems to reach as far down as C, which would be nice, though I worry that LLVM lacks any target smaller than ARM to keep them honest.
The concept of "systems language" itself is not the meme to which I referred. Rather, the bad meme is the notion that Go is one. It may be some day if they make GC optional, but it isn't in its current form.
Why blame him? This is a correct definition.
A language capable of building the OS whole stack from the ground up, taken out the obvious parts in Assembly.
Yes, there are OS out there written in C++.
A language capable of building the OS whole stack from the ground up, taken out the obvious parts in Assembly.
Yes, there are OS out there written in C++.
I have been trying to discourage Go vs. Rust comparisons since time immemorial, given their wildly different purposes and audiences.
The eagerness to compare the two seems to stem primarily from 1) both market themselves as "systems" languages (though the vagueness of that term makes this a tenuous connection), 2) both have a focus on concurrency (though in the year 2014, if your language doesn't have a great concurrency story, you've already lost), and 3) the tech crowd seems to adore the imagined narrative of Google vs. Mozilla (though both languages are somewhat disconnected from their backing companies).
As a Rust follower, I would really love to see more comparisons to C++, Erlang, and Ada.
The eagerness to compare the two seems to stem primarily from 1) both market themselves as "systems" languages (though the vagueness of that term makes this a tenuous connection), 2) both have a focus on concurrency (though in the year 2014, if your language doesn't have a great concurrency story, you've already lost), and 3) the tech crowd seems to adore the imagined narrative of Google vs. Mozilla (though both languages are somewhat disconnected from their backing companies).
As a Rust follower, I would really love to see more comparisons to C++, Erlang, and Ada.
None of those reasons apply to me, and I think you're overlooking a simple one: As an SRE, I compare them because I'm looking for the next language to adopt as my primary systems/infrastructure language. I have enough issues with C++11 and Python in large systems that I'm looking for an expressive language in which I can work fast and build robust systems. Go and Rust are the finalists for that, with Python keeping the scripting side. Go just happened to finish first.
And, I think they both target the same use cases, they just adopted a different mind set on the way there. Most outsiders to Google don't realize this, but Go expresses volumes about the way that Google works internally. And, as with Protocol Buffers, the really awesome stuff in the technology was held back; any Googler will tell you that Go inside the veil is a vastly different experience because of the language-agnostic systems that Google has built internally.
At the end of the day, I want a language to write the various tools and systems I need in my SRE life. I've had a hodgepodge until now, and Go is appealing because I can centralize on one (with one toolchain). Rust is becoming more palatable every day.
And, I think they both target the same use cases, they just adopted a different mind set on the way there. Most outsiders to Google don't realize this, but Go expresses volumes about the way that Google works internally. And, as with Protocol Buffers, the really awesome stuff in the technology was held back; any Googler will tell you that Go inside the veil is a vastly different experience because of the language-agnostic systems that Google has built internally.
At the end of the day, I want a language to write the various tools and systems I need in my SRE life. I've had a hodgepodge until now, and Go is appealing because I can centralize on one (with one toolchain). Rust is becoming more palatable every day.
I sit in that area (SRE/DevOps/Tools) as well, and I strongly believe that Rust is a better foundational language because of the type system strength and guarantees. Particularly useful is the `enum` type and type matching. I want, simply put, to be able to write code that is "bulletproof" after I've brought it to deployment, and Rust gives me some awesome tools for that.
(I've also come to understand that Go is an extremely sharp tool for Google's problems - the style of coding, the concurrency, the expectations of the developers (look at the Google style guides to see the culture of development there, there's a harmony with Go). Your harmony with Go reflects your harmony with Google's problems).
(I've also come to understand that Go is an extremely sharp tool for Google's problems - the style of coding, the concurrency, the expectations of the developers (look at the Google style guides to see the culture of development there, there's a harmony with Go). Your harmony with Go reflects your harmony with Google's problems).
I would be very interested in comparisons to Erlang. Erlang seems to be the king of reliable and fault-tolerant systems and Rust seems to have taken lessons from it.
Not much to compare it to there. Rust's type system is much more advanced which is a big win and it is lower level but Erlang's model of reliability is based heavily on the BEAMVM.
Rust has a good concurrency model but I doubt it will compare favorably with Erlang's distributed computing primitives and fault-tolerance features (read, fault-tolerance is not equivalent to type safety!!)
Rust has a good concurrency model but I doubt it will compare favorably with Erlang's distributed computing primitives and fault-tolerance features (read, fault-tolerance is not equivalent to type safety!!)
Thanks! Yeah, I was specifically pointing to how tasks in Rust work in terms of failure. The approach of "if it fails, just kill it and potentially restart it". This is the same approach that Storm has managed to be fault tolerant.
Well, you could build a process supervisor that runs in its own forked resource (I'm sure, I don't know the language too well) - we have that in Haskell too (you can see similar code in the Cloud Haskell project where you give a supervisor some child specs and it "supervises" them with a couple different restart strategies).
Storm does it more at the machine level, while the philosophy is the same there it's not really done in the language but by Nimbus (correct me, someone, if I'm wrong).
The things in Erlang that are novel are really features in its BEAM VM, and not as much in the language. Distributed RPC, a DNS system built in for discovery, hot-reloading, heartbeat, etc...
I'm sad that Storm ended up being built on Java - Erlang would have been a perfect and probably better way to implement it.
Storm does it more at the machine level, while the philosophy is the same there it's not really done in the language but by Nimbus (correct me, someone, if I'm wrong).
The things in Erlang that are novel are really features in its BEAM VM, and not as much in the language. Distributed RPC, a DNS system built in for discovery, hot-reloading, heartbeat, etc...
I'm sad that Storm ended up being built on Java - Erlang would have been a perfect and probably better way to implement it.
Indeed. I have never touched Erlang, so thanks for the insight. Storm is a hybrid Java/Clojure project, so it's much better than simply a Java project. But yeah, the fault tolerance is not in the language, but the project itself.
You should play a but with Erlang. I no longer advocate weakly typed languages (i would choose Haskell or Scala over erlang these days) but it does have some novel concepts and is a fun language to play with.
Erlang is strongly typed, not weakly. You mean "I no longer advocate dynamically typed languages."
Yes I did mean that, thank you for the correction!
> Rust is a C level replacement for low level direct memory access coding while Go is a garbage collected Java replacement for infrastructure level programming.
Go has been fairly expressly billed as a C/C++ replacement. Now, I think that's somewhat misleading in comparison to Rust also being a C/C++ replacement, in that Go seems intended to replaces C/C++ in uses that are near the boundary where C/C++ (and, yes, Java) competes with Python/Ruby/etc. (where the former set has more of the performance characteristics sought but may be less convenient/concise/expressive, whereas the latter has the reverse features), whereas Rust is aimed at C/C++ deep in those languages prime use cases where they have little current competition -- certainly not from languages like Python/Ruby/etc. -- not at the boundary where they compete with Python/Ruby.
Go has been fairly expressly billed as a C/C++ replacement. Now, I think that's somewhat misleading in comparison to Rust also being a C/C++ replacement, in that Go seems intended to replaces C/C++ in uses that are near the boundary where C/C++ (and, yes, Java) competes with Python/Ruby/etc. (where the former set has more of the performance characteristics sought but may be less convenient/concise/expressive, whereas the latter has the reverse features), whereas Rust is aimed at C/C++ deep in those languages prime use cases where they have little current competition -- certainly not from languages like Python/Ruby/etc. -- not at the boundary where they compete with Python/Ruby.
"C replacement" means a lot of things to different people.
Go doesn't appear to be particularly suited for writing a kernel or drivers, Rust looks better for that. Beyond that, if we're talking about writing user space type applications, can someone point to some that need something particularly C like? There is a whole ton of C code that could easily be done in C, Rust, or go with relatively little downside. Not too many weeks ago someone posted linux coreutils in Rust and someone else posted coreutils in go. I'd be hard pressed to make the case for C over either of those, perhaps raw cycles performance is incrementally better.
Go doesn't appear to be particularly suited for writing a kernel or drivers, Rust looks better for that. Beyond that, if we're talking about writing user space type applications, can someone point to some that need something particularly C like? There is a whole ton of C code that could easily be done in C, Rust, or go with relatively little downside. Not too many weeks ago someone posted linux coreutils in Rust and someone else posted coreutils in go. I'd be hard pressed to make the case for C over either of those, perhaps raw cycles performance is incrementally better.
> Go has been fairly expressly billed as a C/C++ replacement.
I think the community at large has billed it as such, but I haven't seen such a direct statement come from anyone on the Go development team. This is really the core of my original question, why does the community think of Go as a C replacement when it explicitly does not support the feature set required to be such a language?
I think the community at large has billed it as such, but I haven't seen such a direct statement come from anyone on the Go development team. This is really the core of my original question, why does the community think of Go as a C replacement when it explicitly does not support the feature set required to be such a language?
You may be interested in reading http://commandcenter.blogspot.it/2012/06/less-is-exponential... , which is a bit old, but has lots of this history.
I think inevitably we all look at languages from the angle of our own experience. For me, thinking of Go as any sort of replacement for C/C++ comes down to the fact that I've used those languages almost exclusively at a very low level. For me, that is firmware on micro-controllers, and not at the level of linux applications or arduino applications, but direct to the 'bare metal' applications where direct memory addressing and other constructs that are 'poor practice' in high level development are the norm. For example I've implemented an http server on an 8-bit microcontrollers with ~3KB of RAM. I can't imagine doing anything remotely close to that type of work in Go, it's on the wrong planet. Rust on the other hand does seem to have the capabilities required to do that type work so in the end, I don't see them competing in any grand sense, they are different languages for different purposes.
Put in other words, there is a class of problems C/C++ are used for which Go isn't even remotely suitable for, on the other hand, there is a large class of problems that C++ was used for, that could have been written in Java and Go is a good replacement for. I feel that the subset of problems that were/are solved in C/C++ that could not have been solved in something like Java is fairly small. Off the top of my head things like high end video games, high frequency trading, perhaps database type systems where direct memory access may not really be needed yet the performance constraints are tight enough that something like Java was too slow for it. This may be where the 'systems programming language' moniker came from. I would guess that Google has a disproportionately large set of problems that fit into the space that I think is relatively rare for the programming community at large.
Put in other words, there is a class of problems C/C++ are used for which Go isn't even remotely suitable for, on the other hand, there is a large class of problems that C++ was used for, that could have been written in Java and Go is a good replacement for. I feel that the subset of problems that were/are solved in C/C++ that could not have been solved in something like Java is fairly small. Off the top of my head things like high end video games, high frequency trading, perhaps database type systems where direct memory access may not really be needed yet the performance constraints are tight enough that something like Java was too slow for it. This may be where the 'systems programming language' moniker came from. I would guess that Google has a disproportionately large set of problems that fit into the space that I think is relatively rare for the programming community at large.
Yeah, the thing is C/C++ have a wide range of applications, so different alternatives to C/C++ can validly be intended as that and have minimal overlap in core focus.
> I think the community at large has billed it as such, but I haven't seen such a direct statement come from anyone on the Go development team.
Here's an article from Rob Pike both pointing to Go's motivation as a C/C++ replacement and explaining why he thinks it didn't draw that audience:
http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
Here's an article from Rob Pike both pointing to Go's motivation as a C/C++ replacement and explaining why he thinks it didn't draw that audience:
http://commandcenter.blogspot.com/2012/06/less-is-exponentia...
They are indeed targeting different use cases.
I think a potential reason people are comparing the two is because Rust is also great (it's still early, though, so it'll be interesting where people leverage Rust) at the use cases that Go was designed for, while Go cannot touch what Rust was built for. However, the two being defined as system languages with two widely different views on what "system" means doesn't help.
I think a potential reason people are comparing the two is because Rust is also great (it's still early, though, so it'll be interesting where people leverage Rust) at the use cases that Go was designed for, while Go cannot touch what Rust was built for. However, the two being defined as system languages with two widely different views on what "system" means doesn't help.
I am looking forward to seeing browsers and maybe even operating systems written in Rust. Go, not so much.
I'm not so positive that Rust will be so great in cases where you have many developers with different levels of skill and experience working on infrastructure projects. Rust makes the low level stuff easy, but a lot of high level stuff is still going to be easier in Go.
I'm not so positive that Rust will be so great in cases where you have many developers with different levels of skill and experience working on infrastructure projects. Rust makes the low level stuff easy, but a lot of high level stuff is still going to be easier in Go.
I don't think Rust is that much more complicated. There's a few new concepts, but there are proposals to make them easier to use.
I actually feel that Rust is really good at abstractions that make it seem a lot higher-level.
I agree that Rust more complex than other languages, but I don't think it's that much more complex. I think better documentation and tooling will make it more approachable.
I actually feel that Rust is really good at abstractions that make it seem a lot higher-level.
I agree that Rust more complex than other languages, but I don't think it's that much more complex. I think better documentation and tooling will make it more approachable.
I think that having algebraic data types and pattern matching will actually make Rust nicer a lot of higher level things than Go.
"I keep seeing a lot of 'Rust vs Go'"
That's unfortunate. We should be arguing about Ocaml vs. Rust or Ada vs. Go!
That's unfortunate. We should be arguing about Ocaml vs. Rust or Ada vs. Go!
[deleted]
I think Rust has been bad for me. I'm interviewing for my first technical role at the moment and all I keep talking about is how much I love Rust and look at these cool things I made in Rust and I want to program in Rust all the time.
I mainly receive bemused looks. "We use Java."
I mainly receive bemused looks. "We use Java."
I've been following Rust for a long time, and though I'm happy to see how popular it's become I'm also a bit wary.
When people become attached to an exciting new language, in their elation they tend to envision using it in every context imaginable. But most languages are designed for a particular (and possibly narrow) domain. As you venture further from that domain, things begin to unravel.
Example: after giving a presentation at a recent Rust meetup, someone asked me if they could use Rust as a scripting language. My response was something along the lines of, "sure, it's as Turing-complete as any other language, but why would you want to?" Mostly I would like people to acknowledge that different languages exist to serve different needs, and that there does not and will never exist One Language To Rule Them All.
Rust is a low-level systems language, and it's optimized very, very well for that niche. I'm very happy if you want to use it all time, for everything! But please continue to evaluate it as a systems programming language. There are very good reasons for every feature in the language, but many of those reasons may seem entirely superfluous if you don't appreciate the context in which they were made.
When people become attached to an exciting new language, in their elation they tend to envision using it in every context imaginable. But most languages are designed for a particular (and possibly narrow) domain. As you venture further from that domain, things begin to unravel.
Example: after giving a presentation at a recent Rust meetup, someone asked me if they could use Rust as a scripting language. My response was something along the lines of, "sure, it's as Turing-complete as any other language, but why would you want to?" Mostly I would like people to acknowledge that different languages exist to serve different needs, and that there does not and will never exist One Language To Rule Them All.
Rust is a low-level systems language, and it's optimized very, very well for that niche. I'm very happy if you want to use it all time, for everything! But please continue to evaluate it as a systems programming language. There are very good reasons for every feature in the language, but many of those reasons may seem entirely superfluous if you don't appreciate the context in which they were made.
Why not a single language that scales up and down? Problems come on a continuous range; rather than an infinite number of languages specialized for every spot on the range, it's better for interoperability and tooling's sake to have one language that can accommodate many different styles of programming.
/Scala fan, would and have used it for scripting.
/Scala fan, would and have used it for scripting.
Different domains will be optimally served by different features,[1] and any language that aspires to be usable in every domain must assimilate all of those features somehow. This is especially pernicious when considering how similar features can overlap and interact in unexpected ways, creating a labyrinth of corner cases with which a user must familiarize themselves. To maintain sanity, people will start carving out bits of the language to create "dialects" and restrict themselves to only those dialects, at which point you have effectively created multiple languages, each with their own idioms and learning curves.
Consider as well that as long as there exist languages that are so heavily-laden with features, there will continue to crop up "minimalist" languages like Go which will appeal to people by virtue of sheer simplicity and eat the lunch of the maximalist languages.
[1] An example: you know one thing that's great about using bash instead of Python for quick scripts? I don't need to put quotes around strings! Imagine how much time you'd waste in your terminal if you had to type `git grep foo -- bar.txt` as `git "grep" "foo" "--" "bar.txt"` all the time (which is valid bash, btw), or worse, `git("grep", "foo", "--", "bar.txt")`. TCL adopted this barewords-as-strings behavior as well, and though I hear mixed things about the rest of TCL this feature has always intrigued me. But this feature would be awful for any language where text input or string manipulation were not the predominant activity, so how would you go about turning it on and off? And even if you provide tools to automatically convert source files between barewords-as-strings and barewords-as-keywords, is that even the same language anymore?
Consider as well that as long as there exist languages that are so heavily-laden with features, there will continue to crop up "minimalist" languages like Go which will appeal to people by virtue of sheer simplicity and eat the lunch of the maximalist languages.
[1] An example: you know one thing that's great about using bash instead of Python for quick scripts? I don't need to put quotes around strings! Imagine how much time you'd waste in your terminal if you had to type `git grep foo -- bar.txt` as `git "grep" "foo" "--" "bar.txt"` all the time (which is valid bash, btw), or worse, `git("grep", "foo", "--", "bar.txt")`. TCL adopted this barewords-as-strings behavior as well, and though I hear mixed things about the rest of TCL this feature has always intrigued me. But this feature would be awful for any language where text input or string manipulation were not the predominant activity, so how would you go about turning it on and off? And even if you provide tools to automatically convert source files between barewords-as-strings and barewords-as-keywords, is that even the same language anymore?
> To maintain sanity, people will start carving out bits of the language to create "dialects" and restrict themselves to only those dialects, at which point you have effectively created multiple languages, each with their own idioms and learning curves.
Sure, scripting Scala looks rather different from high-performance Scala. But there's a continuity between them, which allows you to customize the appropriate "dialect" for a particular project, and avoids the overheads of using multiple languages in a project that straddles one of the lines.
> how would you go about turning it on and off
There's already a certain level of syntax customizability in most languages, e.g. I can use an import that will make symbols ('grep) treatable as strings. Whether this is a single language or a suite of languages designed to work closely together is an academic question, but I certainly think it would be possible to write something that allowed you to write (say) C-like code and Python-like code with a much smoother interface between them than there currently is when calling C from Python.
Sure, scripting Scala looks rather different from high-performance Scala. But there's a continuity between them, which allows you to customize the appropriate "dialect" for a particular project, and avoids the overheads of using multiple languages in a project that straddles one of the lines.
> how would you go about turning it on and off
There's already a certain level of syntax customizability in most languages, e.g. I can use an import that will make symbols ('grep) treatable as strings. Whether this is a single language or a suite of languages designed to work closely together is an academic question, but I certainly think it would be possible to write something that allowed you to write (say) C-like code and Python-like code with a much smoother interface between them than there currently is when calling C from Python.
I agree with the use the right language for the job sentiment, but most developers work for other people's businesses and engineering is just as much about designing and building something as maintaining and growing it. I can definitely see why some engineers would want a single "magic bullet" type language that can do everything from replace shell scripting to building complex distributed systems; it's easier to hire people to maintain that program 10 years down the road.
I acknowledge that irrational managers may dictate a single language to fulfill all purposes, but I disagree that sticking to a single language for your entire stack makes it easier to hire people. If you can learn Java, you can learn Python. I'm also not trying to encourage unchecked language proliferation; you can get by with one language for applications, one language for scripting, and, if necessary, one language for all the lower-level stuff.
Scripting, applications, webservices can be met with Python. Especially once you start to look at the different implementations like PyPy. Not much out there can do the entire gamut though. Erlang and Rust look like great compliments for specific needs to a Python-centric company.
You could try looking for positions doing C++ development, and specifically with companies which have embraced the new C++11 features. Rust is extremely close in style to idiomatic modern C++, but with greater static safety guarantees.
Runtime polymorphism is very different in Rust, and sum types are prolific in the standard library, so I'm not sure how "extremely close" it is to C++11. But there are many similarities in other areas, such as memory safety through references with ownership semantics.
If you are applying to the enterprise that won't change in foreseeable future.
Worse, Java really means Java and not any alternative language for the JVM.
Worse, Java really means Java and not any alternative language for the JVM.
> If you are applying to the enterprise that won't change in foreseeable future.
That depends. Not all are bought on the Java hype from the past but it surely is still widespread.
That depends. Not all are bought on the Java hype from the past but it surely is still widespread.
> I mainly receive bemused looks. "We use Java."
Yeah, that happens. You probably should just skip those places to begin with :) I second those who mentioned C++ in the comments. Those places have more chances of appreciating Rust.
Yeah, that happens. You probably should just skip those places to begin with :) I second those who mentioned C++ in the comments. Those places have more chances of appreciating Rust.
What platform have you been working on? Win7 works ok for me, but I've tried to install rust in Ubuntu and Lubuntu (13.10 and 14.04) and get errors during the install. I was following these directions:
https://github.com/rust-lang/rust/wiki/Note-getting-started-...
https://github.com/rust-lang/rust/wiki/Note-getting-started-...
If you jump into IRC[1], we can help you out with that. Most people have the opposite problem: hard on Windows, easy on Ubuntu!
I myself run Ubuntu at the moment, so I can certainly help.
1: #rust on irc.mozilla.org, or http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23ru...
I myself run Ubuntu at the moment, so I can certainly help.
1: #rust on irc.mozilla.org, or http://chat.mibbit.com/?server=irc.mozilla.org&channel=%23ru...
Thanks very much.
It turns out default mem settings in VirtualBox weren't large enough. On IRC they recommended 2.0 GB of ram and that worked for me! ready to rock...
It turns out default mem settings in VirtualBox weren't large enough. On IRC they recommended 2.0 GB of ram and that worked for me! ready to rock...
I love all the "X has been removed from the language" bits that occur in every Rust release.
I'm eagerly awaiting Rust 1.0 to play with it.
These days I'm dabbling with Go and while the toolchain is fantastic and the standard library is fairly comprehensive, I find the language itself to be "meh".
Rust-the-language looks much more promising but I'm holding my breath waiting until it stabilises before I consider it for my next project. I read elsewhere that they are striving for a near-final release at the end of the year so I won't have to wait long, after all :)
Keep it up!
These days I'm dabbling with Go and while the toolchain is fantastic and the standard library is fairly comprehensive, I find the language itself to be "meh".
Rust-the-language looks much more promising but I'm holding my breath waiting until it stabilises before I consider it for my next project. I read elsewhere that they are striving for a near-final release at the end of the year so I won't have to wait long, after all :)
Keep it up!
In the mean time you might want to check out Nimrod or D. These are some other languages in a similar space - compiling to native binaries, but with the amenities of modern languages.
Nimrod looks quite interesting. Not so long ago I was discussing with a colleague how much I long for a statically typed Python with macros, sum types, optional garbage collection/ref-counting etc. Nimrod seems pretty close to that ideal programming language.
Thanks for sharing such nice little gem.
Thanks for sharing such nice little gem.
Nimord is a fantastic programming language, even tho the community is small it features a lot of interesting concepts and the guy behind it: Araq (Andreas Rumpf) is one of the smartest programmers I ever had the pleasure to chat with. I really wish a big corporate could sponsor a bit it, because unfortunately nowadays seems the way to go mainstream.
These are the exact two languages I want to see prosper.
Most important reason is that I want to keep believing that a (bunch of) genius(es) inventing their perfect language that can be practically and widely used without a big company backing is still a thing
Secondly because these languages have so many great ideas with high quality implementations.
Most important reason is that I want to keep believing that a (bunch of) genius(es) inventing their perfect language that can be practically and widely used without a big company backing is still a thing
Secondly because these languages have so many great ideas with high quality implementations.
I've been giving D a shot at making my usual learn new language project, making a JRPG styled game. So far it's been looking pretty good while porting an old engine someone wrote for their senior thesis from D1 to D2. The type system is fairly well featured and flexible to the point where lots of bugs while updating code and porting it to the new standard library and language features were caught by the compiler itself. It's at the point now where while it builds I'm having issues with the OpenGL code since there isn't a good binding that supports OpenGL 2.1 the way the engine was originally using it.
https://bitbucket.org/simcop2387/yage
https://bitbucket.org/simcop2387/yage
The other side of that is that D has had a long time to percolate and hasn't found the success of Go, and soon Rust. So, we come back to the common startup ailment, which is having an awesome product but it just inexplicably doesn't get traction, while the inferior (depending on perspective) product does.
I know there are pockets of D throughout the industry. I know it's catching on at Facebook (and, because I know Facebook folks, I know what an uphill battle those folks are having too). I just don't hear about D nearly as much as I'd expect to over a decade in.
Nothing against D, mind.
I know there are pockets of D throughout the industry. I know it's catching on at Facebook (and, because I know Facebook folks, I know what an uphill battle those folks are having too). I just don't hear about D nearly as much as I'd expect to over a decade in.
Nothing against D, mind.
In my opinion the fact that there were two competing standard libraries (Tango and Phobos) certainly brought confusion and needlessly fragmented the community.
IIRC, at the beginning the whole thing was not being developed in the open and the compiler was proprietary (although the front-end became open source at one point).
Those two things (especially the former) pretty much killed it for me.
D finally matured at a time where I was already more interested and invested in the Lisp/ML family of languages, thus I ended up never considering it for a project.
IIRC, at the beginning the whole thing was not being developed in the open and the compiler was proprietary (although the front-end became open source at one point).
Those two things (especially the former) pretty much killed it for me.
D finally matured at a time where I was already more interested and invested in the Lisp/ML family of languages, thus I ended up never considering it for a project.
Those were definitely the two things that kept me from really considering it in the past. Both of those have now changed for the better and there's a more active community building up again. I think the facebook use of D has also brought some much needed attention to it to the point where the language itself is starting to accelerate changes to move forward. The DMD reference compiler still has some restrictions on the backend of it I think but because of the frontend being available there's now LDC and GDC that are LLVM and GCC versions of the compiler that do much better at optimizing and are fully open source anyway. It's also seemed to help find bugs in both the language spec and the DMD backend from what i've read on the news groups because they've got three very different implementations of the language now that are all mostly compatible (the DMD version is always a little ahead since the other two are essentially ports of it to LLVM/GCC).
The D front end was just relicensed from GPL to Boost. (The front end is shared by DMD, GDC, and LDC.)
I knew something had changed but was unsure of the details. Thanks for the correction.
In a non-systems environment (i.e. I'm fine with garbage collection and don't need perfect performance), assuming I already know OCaml and Haskell, does Nimrod or D have a lot to offer over those?
I have a few years of experiene with Haskell, and recently started Nimrod. It's an imperative language, so the differences are huge of course. I'm more productive in Nimrod. The syntax is great, similar to Python. Nimrod compiles to C without external dependencies, which makes it easy to deploy and easy to bind C libraries. Nimrod's metaprogramming is definitely worth checking out too.
Please be more explicit and specific. Are you saying that the Nimrod imperative style makes some problems easier to solve (can you give an example?), or does "productive" mean something else? What exactly is the metaprogramming good for?
I have also used Haskell in the past. Been using Nimrod for a couple of years now. I agree with defg: the differences are huge. But the great thing about Nimrod is how flexible it is. That's precisely where metaprogramming comes into play, while some features found in functional programming languages are missing from Nimrod they can be implemented fairly easily using Nimrod's macros. For example I have recently implemented syntax sugar for anonymous functions using macros (http://build.nimrod-lang.org/docs/future.html).
I do however find the imperative style of programming more efficient, when working with Haskell I always felt like I was fighting it. So perhaps Nimrod may not be for you, but it's still definitely worth checking out!
I do however find the imperative style of programming more efficient, when working with Haskell I always felt like I was fighting it. So perhaps Nimrod may not be for you, but it's still definitely worth checking out!
Same here, actually. I used to be a pretty strong proponent of Go until I used it in a mid-size project. Now I'm really hoping Rust can fill the gap, and by all indications it's looking like it will.
Man, last time I checked in on Rust one of the things that I didn't like was that the rules for what was public or private by default were complicated for no good reason. Now (maybe .11, maybe a previous change) everything is private by default which is nice and simple.
I did and continue to really like the way they handle encapsulation at the module rather than object level.
I did and continue to really like the way they handle encapsulation at the module rather than object level.
I love that when I read the changelogs for Rust releases, most changes are "Feature X has been removed from the language". These guys are serious about avoiding featuritis.
Agreed, though it would be better not to have added the features to begin with.
If a feature gets added, it is to evaluate its usefulness. Some features make the cut, some don't. Even the ones that don't pan out are useful in that they establish precedent for people who ask for that feature later on; we need only tell them "we tried that, it didn't work out, and here are all of our notes and discussions documenting our reasons why".
If a feature gets released, it is for people to use it. A judicious hand with features saves a lot of trouble down the line. If you are adding too many features you get a big pile of features like C++. I don't see how it is worth arguing that people developing something like a programming language need to very carefully weigh these decisions instead of throwing everything at the wall to see if it sticks.
The main reason to load up on features is that you are anxious your audience won't like you unless you do, but it is a wrong idea about design.
The main reason to load up on features is that you are anxious your audience won't like you unless you do, but it is a wrong idea about design.
You completely misjudge the Rust developers. Features are carefully weighed before implementation. Developer time is not infinite. But ultimately some decisions can only be made with experience, and sometimes (thanks to the domino-effect nature of language design) previous decisions need to be reevaluated as entirely separate parts of the language change. If this were C++, we would have left all those features in rather than taking the trouble to purge them.
You do realize that Rust isn't a stable language yet right? Now is precisely the right time for Rust to experiment with what features are useful and what features are not.
I'm mostly doing Go nowadays but keeping an eye on Rust, which I think would make a good match in my toolbox for areas where Go lacks.
Wondering if there's a roadmap/ETA for v1.0?
Wondering if there's a roadmap/ETA for v1.0?
They're shooting for around the end of this year.
I found this roadmap https://docs.google.com/spreadsheet/ccc?key=0AlWBWplsaTZvdGd...
That Google doc has not been updated in a while.
Also https://github.com/rust-lang/rust/issues?direction=desc&mile...
and https://github.com/rust-lang/rust/issues?direction=desc&labe... , which are the most interesting open questions regarding backwards compatibility.
Also https://github.com/rust-lang/rust/issues?direction=desc&mile...
and https://github.com/rust-lang/rust/issues?direction=desc&labe... , which are the most interesting open questions regarding backwards compatibility.
There might be some reasons to have <> instead of [] for specifying Type arguments (I think [] are a lot easier to read). I can't fathom the reasoning behind choosing "::" instead of a ".".
The reason for <> instead of [] is that both are just as ambiguous to Rust's grammar, and that <> is, unfortunately, more-or-less the industry standard (C++, Java, and soon Swift). I would personally prefer something akin to D's generic syntax (but with a different symbol, since the exclamation point already has meaning in Rust).
The reason for using :: instead of . for paths is because the Rust developers did not want to conflate path lookup and field lookup, which would obscure the runtime costs of indirection. (This is also the same reason why you can't omit the parens when calling a method with no arguments: a field lookup and a method call have wildly different runtime costs.)
The reason for using :: instead of . for paths is because the Rust developers did not want to conflate path lookup and field lookup, which would obscure the runtime costs of indirection. (This is also the same reason why you can't omit the parens when calling a method with no arguments: a field lookup and a method call have wildly different runtime costs.)
Thanks for shedding the light. I really really wish they had chosen [] instead of <>. I use Scala and I have fallen in love with how clean [] looks.
Good to know the reasoning behind ::.
Waiting for Rust 1.0, after it gets released it's Scala for JVM and Rust for everything else (except Qt) :P
Good to know the reasoning behind ::.
Waiting for Rust 1.0, after it gets released it's Scala for JVM and Rust for everything else (except Qt) :P
Here's a recent RFC closed by its author on the subject: https://github.com/rust-lang/rfcs/pull/148
(a big issue with []-generics is that they're easy to confuse with indexing/slicing to a human. <> may look noisy, but it's harder to confuse it with comparisons)
(a big issue with []-generics is that they're easy to confuse with indexing/slicing to a human. <> may look noisy, but it's harder to confuse it with comparisons)
Interesting that you won't replace Qt with Rust, because I'm considering doing it. The reasons:
- Qt core (QList, QMap) can be replaced with Rust std lib
- I don't use QML and Javascript (because Javascript errors don't show up at compile time)
- The only thing missing from Rust is QWidgets, but I'm sure there will be something to replace it
I wouldn't like to use a Rust port of Qt just to get QWidgets for Rust, because it would also mean shipping huge Qt core libraries with my Windows application. I don't need them so I don't want to do that.
- Qt core (QList, QMap) can be replaced with Rust std lib
- I don't use QML and Javascript (because Javascript errors don't show up at compile time)
- The only thing missing from Rust is QWidgets, but I'm sure there will be something to replace it
I wouldn't like to use a Rust port of Qt just to get QWidgets for Rust, because it would also mean shipping huge Qt core libraries with my Windows application. I don't need them so I don't want to do that.
You list Qt core but that's not what I use Qt for. I use it to make GUI apps and it's pretty darn good at it.
QML is the way forward for making GUI apps, you are not supposed to use javascript much (although you can make complete apps with it). You are supposed to have your complex logic in a C++ backend which interacts with the QML frontend.
Maybe QML will have Rust bindings.
QML is the way forward for making GUI apps, you are not supposed to use javascript much (although you can make complete apps with it). You are supposed to have your complex logic in a C++ backend which interacts with the QML frontend.
Maybe QML will have Rust bindings.
What I like about Scala is the use of () for indexing arrays. It feels like a more uniform syntax - indexing an array is conceptually like calling a function from int to elements of the array - and I guess it reduces parsing ambiguity w.r.t. generics.
Though apparently this couldn't be used in Rust, since they want both traits for indexing ( [] ) and calling like a function ( () ) on types that implement those respective traits.
Though apparently this couldn't be used in Rust, since they want both traits for indexing ( [] ) and calling like a function ( () ) on types that implement those respective traits.
Matlab uses () for indexing, and I find it awful - you can't tell the difference between indexing and function calls, making code much harder to understand and reason about. It can be pretty confusing for people learning, too (I teach it to undergrad engineers, and don't get a say in the language choice).
`()` is now overloadable, so one could implement that operators for arrays/vectors/slices to get indexing via ().
Not `map[k] = v;`, which is deal breaker.
Other languages don't offer indexing sugar at all, so even minimal sugar for retrieving elements might be nice. There are however, more significant road blocks, like how to handle returning references (basically, we would be left in a similar situation to the current Index trait, which has its uses, but isn't what most indexing should do).
Right, that too, no first-class lvalues in Rust.
Honestly, it's kind of sad that things are chosen because they're industry standard, instead of how good/nice they are. After using Scala, I think that []'s are much easier on the eyes than <>'s.
When designing a language, you have to decide which hills are worth dying on. Uglier it may be, but if using <> makes our syntax more immediately recognizable to C++ developers, then we have a better chance of succeeding in bringing safety to the low-level niche where C and C++ reign supreme.
Don't worry, once Rust has established a foothold here, then we can start designing the pretty language that will usurp it. :)
Don't worry, once Rust has established a foothold here, then we can start designing the pretty language that will usurp it. :)
I really really hope it changes to [] in future. I am scared of the code with lots of <>, I don't know why but I lose context.
I agree with that. Having worked with languages which use <> and Scala, [] are just magnitudes more readable when expressing the same types.
I hate the `<>`s, but the semantics are enticing enough for me to do all of my current personal projects in Rust. I would love Haskelly syntax, but life is never perfect... maybe somebody will make a pre-processor or something! Haha.
I agree, it's not a deal-breaker. It's just that freezing something into a language forever because it's easier for someone just starting out feels wrong. Once you're familiar with the language, you have to deal with the ugliness forever.
I'm not sure what you're saying here, do you mean like in 'std::gc::Gc<T>' ?
Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.
Using :: to indicate a submodule has tons and tons of precedent. The only prominent example I can think of is PHP, and there was a ton of outrage when it didn't use ::.
Language design error: syntax error, expected T_PAAMAYIM_NEKUDOTAYIM
I maybe be remembering some of these wrong, but I think these don't use :: (mostly . instead): Java, C#, Haskell, Clojure.
I don't know about Clojure, but . in Java is ambiguous in the grammar, since it's also used for method calls. And . is function composition in Haskell. I can understand why Rust would want a different sigil.
I think I saw some proposal to replace the function composition from prelude (.) with some other symbol, and presumably making it illegal to define operators named (.). This would of course break a lot of code, but it seems simple enough to make a largely automated transition.
The reason for the proposal was that (.) for function composition made the grammar more complex or problematic because of the accessing 'operator' (.), and/or something that had to do with more fancy accessing and such (lenses?).
The reason for the proposal was that (.) for function composition made the grammar more complex or problematic because of the accessing 'operator' (.), and/or something that had to do with more fancy accessing and such (lenses?).
If it's meant to signify paths, why not use the sigil that everyone uses for path separation, i.e. /
Because this is ambiguous in any language that uses that same character as the division operator. The compiler wouldn't be able to tell whether `foo/bar + 2` is "divide foo by bar, then add two" or "add two to the bar item found in the foo namespace".
Theoretically it's solvable by requiring whitespace to surround all arithmetic operators, which is actually a bit of an intriguing proposition because it would then also allow you to use dashes in variable names and have it be unambiguous, i.e. `foo-bar/qux - baz / spam` would unambiguously mean "divide baz by spam, then subtract it from qux in the foo-bar namespace". But nearly all languages try to avoid this sort of whitespace dependence (look at the ancient furor over the `> >` requirement in C++), and it would be quite a reach for Rust to start championing it now.
Theoretically it's solvable by requiring whitespace to surround all arithmetic operators, which is actually a bit of an intriguing proposition because it would then also allow you to use dashes in variable names and have it be unambiguous, i.e. `foo-bar/qux - baz / spam` would unambiguously mean "divide baz by spam, then subtract it from qux in the foo-bar namespace". But nearly all languages try to avoid this sort of whitespace dependence (look at the ancient furor over the `> >` requirement in C++), and it would be quite a reach for Rust to start championing it now.
Something has precedent doesn't mean you ought to do it. kibwen explains the reason above.
While this is true, that doesn't mean precedent is irrelevant. While what kiwiben said is true, https://github.com/rust-lang/rfcs/pull/148#issuecomment-4771...
i would really like to use rust for a project. but i don't know what i can do with it. any ideas? or which project can i join to work with rust?
> i don't what i can do with it. any ideas?
Well, like any turing-complete language, technically anything, though Rust tends to be lower-level than most.
What kinds of programming do you like to do?
Well, like any turing-complete language, technically anything, though Rust tends to be lower-level than most.
What kinds of programming do you like to do?
I've used Ruby and Python and PHP for web related projects. I've used C for low level programming, Linux modules and SCADA programming running on QNX. So I guess I like pretty high level and low level programming
Well, there are a number of web frameworks being worked on, maybe checking them out and helping out would be a good idea? https://github.com/iron/iron was on HN asking for help the other day.
Work through project euler?
So there has been what seems to be a lot of attention on high level performant languages lately; Rust, Go, Nimrod, D. Languages that can provide performance in the ballpark of C, or at least faster than a lot of other high level languages. High level languages that still keep an eye on what can be implemented efficiently.
But I wonder; if these newer 'systems' (which we can define to be very performant, though not necessarily C-level performant) languages are so interesting, why don't any of the older systems languages come up? Like Free Pascal or Ada (I think this language is a 'systems' language in this sense?). Are these languages viable today, if you already can afford to use relatively new languages with all that that entails of lacking libraries etc.? Or are they dead ends? It seems weird to me that when talking about these languages, there seems to just be C/++ and these newer languages, while the older performant languages seem to not come up. Is this because they aren't suitable for most people, or because people don't know about them/forgot about them? I don't know myself, since they seldom seem to come up in discussions on forums like this.
But I wonder; if these newer 'systems' (which we can define to be very performant, though not necessarily C-level performant) languages are so interesting, why don't any of the older systems languages come up? Like Free Pascal or Ada (I think this language is a 'systems' language in this sense?). Are these languages viable today, if you already can afford to use relatively new languages with all that that entails of lacking libraries etc.? Or are they dead ends? It seems weird to me that when talking about these languages, there seems to just be C/++ and these newer languages, while the older performant languages seem to not come up. Is this because they aren't suitable for most people, or because people don't know about them/forgot about them? I don't know myself, since they seldom seem to come up in discussions on forums like this.
One of Rust's goals is being as fast or faster than C. Not ballpark, but actually competing.
Personally I'm a big fan of Pascal, and I look to Ada sometimes for inspiration (it brought a lot to the table!), but it's quite clear historically that these languages petered off and simply won't get enough momentum to become popular again.
Personally I'm a big fan of Pascal, and I look to Ada sometimes for inspiration (it brought a lot to the table!), but it's quite clear historically that these languages petered off and simply won't get enough momentum to become popular again.
I think the key is in whether these languages get the backing of a Big Institution. Tech people are simultaneously sensitive and oblivious to the political nature of what technologies interest them: For example, all the coverage of Swift is because Apple is backing it. All the coverage of Go is because it has some famous people behind it plus the tacit support of Google. All the coverage of Rust is because it's backed by Mozilla. But when asked directly about their interest most coders will proclaim that it's simply because the technology in these things is better, even though there were plenty of languages that had similar features and implementation quality beforehand. Nobody - especially not people caught within the politics of their own company - has the time or depth of experience to be completely confident about what they would need from a new language and why, so social signalling and appeal to authority tends to rule the day: "No one ever got fired for buying IBM." And so, intentionally or no, people come out of the woodwork to position themselves as early adopters of the "next IBM."
That said, in the long run I think the APIs and tooling experience matters. Free Pascal basically hangs on because Delphi did so well as a third-party environment, even though it was always marginalized on Windows for not being a Microsoft-anointed language. But the Delphi experience was related to the era of the Windows desktop application, and when the market's interest moved away from that the magic was kind of lost. Ada likewise has hung on because it has that gov/mil influence behind it - and its ecosystem is still mostly centered around commercial development environments.
That said, in the long run I think the APIs and tooling experience matters. Free Pascal basically hangs on because Delphi did so well as a third-party environment, even though it was always marginalized on Windows for not being a Microsoft-anointed language. But the Delphi experience was related to the era of the Windows desktop application, and when the market's interest moved away from that the magic was kind of lost. Ada likewise has hung on because it has that gov/mil influence behind it - and its ecosystem is still mostly centered around commercial development environments.
In the case of Rust, I think the hype actually is well-founded, technically. It is aiming for a niche that I have seen no one claim that any other language has accomplished to fill before. So unless you know of some languages that have memory safety with no form of enforced garbage collection (it's part of the library, but completely optional), I'll say that Rust has merit on its own, no matter what organization is backing it.
ATS can also do that.
Darn, forgot about that one. ATS does seem to get considerably less mention than Rust, which may be because of marketing and/or because it is even more scary than Rust (dependent types, oh my).
It's also rather unwieldy to use, much more so than other dependently typed languages (like Idris).
Sadly, despite having useful-looking properties, I suspect it'll serve as little more than inspiration for others.
Sadly, despite having useful-looking properties, I suspect it'll serve as little more than inspiration for others.
It might be that it could serve the niche in which code has to be really performant, and you also need "complete" (to a strict degree) safety guarantees, and Rust can not give enough guarantees in that regard (and it is unacceptable to have a lot of unsafe-blocks). It could even complement Rust, in that regard. The biggest problem might be that ATS looks like a very intimidating language already (I have not tried it myself, so that is just my impression, but the creator seems to share the same sentiment), which might a bit too much of a burden for this purpose.
Many seem to think that only Rust is suitable for kernelspace but are questioning whether Go or Rust is more suitable in userspace. A Go library will work in a Go process (due to the need for (shared) GC in the runtime, among other things), whereas a Rust library that avoids GC (which is idiomatic Rust) will (I think!) be able to expose an interface akin to a C library (similar calling conventions, internal data type layout like C, etc), making it usable from practically any language with C-FFI.
Personally, this is one of the things I look forward to the most. We can create drop-in replacements for C libraries, creating a safer (but just as fast) world one library at a time. And if so desired, all the functionality will be available to anything that can interface with C. Even Go. Your Go libs are stuck in Go's universe. Your Rust libs can be made available to anything that can bind to C.
Go eats the C/C++/Python/Ruby cake from the top, but it just can't go all the way to the bottom. Rust can eat the cake from the very bottom (bare metal/kernelspace and up), but just like Go, the sky's the limit - and for many reasons, like e.g. even better constraints on shared data than Go has, I personally believe it will go even "higher".
My two cents. And as always: More knowledgeable Rust people, if I'm wrong, please correct me.