20 ms·

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, th

by adeon 4y ago

I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I've written Rust for years now and this still occasionally can really slow me down. Rust is still a very nice language so I just deal with it :) no pain no gain. I would love a Rust-with-GC or something in that spirit that is similar to Rust but automatically figures out lifetimes as much as possible and GCs whatever it cannot figure out automatically. I've looked at languages like Nim and read about research languages like Koka so I'm optimistic something will emerge from this space I really like.

yeputons 4y ago
> I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an RPC/HTTP request, and a user closed a particular window, should you abort the request or not? What if the user have closed all windows except one? Can they actually close window X without doing something in window Y first? What should happen if you forgot to abort the request and now the callback is called, but the original caller is gone?
- taneq 4y ago
  I feel this fact is grossly underappreciated. Caring about speed and correctness but not ownership and lifetimes (and thread safety and race conditions and...) is like caring about road safety but not caring about headlights. You're not avoiding ownership and lifetime problems, you're just avoiding looking at them.
  - preseinger 4y ago
    Thread safety, and memory model safety, and all this important stuff, is important! But ownership and lifetimes are models of reality that Rust asserts as part of its domain language, which, like all models, are approximations of reality, not reality itself. They're useful to the extent that they help to solve a given problem. And not all problems fit into the assumptions that they assert.
- valenterry 4y ago
  I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garbage collected languages such as Haskell or Scala. I would even say that those languages make a correct solution easier than in Rust, but they trade in a bit of performance for it (e.g. by using immutable datastructures instead of an ownership model). But for async stuff, I think this is actually simpler. However, when performance is key, then Rust is by far the easiest solution to get it performant and still correct.
  - shultays 4y ago
    "good performance" is a relative term. You may consider Haskell or Scala having "good performance" but for others having garbage collection itself is a big no. So you are either left with Rust's approach where you limit the programmer, or C++'s approach where you leave memory management mostly to the programmer
    - valenterry 4y ago
      I think you missed the point here. My response was focussed on the part of the challenges of async logic. And what OP essentially said is that Rust does not only help performance because of the ownership model (vs. garbage collection), but also because it makes it easy to come up with correct and performant solution to async-related problems. My point was that, when ignoring the performance benefits of ownership model vs. garbage collection, a language like Haskell or Scala makes a performant and correct solution for async problems easier than Rust does - at least at the current point in time. I hope it's more clear now.
  - NoGravitas 4y ago
    You can get great performance from garbage collected languages, to be honest. I guess what you can't get is perfectly predictable latency — but that only matters for a pretty narrow class of applications.
    - Hirrolot 4y ago
throwamon 4y ago
Sounds like OCaml is exactly what you want. Many of Rust's features are even inspired by it.
- ssokolow 4y ago
  As well as syntactic constructs. For example, Rust's unusual 'a syntax for lifetime parameters is Ocaml's syntax for generics because lifetimes are a special class of generics.
aphexairlines 4y ago
I think that's ocaml. Higher level, with GC, nice type system, no traits but signatures and higher order modules might be enough for you, and a compiler that produces fast native binaries.
- adeon 4y ago
  I think you are pretty spot on here. I write Rust and Haskell most of the time, where the choice depends on the kind of project I'm working on. Also I've written Rust professionally but Haskell has been confined to random hobby projects. I love Haskell but it has its own flavor of problems. I've meant to brush up a bit on OCaml; I've heard it has interesting features in its module system that Haskell does not have (maybe what you call "higher order modules").
  - ChadNauseam 4y ago
    Yup. Professional OCaml dev here, higher order modules are pretty cool. But OCaml shows its age and without typeclasses I don't find it very pleasant to program in. Most days I'd rather use Rust to be honest.
- jnash 4y ago
  Yep ocaml seems to be a perfect balance of all the best of other languages.
- adastra22 4y ago
  There are plenty of languages to choose from if you allow a GC. I think Rust's niche is systems-level programming where a garbage collector is an impossibility. I wish there was an easier to use language with Rust's features which occupied this niche. I find myself reaching for modern C++ instead of Rust when I want to be productive :(
  - adev_ 4y ago
    > I find myself reaching for modern C++ instead of Rust when I want to be productive :( You are not the only one, this is also my experience. And if you think about it: This is fine. There is a reason why we are not using TLA+ or format proofs framework when we want to do quick prototyping: Safety has a cost like everything else. It can be a run-time cost (in case of ARC or GC languages) or a mental effort / productivity cost but it is still a cost.
nicoburns 4y ago
Swift is by far the closest from a language point of view, but alas the ecosystem is all-but-nonexistent outside of the Apple systems.
- josephg 4y ago
  This is a shame. Swift could be a lovely general purpose language. I like the balance swift strikes between ease of use, expressiveness and performance. Like, swift has an equivalent of Option - but there’s syntax sugar for it. Rust has String / &str / Etc. To get a SSO string you need to pull in an external crate. Swift just has a built in, good, general purpose SSO string as part of the language. But adding random half baked features to swift seems to be on the promotion path at Apple. Nothing is well documented. The language doesn’t feel stable and there isn’t much of a broad community like there is with rust, javascript and python. It’s a pity!
- efnx 4y ago
  I would argue that swift is pretty distant compared to the ML family of languages - specifically Haskell. Besides garbage collection, the biggest difference between Haskell and Rust is that Haskell already has higher kinded types.
teucris 4y ago
What about a transpiler that added a ^ operator that made a variable actually an Arc and inserted unwraps, clones, etc as necessary?
0des 4y ago
Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC
- adeon 4y ago
  I like Go a lot. At my previous employer a lot of the systems we wrote for log processing were written in Golang. And I thought it was really nice; I can compile my code really quickly and code in general will run pretty fast. I've only used in the space of big data file processing though. My only real issue with Go is that I feel the language part itself is simplistic and doesn't have the kind of type/trait/typeclass/similarthing like Rust or Haskell has. In Haskell I especially like doing DSLs using monads, e.g. I did a integer-problem-to-SAT-problem DSL and another DSL for NetHack playing AI. In Go making these DSLs is more pain. Although I think that would be true for Rust as well, just not as much.
- mftb 4y ago
  Just wacky I had to scroll this far to see Go mentioned. In certain contexts Rust is very impressive, in others Go is a much better choice. I'm really starting to hope that we'll see some of the important advancements in Rust packaged up in a better language.
  - ncmncm 4y ago
    Go is very deliberately designed for when you depend on a team with sharply limited skills.
    - mftb 4y ago
      These one-liners aren't super-constructive, my own comment was hardly in-depth, so whatever... On any team or in a community your most likely to have a range of skill levels across members. A language can be many things, a powerful tool or a strong barrier. When I first heard about Rust I thought we were on the verge of getting some real advancements across a much larger community of developers and scope of projects. Instead I think we're headed further down a path of at least 3 major groups of PL (scripting, memory-managed, precise semantics). Who knows, maybe it's for the best. If so we better get busy improving the inter-op.
Ar-Curunir 4y ago
I think some aspects of ownership are useful, e.g. move semantics and mutable/immutable references. withoutboats had a good post about a Rust-with-ownership-and-GC language a while back: https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/
teleforce 4y ago
Try D it has most features that you just described. It feels Phytonic and it's GC by default[1]. There is an ongoing work for borrow checker for D language, and pardon the pun but I believe D is borrowing just the right amount features from Cyclon and Rust for safer compiled software without overly complex programming syntax. [1]Origins of the D programming language: https://dl.acm.org/doi/abs/10.1145/3386323 https://dl.acm.org/doi/abs/10.1145/3386323
crabbygrabby 4y ago
Without diving into completely obscure programming languages, you can look at Scala, F#(doesn't scale super great ime), or I guess golang. That said, they all don't give you what rust gives you and have their own troubles. The truth is, either you care about life times and ownership, or you really don't care much about speed and correctness. Not saying that targeted at you as a person, but the royal "you". Even in c/c++ I have to think about that stuff, there's just no tools for it . Fwiw you can import crates to have a gc in rust. To me it defeats the purpose. Wishing you the best on your search
- mbrodersen 4y ago
  What makes you think that F# doesn’t scale? Anything you can do in (say) C# you can do in F#?
birdfood 4y ago
I've bounced around a few languages this year, looking for a language to use in my spare time for fun / enjoyment / skills growth (I have a similar set of criteria to you). I've looked at rust, swift, haxe, zig, and now nim, and I think I'll be sticking with nim. I like that it's seemingly simple, and takes care of memory management for you, but you still have access to pointers if you want them and can extend the language with its macros. It seems like a language that I'll be able to grow with / pick up complexity as I want it, but by default I'll have concise readable code. What was your take on nim?
- adeon 4y ago
  There were many things I liked about Nim: * The compiled programs run pretty fast. * Compiling is pretty fast too (compared to Rust or Haskell). * It's easy for me to bind to whatever C library I have even if nobody made nice Nim packages for it. This one was important for the project I was working on. * There is a GC, but if you choose the proper GC it will be based on reference counting (or if you are compiling to JavaScript, it'll use JavaScript's GC). It means I don't have to care about cleaning up resources. My memory may be wrong but I think Nim also tries to remove reference counting checks when it can. I haven't ever checked in the compiled code does it do a good job at this. * The language rarely complains that something in my code is wrong; there's no borrow checker complaining. Even with little experience I was able to write some quite complicated code. It's like Nim wants to do its best to compile and run my crappy code. * It's easy to read. Maybe because it looks so much like Python and I have lots of Python experience. Nim does not want to complain about your code unless it has to. Despite being statically typed, you don't have to write type definitions that much. There are things I don't like as much: * The story for running threads in Nim is not great. You can run OS-level threads but it's a bit janky (you'll have to now care what data can be shared). It wouldn't stop me from writing multi-threaded software though if I really needed threads. * The documentation could be a bit better. I think Nim project should take this giant page: https://nim-lang.org/docs/manual.html https://nim-lang.org/docs/manual.html and reorganize it and make sure the language is easy to read and find stuff. I often have trouble finding documentation on some language feature. I think the project is acknowledging this right in the first paragraph "This document is a draft! Several of Nim's features may need more precise wording. This manual is constantly evolving into a proper specification." This one is harder to pinpoint into specific examples but the language feels a bit immature. I feel like there's bunch of half-baked features that were thrown in on a whim idea. And obviously the package ecosystem isn't as wide as in more established programming languages. I looked it up and Nim has apparently existed since 2008; I'm sure it used to be way more immature ;) Despite the negatives, I think Nim is an amazing tinkerer's language. I can very quickly write programs that will be speedy and easy to read. I'm not sure I'd start a very complicated large project in Nim though. I am bullish that Nim will mature and its userbase will grow, fixing some of the warts. In a few months I plan to take a long vacation and work on a video game with my friend. There is a high chance that I'm going to use Nim for this project; to make something that runs both in browser and also natively.
bin_bash 4y ago
I know some folks are working on this but I just want cargo for JS
inChargeOfIT 4y ago
I really like the idea of something like vlang (https://vlang.io https://vlang.io), as I've tried multiple times to find the motivation to learn Rust, but always end up going back to golang for the simplicity.
- Tozen 4y ago
  Unless there is some very compelling reason to need Rust, a lot of people would be better off with Golang or Vlang, because it would make their lives easier in terms of more general usage and ease of use.
sprkv5 4y ago
OCaml[1] is what you are looking for. You also might want to look at Roc[2], even though that's not released yet. 1. https://ocaml.org/ https://ocaml.org/ 2. https://www.roc-lang.org/ https://www.roc-lang.org/
goodpoint 4y ago
> I've looked at languages like Nim and read about research languages like Koka Nim is indeed going in the right direction with ORC/ARC
syntheweave 4y ago
In addition to the Ocaml recommendations I suggest Haxe, which is basically "Ocaml concepts transposed into a compiler targeting various GC runtimes". (Compiler is also written in Ocaml - it's not kidding around) Easy to pick up if you already know JS syntax, and basically covers the "best-of" of static inferred type systems, but you can easily break out of it if you need dynamic or low-level behavior. Downside is that it's not convenient if you just want one standard library and runtime because it targets all of them. You have to justify the trade-offs involved in that, but it's a good secret weapon.
dagmx 4y ago
Sounds like you're describing Swift. I'm trivializing it, but Swift is basically a higher level Rust with everything wrapped in an Arc.
- therockhead 4y ago
  As someone who does Swift 9-5 and dabbles with Rust, this statement rings true to me.
labrador 4y ago
People don't like to mention C# since like PHP, it has a bad rep from early days, but C# 10 and .NET 6 hit all the sweet spots people are mentioning. C# and .NET now run on Linux and Mac and compile to a single executable like Go with tree shaking so the binary is much reduced. I don't really care, but it's a shame people don't take another look at C#. When I learned Rust I was surprised how similar it felt to C#, but much more ergonomic.
- orthoxerox 4y ago
  Static interfaces are still in preview, DUs aren't being actively worked on, that's what I miss from Rust when I'm writing C#.
  - NoGravitas 4y ago
    Have you used the OneOf library? It's not DUs, but it's kind of an 80% solution in that space.
DeathArrow 4y ago
>I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I think F# might fit this role.
TheCipster 4y ago
I have high hopes for Jakt: https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt
renonce 4y ago
Would it be possible to do something like Rust+Go where you integrate Go code natively into Rust? So Go pointers become `GoPtr<T>` where `GoPtr<T>: Copy + GC` etc. Then all Go structs implement `GoStruct` which would have a static method called `reflect` that returns all the information required for type reflection. One thing I love about Rust is its genericity that at least makes imagining such things possible, though I do expect a lot of engineering effort.
kitd 4y ago
D lang is incorporating a borrow-checking system. I'm not certain how far along they are with it. Walter Bright posts here often and will know. D has a wide range of GC and non-GC techniques that may meet your needs.
- p0nce 4y ago
  And no D programmer says "it was really hard but worth it in the end". It's worth it right from the start.
tucnak 4y ago
Elixir?
- eggy 4y ago
  Not for system-level programming.
  - dymk 4y ago
    Well they want something GCd so it won’t be for systems programming anyways
kaba0 4y ago
Scala might just be that. It has a very strong type system which is quite similar to Rust's, lifetimes are managed by the JVM's state-of-the art GC, and all in all it is a very expressive language. Think of python-level expressivity, but all statically typed with type inference. It also has a similar stance on the functional-imperative question as Rust has - it prefers functional concepts but lets you write imperative code when you want to hand-optimize something. Oh and I almost forget to point out that it can just use basically one of the largest ecosystems, and can also compile to js or native (for the latter there is scala native as well as graal)
- EugeneOZ 4y ago
  Does it have a borrow checker and mutability control?
  - kaba0 4y ago
    It is a GCd language, a borrow checker is very seldom needed outside of that (and frankly, one should just use try-with and similar constructs for other kinds of resources), so why would it need one? As for mutability, it is not enforced on a language level (only shallowly), but the standard library, the language primitives and basically everything makes control over mutability very good. In practice it won't be much different than Rust with the interior mutability pattern.
    - EugeneOZ 4y ago
      “Side-effect” of borrow-checking - there is always only one who can write to a variable. It's much more important than GC.
      - kaba0 4y ago
        Oh I see. No it does not have it enforced at the language level, but it relies heavily on immutable data structures, and the type system is strong enough to express a complete actor-based concurrency library. But since it is interoperable with Java and that exposes low-level primitives of concurrency, it can’t really be made guaranteed data-race free.
sideeffffect 4y ago
> Rust-like programming language that was just a little bit higher level I think the best answer is Scala. It has an awesome community/libraries/ecosystem. See this for example https://news.ycombinator.com/item?id=31601040#31604573 https://news.ycombinator.com/item?id=31601040#31604573 There are other great answers, like F#, Haskell or OCaml, but these are not as mainstream and that comes with its challenges. With Scala you get and awesome IDE, surprisingly wide variety of libraries and the whole Java world as a backup.
NoGravitas 4y ago
Koka and Vale both seem to be decent (experimental) approaches to languages that learn from Rust, both what it got right, and what it got wrong.
- Hirrolot 4y ago
  I think Rust will eventually repeat the story of C++. 1) There will emerge more ergonomic languages that solve real-world problems that Rust attempted to solve. 2) Rust's issues with type system and async will be largely resolved, so it could be used in areas where it is absolutely required.
benibela 4y ago
Pascal was almost there It puts the reference counting in the type system. Like the default string type and arrays (=vectors) are reference counted. And for speed you could use manual memory management Any string literal is like an arc<string>. E.g. in Delphi you can now write string concatenation like: var a = 'bcd'; var b = 'xyz'; var c = a + b; which corresponds to Rust like let a = Arc::new(String::from("bcd")); let b = Arc::new(String::from("xyz")); let c = format!("{}{}", a,b)
- ssokolow 4y ago
  I think the big thing that hurt Pascal initially was the poor start it got off to. By the time things like Borland Pascal came around and fixed the weaknesses from explicitly starting as a teaching language, the damage had already let C pull ahead. As for nowadays, I'd say there are three things that help people to bounce: 1. The big name (Delphi) is proprietary and Free Pascal's documentation feels like it hasn't caught up with various lessons that were learned about how to document a toolchain and standard library since the early 2000s. (And that's before you discover that, apparently, the API documentation is manual enough that the official stance on the Free Vision TUI component's documentation is "go find a copy of the Turbo Vision book from the Borland Pascal manuals", and that the Free Pascal Wiki either neglected to mention one or two classes when they were saying what is yet to be reimplemented or neglected to mention additional restrictions present in the DPMI port.) 2. Similar to with Ada, the ecosystem people are normalized into as they learn programming is leaning more and more strongly on the C-descended syntaxes, making Wirth-style syntaxes feel more alien. I have to admit, compared to something like Rust, there's a certain off-puttingness to having so much verbosity and ceremony in the structure of the block constructs. To exaggerate a bit to get the point across, it's sort of like Pascal expects me to remember all the layouts and lines for what an empty tax form looks like well enough to draw it from memory before filling it out... and that sense of discomfort doesn't go away if I delegate it to my code snippets tool. It lends an ambient sense that there's an iceberg of structure I don't understand and Pascal expects me to remember how many separate peaks it should have poking out of the water and where they should be, without me understanding the topography of the submerged portion. (And yet I still recommend it as the Java/C# equivalent for DOS retro-hobby computing, since it's safer than C and has a much richer library of bundled functionality and comparable performance.) 3. The Free Pascal APIs are aggressively 90s and don't have enough examples to break you from your 2010s-and-beyond expectations. (I was almost tearing my hair out over how to get status updates from their zip extraction code before I realized that I was fixated on the Qt/GTK/DOM/etc. idea of using some kind of signal.connect(my_callback) function rather than using subclassing to set an event handler.) Just, in general, it's an experience that's alien to current language trends and growing more so, the documentation available before you're committed enough to pay for it is wanting, and if you're willing to pay hobbyist prices, you need to do your own research on what exists to pay for.
efnx 4y ago
You should try Haskell. It has everything Rust has (and much more) and it also has a garbage collector. I prefer it to ocaml.
Wodann 4y ago
Have you heard of https://mun-lang.org/ https://mun-lang.org/ ? It's an embeddable scripting language with the goal of being a Rust-like language that supports hot reloading of functions AND data. To achieve the latter, it uses GC'ed memory such that memory can easily be mapped when the memory's type changes. It's still in early development but maybe one day will serve your needs :)
Aardappel 4y ago
Lobster's automatic compile time reference counting has exactly this purpose: https://aardappel.github.io/lobster/memory_management.html https://aardappel.github.io/lobster/memory_management.html
snthpy 4y ago
Have a look at nim through the lens of this talk: https://youtu.be/j0fUqdYC71k https://youtu.be/j0fUqdYC71k

by adeon 4y ago

yeputons 4y ago

> I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an RPC/HTTP request, and a user closed a particular window, should you abort the request or not? What if the user have closed all windows except one? Can they actually close window X without doing something in window Y first? What should happen if you forgot to abort the request and now the callback is called, but the original caller is gone?

taneq 4y ago
I feel this fact is grossly underappreciated. Caring about speed and correctness but not ownership and lifetimes (and thread safety and race conditions and...) is like caring about road safety but not caring about headlights. You're not avoiding ownership and lifetime problems, you're just avoiding looking at them.
- preseinger 4y ago
  Thread safety, and memory model safety, and all this important stuff, is important! But ownership and lifetimes are models of reality that Rust asserts as part of its domain language, which, like all models, are approximations of reality, not reality itself. They're useful to the extent that they help to solve a given problem. And not all problems fit into the assumptions that they assert.
valenterry 4y ago
I think after the (correct) first sentence you are a bit mistaken here. The example you describe can be solved correctly and also with good performance in garbage collected languages such as Haskell or Scala. I would even say that those languages make a correct solution easier than in Rust, but they trade in a bit of performance for it (e.g. by using immutable datastructures instead of an ownership model). But for async stuff, I think this is actually simpler. However, when performance is key, then Rust is by far the easiest solution to get it performant and still correct.
- shultays 4y ago
  "good performance" is a relative term. You may consider Haskell or Scala having "good performance" but for others having garbage collection itself is a big no. So you are either left with Rust's approach where you limit the programmer, or C++'s approach where you leave memory management mostly to the programmer
  - valenterry 4y ago
    I think you missed the point here. My response was focussed on the part of the challenges of async logic. And what OP essentially said is that Rust does not only help performance because of the ownership model (vs. garbage collection), but also because it makes it easy to come up with correct and performant solution to async-related problems. My point was that, when ignoring the performance benefits of ownership model vs. garbage collection, a language like Haskell or Scala makes a performant and correct solution for async problems easier than Rust does - at least at the current point in time. I hope it's more clear now.
- NoGravitas 4y ago
  You can get great performance from garbage collected languages, to be honest. I guess what you can't get is perfectly predictable latency — but that only matters for a pretty narrow class of applications.
  - Hirrolot 4y ago

throwamon 4y ago

Sounds like OCaml is exactly what you want. Many of Rust's features are even inspired by it.

ssokolow 4y ago
As well as syntactic constructs. For example, Rust's unusual 'a syntax for lifetime parameters is Ocaml's syntax for generics because lifetimes are a special class of generics.

aphexairlines 4y ago

I think that's ocaml. Higher level, with GC, nice type system, no traits but signatures and higher order modules might be enough for you, and a compiler that produces fast native binaries.

adeon 4y ago
I think you are pretty spot on here. I write Rust and Haskell most of the time, where the choice depends on the kind of project I'm working on. Also I've written Rust professionally but Haskell has been confined to random hobby projects. I love Haskell but it has its own flavor of problems. I've meant to brush up a bit on OCaml; I've heard it has interesting features in its module system that Haskell does not have (maybe what you call "higher order modules").
- ChadNauseam 4y ago
  Yup. Professional OCaml dev here, higher order modules are pretty cool. But OCaml shows its age and without typeclasses I don't find it very pleasant to program in. Most days I'd rather use Rust to be honest.
jnash 4y ago
Yep ocaml seems to be a perfect balance of all the best of other languages.
adastra22 4y ago
There are plenty of languages to choose from if you allow a GC. I think Rust's niche is systems-level programming where a garbage collector is an impossibility. I wish there was an easier to use language with Rust's features which occupied this niche. I find myself reaching for modern C++ instead of Rust when I want to be productive :(
- adev_ 4y ago
  > I find myself reaching for modern C++ instead of Rust when I want to be productive :( You are not the only one, this is also my experience. And if you think about it: This is fine. There is a reason why we are not using TLA+ or format proofs framework when we want to do quick prototyping: Safety has a cost like everything else. It can be a run-time cost (in case of ARC or GC languages) or a mental effort / productivity cost but it is still a cost.

nicoburns 4y ago

Swift is by far the closest from a language point of view, but alas the ecosystem is all-but-nonexistent outside of the Apple systems.

josephg 4y ago
This is a shame. Swift could be a lovely general purpose language. I like the balance swift strikes between ease of use, expressiveness and performance. Like, swift has an equivalent of Option - but there’s syntax sugar for it. Rust has String / &str / Etc. To get a SSO string you need to pull in an external crate. Swift just has a built in, good, general purpose SSO string as part of the language. But adding random half baked features to swift seems to be on the promotion path at Apple. Nothing is well documented. The language doesn’t feel stable and there isn’t much of a broad community like there is with rust, javascript and python. It’s a pity!
efnx 4y ago
I would argue that swift is pretty distant compared to the ML family of languages - specifically Haskell. Besides garbage collection, the biggest difference between Haskell and Rust is that Haskell already has higher kinded types.

teucris 4y ago

What about a transpiler that added a ^ operator that made a variable actually an Arc and inserted unwraps, clones, etc as necessary?

0des 4y ago

Go and Hare are rust-adjacent with just a touch of crayon involved. I highly recommend both especially Go since you mention rust with GC

adeon 4y ago
I like Go a lot. At my previous employer a lot of the systems we wrote for log processing were written in Golang. And I thought it was really nice; I can compile my code really quickly and code in general will run pretty fast. I've only used in the space of big data file processing though. My only real issue with Go is that I feel the language part itself is simplistic and doesn't have the kind of type/trait/typeclass/similarthing like Rust or Haskell has. In Haskell I especially like doing DSLs using monads, e.g. I did a integer-problem-to-SAT-problem DSL and another DSL for NetHack playing AI. In Go making these DSLs is more pain. Although I think that would be true for Rust as well, just not as much.
mftb 4y ago
Just wacky I had to scroll this far to see Go mentioned. In certain contexts Rust is very impressive, in others Go is a much better choice. I'm really starting to hope that we'll see some of the important advancements in Rust packaged up in a better language.
- ncmncm 4y ago
  Go is very deliberately designed for when you depend on a team with sharply limited skills.
  - mftb 4y ago
    These one-liners aren't super-constructive, my own comment was hardly in-depth, so whatever... On any team or in a community your most likely to have a range of skill levels across members. A language can be many things, a powerful tool or a strong barrier. When I first heard about Rust I thought we were on the verge of getting some real advancements across a much larger community of developers and scope of projects. Instead I think we're headed further down a path of at least 3 major groups of PL (scripting, memory-managed, precise semantics). Who knows, maybe it's for the best. If so we better get busy improving the inter-op.

Ar-Curunir 4y ago

I think some aspects of ownership are useful, e.g. move semantics and mutable/immutable references. withoutboats had a good post about a Rust-with-ownership-and-GC language a while back: https://without.boats/blog/revisiting-a-smaller-rust/ https://without.boats/blog/revisiting-a-smaller-rust/

teleforce 4y ago

Try D it has most features that you just described. It feels Phytonic and it's GC by default[1]. There is an ongoing work for borrow checker for D language, and pardon the pun but I believe D is borrowing just the right amount features from Cyclon and Rust for safer compiled software without overly complex programming syntax. [1]Origins of the D programming language: https://dl.acm.org/doi/abs/10.1145/3386323 https://dl.acm.org/doi/abs/10.1145/3386323

crabbygrabby 4y ago

Without diving into completely obscure programming languages, you can look at Scala, F#(doesn't scale super great ime), or I guess golang. That said, they all don't give you what rust gives you and have their own troubles. The truth is, either you care about life times and ownership, or you really don't care much about speed and correctness. Not saying that targeted at you as a person, but the royal "you". Even in c/c++ I have to think about that stuff, there's just no tools for it . Fwiw you can import crates to have a gc in rust. To me it defeats the purpose. Wishing you the best on your search

mbrodersen 4y ago
What makes you think that F# doesn’t scale? Anything you can do in (say) C# you can do in F#?

birdfood 4y ago

I've bounced around a few languages this year, looking for a language to use in my spare time for fun / enjoyment / skills growth (I have a similar set of criteria to you). I've looked at rust, swift, haxe, zig, and now nim, and I think I'll be sticking with nim. I like that it's seemingly simple, and takes care of memory management for you, but you still have access to pointers if you want them and can extend the language with its macros. It seems like a language that I'll be able to grow with / pick up complexity as I want it, but by default I'll have concise readable code. What was your take on nim?

adeon 4y ago
There were many things I liked about Nim: * The compiled programs run pretty fast. * Compiling is pretty fast too (compared to Rust or Haskell). * It's easy for me to bind to whatever C library I have even if nobody made nice Nim packages for it. This one was important for the project I was working on. * There is a GC, but if you choose the proper GC it will be based on reference counting (or if you are compiling to JavaScript, it'll use JavaScript's GC). It means I don't have to care about cleaning up resources. My memory may be wrong but I think Nim also tries to remove reference counting checks when it can. I haven't ever checked in the compiled code does it do a good job at this. * The language rarely complains that something in my code is wrong; there's no borrow checker complaining. Even with little experience I was able to write some quite complicated code. It's like Nim wants to do its best to compile and run my crappy code. * It's easy to read. Maybe because it looks so much like Python and I have lots of Python experience. Nim does not want to complain about your code unless it has to. Despite being statically typed, you don't have to write type definitions that much. There are things I don't like as much: * The story for running threads in Nim is not great. You can run OS-level threads but it's a bit janky (you'll have to now care what data can be shared). It wouldn't stop me from writing multi-threaded software though if I really needed threads. * The documentation could be a bit better. I think Nim project should take this giant page: https://nim-lang.org/docs/manual.html https://nim-lang.org/docs/manual.html and reorganize it and make sure the language is easy to read and find stuff. I often have trouble finding documentation on some language feature. I think the project is acknowledging this right in the first paragraph "This document is a draft! Several of Nim's features may need more precise wording. This manual is constantly evolving into a proper specification." This one is harder to pinpoint into specific examples but the language feels a bit immature. I feel like there's bunch of half-baked features that were thrown in on a whim idea. And obviously the package ecosystem isn't as wide as in more established programming languages. I looked it up and Nim has apparently existed since 2008; I'm sure it used to be way more immature ;) Despite the negatives, I think Nim is an amazing tinkerer's language. I can very quickly write programs that will be speedy and easy to read. I'm not sure I'd start a very complicated large project in Nim though. I am bullish that Nim will mature and its userbase will grow, fixing some of the warts. In a few months I plan to take a long vacation and work on a video game with my friend. There is a high chance that I'm going to use Nim for this project; to make something that runs both in browser and also natively.

bin_bash 4y ago

I know some folks are working on this but I just want cargo for JS

inChargeOfIT 4y ago

I really like the idea of something like vlang (https://vlang.io https://vlang.io), as I've tried multiple times to find the motivation to learn Rust, but always end up going back to golang for the simplicity.

Tozen 4y ago
Unless there is some very compelling reason to need Rust, a lot of people would be better off with Golang or Vlang, because it would make their lives easier in terms of more general usage and ease of use.

sprkv5 4y ago

OCaml[1] is what you are looking for. You also might want to look at Roc[2], even though that's not released yet. 1. https://ocaml.org/ https://ocaml.org/ 2. https://www.roc-lang.org/ https://www.roc-lang.org/

goodpoint 4y ago

> I've looked at languages like Nim and read about research languages like Koka Nim is indeed going in the right direction with ORC/ARC

syntheweave 4y ago

In addition to the Ocaml recommendations I suggest Haxe, which is basically "Ocaml concepts transposed into a compiler targeting various GC runtimes". (Compiler is also written in Ocaml - it's not kidding around) Easy to pick up if you already know JS syntax, and basically covers the "best-of" of static inferred type systems, but you can easily break out of it if you need dynamic or low-level behavior. Downside is that it's not convenient if you just want one standard library and runtime because it targets all of them. You have to justify the trade-offs involved in that, but it's a good secret weapon.

dagmx 4y ago

Sounds like you're describing Swift. I'm trivializing it, but Swift is basically a higher level Rust with everything wrapped in an Arc.

therockhead 4y ago
As someone who does Swift 9-5 and dabbles with Rust, this statement rings true to me.

labrador 4y ago

People don't like to mention C# since like PHP, it has a bad rep from early days, but C# 10 and .NET 6 hit all the sweet spots people are mentioning. C# and .NET now run on Linux and Mac and compile to a single executable like Go with tree shaking so the binary is much reduced. I don't really care, but it's a shame people don't take another look at C#. When I learned Rust I was surprised how similar it felt to C#, but much more ergonomic.

orthoxerox 4y ago
Static interfaces are still in preview, DUs aren't being actively worked on, that's what I miss from Rust when I'm writing C#.
- NoGravitas 4y ago
  Have you used the OneOf library? It's not DUs, but it's kind of an 80% solution in that space.

DeathArrow 4y ago

>I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I think F# might fit this role.

TheCipster 4y ago

I have high hopes for Jakt: https://github.com/SerenityOS/jakt https://github.com/SerenityOS/jakt

renonce 4y ago

Would it be possible to do something like Rust+Go where you integrate Go code natively into Rust? So Go pointers become `GoPtr<T>` where `GoPtr<T>: Copy + GC` etc. Then all Go structs implement `GoStruct` which would have a static method called `reflect` that returns all the information required for type reflection. One thing I love about Rust is its genericity that at least makes imagining such things possible, though I do expect a lot of engineering effort.

kitd 4y ago

D lang is incorporating a borrow-checking system. I'm not certain how far along they are with it. Walter Bright posts here often and will know. D has a wide range of GC and non-GC techniques that may meet your needs.

p0nce 4y ago
And no D programmer says "it was really hard but worth it in the end". It's worth it right from the start.

tucnak 4y ago

Elixir?

eggy 4y ago
Not for system-level programming.
- dymk 4y ago
  Well they want something GCd so it won’t be for systems programming anyways

kaba0 4y ago

Scala might just be that. It has a very strong type system which is quite similar to Rust's, lifetimes are managed by the JVM's state-of-the art GC, and all in all it is a very expressive language. Think of python-level expressivity, but all statically typed with type inference. It also has a similar stance on the functional-imperative question as Rust has - it prefers functional concepts but lets you write imperative code when you want to hand-optimize something. Oh and I almost forget to point out that it can just use basically one of the largest ecosystems, and can also compile to js or native (for the latter there is scala native as well as graal)

EugeneOZ 4y ago
Does it have a borrow checker and mutability control?
- kaba0 4y ago
  It is a GCd language, a borrow checker is very seldom needed outside of that (and frankly, one should just use try-with and similar constructs for other kinds of resources), so why would it need one? As for mutability, it is not enforced on a language level (only shallowly), but the standard library, the language primitives and basically everything makes control over mutability very good. In practice it won't be much different than Rust with the interior mutability pattern.
  - EugeneOZ 4y ago
    “Side-effect” of borrow-checking - there is always only one who can write to a variable. It's much more important than GC.
    - kaba0 4y ago
      Oh I see. No it does not have it enforced at the language level, but it relies heavily on immutable data structures, and the type system is strong enough to express a complete actor-based concurrency library. But since it is interoperable with Java and that exposes low-level primitives of concurrency, it can’t really be made guaranteed data-race free.

sideeffffect 4y ago

> Rust-like programming language that was just a little bit higher level I think the best answer is Scala. It has an awesome community/libraries/ecosystem. See this for example https://news.ycombinator.com/item?id=31601040#31604573 https://news.ycombinator.com/item?id=31601040#31604573 There are other great answers, like F#, Haskell or OCaml, but these are not as mainstream and that comes with its challenges. With Scala you get and awesome IDE, surprisingly wide variety of libraries and the whole Java world as a backup.

NoGravitas 4y ago

Koka and Vale both seem to be decent (experimental) approaches to languages that learn from Rust, both what it got right, and what it got wrong.

Hirrolot 4y ago
I think Rust will eventually repeat the story of C++. 1) There will emerge more ergonomic languages that solve real-world problems that Rust attempted to solve. 2) Rust's issues with type system and async will be largely resolved, so it could be used in areas where it is absolutely required.

benibela 4y ago

Pascal was almost there It puts the reference counting in the type system. Like the default string type and arrays (=vectors) are reference counted. And for speed you could use manual memory management Any string literal is like an arc<string>. E.g. in Delphi you can now write string concatenation like: var a = 'bcd'; var b = 'xyz'; var c = a + b; which corresponds to Rust like let a = Arc::new(String::from("bcd")); let b = Arc::new(String::from("xyz")); let c = format!("{}{}", a,b)

ssokolow 4y ago
I think the big thing that hurt Pascal initially was the poor start it got off to. By the time things like Borland Pascal came around and fixed the weaknesses from explicitly starting as a teaching language, the damage had already let C pull ahead. As for nowadays, I'd say there are three things that help people to bounce: 1. The big name (Delphi) is proprietary and Free Pascal's documentation feels like it hasn't caught up with various lessons that were learned about how to document a toolchain and standard library since the early 2000s. (And that's before you discover that, apparently, the API documentation is manual enough that the official stance on the Free Vision TUI component's documentation is "go find a copy of the Turbo Vision book from the Borland Pascal manuals", and that the Free Pascal Wiki either neglected to mention one or two classes when they were saying what is yet to be reimplemented or neglected to mention additional restrictions present in the DPMI port.) 2. Similar to with Ada, the ecosystem people are normalized into as they learn programming is leaning more and more strongly on the C-descended syntaxes, making Wirth-style syntaxes feel more alien. I have to admit, compared to something like Rust, there's a certain off-puttingness to having so much verbosity and ceremony in the structure of the block constructs. To exaggerate a bit to get the point across, it's sort of like Pascal expects me to remember all the layouts and lines for what an empty tax form looks like well enough to draw it from memory before filling it out... and that sense of discomfort doesn't go away if I delegate it to my code snippets tool. It lends an ambient sense that there's an iceberg of structure I don't understand and Pascal expects me to remember how many separate peaks it should have poking out of the water and where they should be, without me understanding the topography of the submerged portion. (And yet I still recommend it as the Java/C# equivalent for DOS retro-hobby computing, since it's safer than C and has a much richer library of bundled functionality and comparable performance.) 3. The Free Pascal APIs are aggressively 90s and don't have enough examples to break you from your 2010s-and-beyond expectations. (I was almost tearing my hair out over how to get status updates from their zip extraction code before I realized that I was fixated on the Qt/GTK/DOM/etc. idea of using some kind of signal.connect(my_callback) function rather than using subclassing to set an event handler.) Just, in general, it's an experience that's alien to current language trends and growing more so, the documentation available before you're committed enough to pay for it is wanting, and if you're willing to pay hobbyist prices, you need to do your own research on what exists to pay for.

efnx 4y ago

You should try Haskell. It has everything Rust has (and much more) and it also has a garbage collector. I prefer it to ocaml.

Wodann 4y ago

Have you heard of https://mun-lang.org/ https://mun-lang.org/ ? It's an embeddable scripting language with the goal of being a Rust-like language that supports hot reloading of functions AND data. To achieve the latter, it uses GC'ed memory such that memory can easily be mapped when the memory's type changes. It's still in early development but maybe one day will serve your needs :)

Aardappel 4y ago

Lobster's automatic compile time reference counting has exactly this purpose: https://aardappel.github.io/lobster/memory_management.html https://aardappel.github.io/lobster/memory_management.html

snthpy 4y ago

Have a look at nim through the lens of this talk: https://youtu.be/j0fUqdYC71k https://youtu.be/j0fUqdYC71k