5 ms·

I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comp

I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better (one could make a lot of negative points about TypeScript and node in general, but the ecosystem is a joy to work with). I feel like this is because people have accepted C and C++ with their respective pain points for close to 50 years now, because there really were no viable contenders. I like how this is starting to change. I still feel Rust, Nim and Zig kind of get the right ideas, but they are not there just yet. I like rust with it's expliciteness and correctness, but I wish some stricter features were opt-in. I do not feel that the borrow checker is the ultimate solution to safety problems. Its strictness can make working with Rust a pain. As the author demonstrates, sometimes you know what you want to do and how to write it in other languages, but it can take quite a while to get it down in such a way that the rust compiler will accept it. I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. I also think Rust may focus a bit too much on the terseness of its syntax. This can make modern Rust hard to read because there are so many special tokens.

peteretep 6y ago
> node ... the ecosystem is a joy to work with I'm not entirely sure I've heard anyone express this before. What do you like about it?
- renke1 6y ago
  Tools like ESLint or prettier are really top-notch. TypeScript itself is a really nice language, too. Its type system is pretty powerful, more than one would expect certainly. Going from TypeScript to Kotlin feels like such a downgrade in that regard. Also the wider JS ecosystem really has some great, high-quality projects that explore (or possibly reinvent, in a positive way) ways to do things in an elegant way.
- j-krieger 6y ago
  Multiple points: I really like how there's a package for everything. Many other languages have adopted this method, but for example in Rust, most packages are not as mature as JS packages are. The JS ecosystem is responsible for spawning services that fund Open-Source developers. Packages are also easy to install. I spent a whole weekend trying to install Postgres and Drogon (a http server) on C++ with conan/vcpkg, and in the end I could only manage with a docker container installing these dependencies via apt-get, which was exactly what I did not want. Furthermore, NPM is the package manager among package managers. No other package manager comes close. Python has too many options, virtual environments and so on. Rust's cargo is good enough, but I really do not enjoy having to install a seperate package (cargo-edit) just to add a package via the command line instead of editing text files. C++'s package management systems are most of the time a total letdown or don't have widespread adoption. Not only that, npm also takes care of a package maintainer needs (semver, transitive dependencies, etc) --- Many people express dissatisfaction about build tools and the like, but as someone who got into webdev at the exact time people began building larger applications on the client, I love them. Sure, when they first appeared they were a pain to work with, but most modern build systems are amazing. I can just include most files (MD, SVG, images) and work with as if they were JSON/JS files and don't have to worry about how it's done internally. --- Prototyping is really fast and important if you work with startups or want to create a proof of concept for a customer. I can throw together a functioning backend with http server and database in a couple of days. Modern JS frameworks are uncomplicated and can be minimal if you know how to use them. For example, my personal site (https://juliankrieger.dev/ https://juliankrieger.dev/) is written in Gatsby and React.js, but it weighs only 20kb. Now, there's not much on it but all content is rendered server side and only rehydrated when I need it. For anyone interested in getting even better results on a personal homepage, I recommend looking at 11ty for a static site generator and htm/preact for an absolutely minimal React implementation that only ships javascript where you really need it. --- I also like how it enables me to write scripts for personal use and at the same time I can use Node for larger projects. I've used python for this in the past, but a large python code base can be a beast of its own. Moreover, not having to recompile dependencies on a code change is a welcome feature. My main problem with Rust are the large compile times. Node even enabled me to hot reload code under the right conditions, making iterative development an insanely fast process.
- skohan 6y ago
  I actually think NPM is an amazing tool. When comparing to many other dependency management solutions, NPM: 1. has a nicer user experience 2. gives a lot of confidence that a project will be reproducible across environments, with only a package.json file Cargo is pretty close, but NPM is the gold standard for dependency management as far as I'm concerned.
  - sacado2 6y ago
    Last time I used NPM, it tended to download megabytes of dependencies for each project. If you used a package in, say, 10 different projects, you had 10 copies of it. Did they solve that issue?
    - Gaelan 6y ago
      This is still the case. There are some alternate package managers (pnpm, yarn) that handle this better, but they both break some tooling. In practice, I've found that it's not too big an issue—most people have plenty of disk space, and if you are running low you can just `rm -rf node_modules` on some old projects and install again next time you touch them.
    - skohan 6y ago
      It's good for isolation: i.e. in general if you copy a directory containing an NPM project to another location, in general it will just work, and deleting something elsewhere on the file system should never affect the project. In general I would argue this is a more important property for dependency managers to have rather than using the least amount of space possible. If you really want to avoid it you can install everything as a global dependency, but it's not best practice.
  - lenkite 6y ago
    I have some frontend developers in my team who think java is slow, but wait minutes waiting for NPM to finish its job. Our backend code builds 3x faster than our frontend code these days.
    - 6y ago
twic 6y ago
> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. I remain to be convinced that this is possible. Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they could be with GC (like iterators). If you make a language GC by default with opt-in ownership, what does your standard library look like? It either isn't usable in ownership code, or it's crippled for GC code.
- j-krieger 6y ago
  Well, the idea would be that references and values alike could be marked to be excluded from the garbage collector and then used in a borrowed way. If you want to interface with the garbage collector, you have to do so in an explicit way. However, I have no idea how to do so.
- johncolanduoni 6y ago
  I think it would need to have a GC like Go’s that allows arbitrary interior pointers. Then most of the standard library could continue to take references, which would be allowed to point to GC or non-GC memory. There isn’t too much in the standard library that wants you to pass things to it to take ownership of that make sense to be shared. For example, the buffered reader structure wants ownership of the file it’s reading from, but it’s not like it’s going to make sense to read the same file descriptor at the same time it’s being read by the buffered reader. I think the bigger problem is that GC pointers will have to work like Rust’s reference counted pointers do today, meaning you need to use mutexes, read-write locks, etc. to mutate anything behind them. Most shared-memory GC languages allow free data races on all member variables, and just provide unordered atomicity to prevent you from being able to cause a race that writes a bad pointer somewhere. Changing that would be a much stronger mismatch, and as long as that’s the case you’re still not going to be able to write Rust code like you would Java or C#.
- teleforce 6y ago
  >I remain to be convinced that this is possible. Check out D language with default GC and the ongoing effort opt-in ownership model: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...
Shorel 6y ago
Fast, garbage collected with plans to add a borrow checker: dlang. It is an absolute joy to write code in D. Only downside is people complaining it has garbage collection.
- ffdjjjffjj 6y ago
  Has there been much progress with the D borrow checker? It always comes up in these threads but it seems to still be missing some key features (parameterized lifetimes for example). What’s the timeline for this landing in some form of “non-experimental”?
sacado2 6y ago
> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. Put everything you don't want to manage into Rcs, RefCells, Boxes and the like, and you'll more or less feel like you're using a (verbose) GCed language (with a loss of performance and safety as a natural consequence). > I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better The fact you call them "server-side language" is a strong bias. Not everything is a client/server app.
- j-krieger 6y ago
  RefCells and Boxes just throw the same errors at runtime instead of compile time.
  - steveklabnik 6y ago
    (RefCell yes, but box no)
    - j-krieger 6y ago
      Woops, I guess I meant RC's and RefCells.
  - estebank 6y ago
    RefCell is runtime "borrow checking" where a panic is thrown if the object is already mutably borrowed. Depending on your use case you might not even care about this behavior because you have other invariants that ensure that you're only borrowing mutably once, you just can't encode it in the type system. Otherwise, you would combine it with Rc[1]: Rc<RefCell<T>>. Box, on the other hand, doesn't have any runtime cost. In fact, it's runtime cost is the same as a borrow: both & and Box<T> are just plain pointers, with the extra benefit of having compile time lifetime checking. [1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...
bumblebritches5 6y ago
Then learn C#. garbage collection is a hard no for a system language.

peteretep 6y ago

> node ... the ecosystem is a joy to work with I'm not entirely sure I've heard anyone express this before. What do you like about it?

renke1 6y ago
Tools like ESLint or prettier are really top-notch. TypeScript itself is a really nice language, too. Its type system is pretty powerful, more than one would expect certainly. Going from TypeScript to Kotlin feels like such a downgrade in that regard. Also the wider JS ecosystem really has some great, high-quality projects that explore (or possibly reinvent, in a positive way) ways to do things in an elegant way.
j-krieger 6y ago
Multiple points: I really like how there's a package for everything. Many other languages have adopted this method, but for example in Rust, most packages are not as mature as JS packages are. The JS ecosystem is responsible for spawning services that fund Open-Source developers. Packages are also easy to install. I spent a whole weekend trying to install Postgres and Drogon (a http server) on C++ with conan/vcpkg, and in the end I could only manage with a docker container installing these dependencies via apt-get, which was exactly what I did not want. Furthermore, NPM is the package manager among package managers. No other package manager comes close. Python has too many options, virtual environments and so on. Rust's cargo is good enough, but I really do not enjoy having to install a seperate package (cargo-edit) just to add a package via the command line instead of editing text files. C++'s package management systems are most of the time a total letdown or don't have widespread adoption. Not only that, npm also takes care of a package maintainer needs (semver, transitive dependencies, etc) --- Many people express dissatisfaction about build tools and the like, but as someone who got into webdev at the exact time people began building larger applications on the client, I love them. Sure, when they first appeared they were a pain to work with, but most modern build systems are amazing. I can just include most files (MD, SVG, images) and work with as if they were JSON/JS files and don't have to worry about how it's done internally. --- Prototyping is really fast and important if you work with startups or want to create a proof of concept for a customer. I can throw together a functioning backend with http server and database in a couple of days. Modern JS frameworks are uncomplicated and can be minimal if you know how to use them. For example, my personal site (https://juliankrieger.dev/ https://juliankrieger.dev/) is written in Gatsby and React.js, but it weighs only 20kb. Now, there's not much on it but all content is rendered server side and only rehydrated when I need it. For anyone interested in getting even better results on a personal homepage, I recommend looking at 11ty for a static site generator and htm/preact for an absolutely minimal React implementation that only ships javascript where you really need it. --- I also like how it enables me to write scripts for personal use and at the same time I can use Node for larger projects. I've used python for this in the past, but a large python code base can be a beast of its own. Moreover, not having to recompile dependencies on a code change is a welcome feature. My main problem with Rust are the large compile times. Node even enabled me to hot reload code under the right conditions, making iterative development an insanely fast process.
skohan 6y ago
I actually think NPM is an amazing tool. When comparing to many other dependency management solutions, NPM: 1. has a nicer user experience 2. gives a lot of confidence that a project will be reproducible across environments, with only a package.json file Cargo is pretty close, but NPM is the gold standard for dependency management as far as I'm concerned.
- sacado2 6y ago
  Last time I used NPM, it tended to download megabytes of dependencies for each project. If you used a package in, say, 10 different projects, you had 10 copies of it. Did they solve that issue?
  - Gaelan 6y ago
    This is still the case. There are some alternate package managers (pnpm, yarn) that handle this better, but they both break some tooling. In practice, I've found that it's not too big an issue—most people have plenty of disk space, and if you are running low you can just `rm -rf node_modules` on some old projects and install again next time you touch them.
  - skohan 6y ago
    It's good for isolation: i.e. in general if you copy a directory containing an NPM project to another location, in general it will just work, and deleting something elsewhere on the file system should never affect the project. In general I would argue this is a more important property for dependency managers to have rather than using the least amount of space possible. If you really want to avoid it you can install everything as a global dependency, but it's not best practice.
- lenkite 6y ago
  I have some frontend developers in my team who think java is slow, but wait minutes waiting for NPM to finish its job. Our backend code builds 3x faster than our frontend code these days.
  - 6y ago

twic 6y ago

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. I remain to be convinced that this is possible. Rust's ownership model exerts huge design pressure on its standard library. There are some parts that just wouldn't work without ownership (like guards), and many that are far less ergonomic than they could be with GC (like iterators). If you make a language GC by default with opt-in ownership, what does your standard library look like? It either isn't usable in ownership code, or it's crippled for GC code.

j-krieger 6y ago
Well, the idea would be that references and values alike could be marked to be excluded from the garbage collector and then used in a borrowed way. If you want to interface with the garbage collector, you have to do so in an explicit way. However, I have no idea how to do so.
johncolanduoni 6y ago
I think it would need to have a GC like Go’s that allows arbitrary interior pointers. Then most of the standard library could continue to take references, which would be allowed to point to GC or non-GC memory. There isn’t too much in the standard library that wants you to pass things to it to take ownership of that make sense to be shared. For example, the buffered reader structure wants ownership of the file it’s reading from, but it’s not like it’s going to make sense to read the same file descriptor at the same time it’s being read by the buffered reader. I think the bigger problem is that GC pointers will have to work like Rust’s reference counted pointers do today, meaning you need to use mutexes, read-write locks, etc. to mutate anything behind them. Most shared-memory GC languages allow free data races on all member variables, and just provide unordered atomicity to prevent you from being able to cause a race that writes a bad pointer somewhere. Changing that would be a much stronger mismatch, and as long as that’s the case you’re still not going to be able to write Rust code like you would Java or C#.
teleforce 6y ago
>I remain to be convinced that this is possible. Check out D language with default GC and the ongoing effort opt-in ownership model: https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in-d/ https://dlang.org/blog/2019/07/15/ownership-and-borrowing-in...

Shorel 6y ago

Fast, garbage collected with plans to add a borrow checker: dlang. It is an absolute joy to write code in D. Only downside is people complaining it has garbage collection.

ffdjjjffjj 6y ago
Has there been much progress with the D borrow checker? It always comes up in these threads but it seems to still be missing some key features (parameterized lifetimes for example). What’s the timeline for this landing in some form of “non-experimental”?

sacado2 6y ago

> I think enabling a language to be garbage collected in general, while making a borrow checker opt in for special, time critical functions is the best of both worlds. Put everything you don't want to manage into Rcs, RefCells, Boxes and the like, and you'll more or less feel like you're using a (verbose) GCed language (with a loss of performance and safety as a natural consequence). > I enjoy Rust and have been writing it for quite some time. However, I feel like server side languages still have a long way to go. Client-side languages in comparison have been only growing better The fact you call them "server-side language" is a strong bias. Not everything is a client/server app.

j-krieger 6y ago
RefCells and Boxes just throw the same errors at runtime instead of compile time.
- steveklabnik 6y ago
  (RefCell yes, but box no)
  - j-krieger 6y ago
    Woops, I guess I meant RC's and RefCells.
- estebank 6y ago
  RefCell is runtime "borrow checking" where a panic is thrown if the object is already mutably borrowed. Depending on your use case you might not even care about this behavior because you have other invariants that ensure that you're only borrowing mutably once, you just can't encode it in the type system. Otherwise, you would combine it with Rc[1]: Rc<RefCell<T>>. Box, on the other hand, doesn't have any runtime cost. In fact, it's runtime cost is the same as a borrow: both & and Box<T> are just plain pointers, with the extra benefit of having compile time lifetime checking. [1] https://doc.rust-lang.org/book/ch15-05-interior-mutability.html https://doc.rust-lang.org/book/ch15-05-interior-mutability.h...

bumblebritches5 6y ago

Then learn C#. garbage collection is a hard no for a system language.