Earlier quoted context omitted.
Facebook Messenger's backend was/is OCaml... React was originally written in SML, then OCaml, then whatever it is now. And a bunch of places use it for various things. https://ocaml.org/industrial-users
React was never written in SML or Ocaml. It was originally called FaxJS, and the source code is published online. A version of React was built to run in ReasonML, which is a flavor of Ocaml for the web, but Reason didn't even exist before React was fairly well established.
The borrowchecker is what I like the least about Rust
161–170 of 459 posts
Re: The borrowchecker is what I like the least about Rust
#162Earlier quoted context omitted.
Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…
[flagged]
I think that's harsh. IME Go excels in a business setting where the focus is on correct, performant, maintainable, business logic in larger organizations, that's easy to integrate with a bunch of other systems. You can't squeeze every last bit of low-level performance out of it but you can get ... 9x% of the way there with concurrent code that is easy to reason about.
Re: The borrowchecker is what I like the least about Rust
#163Regarding Indexes: "When the same borrowchecker makes references unworkable, their solution is to... recommend that I manually manage them, with zero safety and zero language support?!?" Language support: You can implement extension traits on an integer so you can do things like current_node.next(v) (like if you have an integer named 'current_node' which is an index into a vector v of nodes) and customize how your ne…
> If you go out of bounds, Rust will panic and tell you exactly where it panicked This arguement has a long history. It is a widely used pattern in rust. It is true that panics are memory safe, and there is nothing unsafe about having your own ref ids. However, I believe thats its both fair and widely acknowledged that in general this approach is prone to bugs that cause panics for exactly this reason, and thats bad.…
I wish Rust had syntax or a directive to make Rcs a bit less obtrusive.
Re: The borrowchecker is what I like the least about Rust
#164I don't use Rust much, but I agree with the thrust of the article. However, I do think that the borrowchecker is the only reason Rust actually caught on. In my opinion, it's really hard for a new language to succeed unless you can point to something and say "You literally can't do this in your language" Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also…
Agreed. As a comparison Golang was sold as "CSP like Erlang without the weird syntax" but people realized channels kind of suck and goroutines are not really a lot better than threads in other languages. The actual core of OTP was the supervisor tree but that's too complicated so Golang is basically just more concise Java. I don't think this is a bad thing but it's a funny consequence that to become mainstream you ha…
> Golang is basically just more concise Java.
That is exactly how it was sold.
A safe C, or a nicer simpler Java.
Nobody cared about Erlang back then and nobody does today.
I write Erlang for a living.
Re: The borrowchecker is what I like the least about Rust
#165Earlier quoted context omitted.
I'm not sure.. without the borrow checker you could have a pretty nice language that is like a "pro" version of golang, with better typing, concise error handling syntax, and sum types. If you only use things like String and Arc objects, you basically can do this, but it'd be nice to make that not required!
That's my whole point. Without the borrow checker it would have been a nice language, but I believe it would not have gotten popular, because being nice isnt enough to be popular in the current programming language landscape.
Rust's original author agrees with you: https://graydon2.dreamwidth.org/307291.html
Re: The borrowchecker is what I like the least about Rust
#166I don't use Rust much, but I agree with the thrust of the article. However, I do think that the borrowchecker is the only reason Rust actually caught on. In my opinion, it's really hard for a new language to succeed unless you can point to something and say "You literally can't do this in your language" Without something like that, I think it just would have been impossible for Rust to gain enough momentum, and also…
About 20 years ago your choice of language basically boiled down to what you were going to pick for your web server. Your choices were
- Java (popular among people who went to college and learned all about OOP or places that had a lot of "enterprise" software development)
- Ruby on Rails (which was the hot new thing)
- Python or Perl to be the P in your LAMP stack
- C++ for "performance"
All of these were kitchen sink choices because they wound up needing to do everything. If you went back in time and said you were building a language that didn't do something incredibly common and got in the way of your work, no one would pick it up.
Re: The borrowchecker is what I like the least about Rust
#167Earlier quoted context omitted.
To make sure I understand correctly: did you want to read a `String` and have lots of references to slices within the same string without having to deal with lifetimes? If so, would another variant of `Rc ` which supports substrings that also update the same reference count have worked for you? Looking through crates.io, I see multiple libraries that seem to offer this functionality: [1]: https://crates.io/crates/arc…
It’s deeper than that. Let’s pretend I was in C. I would allocate one big flat segment of memory. I’d read the “JSON” text file into this block. Then I’d build an AST of nodes. Each node would be appended into the arena. Object nodes would container a list of pointers to child nodes. Once I built the AST of nested nodes of varying type I would treat it as constant. I’d use it for a few purposes. And then at some poin…
Something like the following? I am trying and failing to reproduce the issue, even with mutable AST nodes.
use bumpalo::Bump;
use std::io::Read;
fn main() {
let mut arena = Bump::new();
loop {
read_and_process_lines(&mut arena);
arena.reset();
}
}
#[derive(Debug)]
enum AstNode {
Leaf(&'a str),
Branch {
line: &'a str,
meta: usize,
cons: &'a mut AstNode
},
}
fn read_and_process_lines(arena: &Bump) {
let cap = 40;
let buf: &mut [u8] = arena.alloc_slice_fill_default(cap);
let l = std::io::stdin().lock().read(buf).expect("reading stdin");
let content: &str = str::from_utf8(&buf[..l]).unwrap();
dbg!(content);
let mut lines = content.lines();
let mut latest: &mut AstNode = arena.alloc(AstNode::Leaf(lines.next().unwrap()));
for line in lines {
latest = arena.alloc(AstNode::Branch{line, meta:0, cons: latest});
}
println!("{latest:?}");
}Re: The borrowchecker is what I like the least about Rust
#168I think under the constrained of not using GC and not defaulting to unsafe memory that the borrow checker is a decent design.
The constraints mean that you need some form of formal verification of your lifetimes.
These can get very complex and difficult to use. So it might make sense to limit their expressiveness and instead rely on unsafe escape hatches.
I think Rust's borrow checker provides a decent tradeoff between easy of use and how often unsafe is needed. There are rough edges and progress has been slow, but I have yet to see anything radically better. Other system PLs require a lot more unsafe usage (e.g. Zig) and I'm not aware of any mainstream system PLs that offer much more expressive verification.
Re: The borrowchecker is what I like the least about Rust
#169Earlier quoted context omitted.
This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.
I think there are two other big differences that also helped Rust become popular: * Rust has a C++-flavored syntax, but OCaml has a relatively alien ML-flavored syntax. * Rust has the backing of Mozilla, but I don't think OCaml had comparable industry backing. (Jane Street, maybe?)
Facebook and their Reason?
Re: The borrowchecker is what I like the least about Rust
#170Earlier quoted context omitted.
This is also somewhat backed up by the fact that OCaml (to my understanding) is basically GC Rust without a borrow checker, and yet it’s basically a hobby language.
Idiomatic programming in a functional language requires garbage collection. There is a reason languages like OCaml and Haskell have a garbage collector. Without it, programming in these languages would be completely different. If you look at it from that perspective, then Rust is the hobby language.
> Without it, programming in these languages would be completely different.
How different?