Earlier quoted context omitted.
Go is the language in the LXC, Docker, containerisation space.
Which is something I never understood. Since you are mainly wrapping OS API, why not take a higher level langage ?
What language you have in mind?
Rust is mostly safety
131–140 of 474 posts
Re: Rust is mostly safety
#132> Modula-3, Eiffel, Sather Nice to see these languages on Rust's team radar, specially Sather. Just shows how you guys have researched prior work, congratulations.
To be clear, Graydon doesn't work on Rust anymore, and hasn't in years. His knowledge of the space is absolutely impressive, though. :)
Only inaccuracy I find is in his claim on safe concurrency in other languages. It existed in Concurrent Pascal (used in Solo OS), Ravenscar Ada (widely deployed), and Eiffel SCOOP (widely deployed). Rust isn't the first doing this. It's just apparently the best at it in system space. Ada camp is making a comeback, though, with ParaSail that looks interesting:
http://www.embedded.com/design/other/4375616/ParaSail--Less-...
Re: Rust is mostly safety
#133Earlier quoted context omitted.
I literally had a conversation about this yesterday. We need someone to champion the work. If that's you, we should get in touch.
email sent
Excellent! It might take me a day or two; I have some stuff to look up in order to give you a proper response.
Re: Rust is mostly safety
#134I'm a lowly ancient Java programmer and I think Rust is far far more than safety. In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community. Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage. I have never seen a more disciplined and bal…
> In my opinion Rust is about doing things right.
On the other hand there is a quite dark cloud on the horizon with the stable vs nightly split. You can't run infrastructure on nightly builds; or add nightly builds to distributions.
Re: Rust is mostly safety
#135The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.
Part of the issue stopping me from jumping in is that it feels like the language is still changing in ways large enough to make it difficult to learn. That may not be true anymore, but it seems like it would take a lot of work to keep up with the current 'best practices'.
It's true that idioms are still developing; there are tools like clippy to help you learn them, though.
Re: Rust is mostly safety
#136Earlier quoted context omitted.
If you want to avoid data corruption in concurrent software, there's always Erlang as an option.
I haven't checked Erlang too well, but is it so that the concurrency in Erlang software is basically actors only? Of course in this space you can also use Akka and even Rust and C++ have actor libraries available. But there are definitely use cases where you don't want to use actors, where you might want to compose several futures together without the overhead of actor mailboxes.
> it so that the concurrency in Erlang software is basically actors only?
Erlang's concurrency is "don't communicate by sharing, share by communicating" enforced at the language level: an Erlang system is composed of processes which each have their own heap (and stack) and an incoming "mailbox", an Erlang process can only interact with the world by calling BIFs (built-in "native" functions, Erlang syscalls if you will) or sending messages to other processes, and messages can only contain immutable data structures (mutation happens only at the process level).
Of course one of the sources for this design is that Erlang comes from a world where 1 = 0 (if you don't have redundancy you don't have a system) thus two processes may live on different nodes (erlang VMs) on different physical machines and shouldn't behave any differently than if they were on the same node.
Re: Rust is mostly safety
#137I think Rust is mostly about safety in the same way that skydiving is mostly about safety. Having safety features that you know you can rely on allows you to take risks that you normally wouldn't in order to accomplish some really awesome things. (I guess in this analogy C is a parachute that you have to open manually, while Rust is a parachute that always opens at exactly the right altitude, but isn't any heavier th…
A lot of C libraries and applications are more like a parachute that was folded by someone who saw a two minute video about parachute folding a couple years ago.
Re: Rust is mostly safety
#138I completely agree. This is what I wrote on Reddit in response to Klabnik's post: Rust can make such an important contribution to such an important slice of the software world, that I really fear that trying to make a better pitch and get as many adopters as quickly as possible might create a community that would pull Rust in directions that would make it less useful, not more. Current C/C++ developers really do need…
We are doing some work like that, but not a ton yet. You need connections to do so, in my experience, and that's tough.
Re: Rust is mostly safety
#139Earlier quoted context omitted.
Rust has three main forms of metaprogramming: generics, which are kind of like templates, but more like concepts (in C++ terms), macros, and compiler plugins.
Wait, Rust has macros that expand to code and mess up debugging, confuse tooling and everything else just like C++? Isn't that exactly what the language should have avoided?
They do expand to code. They shouldn't mess up debugging or confuse tooling. They're much more similar to Lisp-style macros than the C preprocessor.
Re: Rust is mostly safety
#140Earlier quoted context omitted.
I haven't checked Erlang too well, but is it so that the concurrency in Erlang software is basically actors only? Of course in this space you can also use Akka and even Rust and C++ have actor libraries available. But there are definitely use cases where you don't want to use actors, where you might want to compose several futures together without the overhead of actor mailboxes.
> it so that the concurrency in Erlang software is basically actors only? Erlang's concurrency is "don't communicate by sharing, share by communicating" enforced at the language level: an Erlang system is composed of processes which each have their own heap (and stack) and an incoming "mailbox", an Erlang process can only interact with the world by calling BIFs (built-in "native" functions, Erlang syscalls if you wil…
So basically it's like Scala/Akka, except in Erlang you can send functions which is a nice feature. One thing that has kept me from using it in production is its dynamic typing. Once you've been spoiled with a good type system, it's quite hard to go back to dynamic typing.