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.
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").
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?
However, when performance is key, then Rust is by far the easiest solution to get it performant and still correct.
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.
* 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 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.
I've been following the nature of code and making a little 2d platformer at the same time using nim + raylib. Compiling to wasm I found to be even simpler than when doing the same thing with C++. It's really nice being able to compile to native or wasm with a single compiler flag.
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:
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!
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)
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.
For example, Rust's unusual 'a syntax for lifetime parameters is Ocaml's syntax for generics because lifetimes are a special class of generics.
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
The best summary I can give of Rust is that it was designed by people who learned from the mistakes of the programming languages that came before it.
The best summary I can give of Go is to quote Rob Pike's response [0] to a request for syntax highlighting in the Go playground:
> Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods (http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.
[0] https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3B...
Go has nil where Rust has Option.
Go has weird not-quite-tuple returns & if err != nil where Rust has Result.
Go has no real enum concept, where rust has its powerful enums and matching constructs.
Go has generics, but only after a decade of pressure from users (and even then, they are much much less useful than Rust's type system).
I like Go and I feel very productive in it, but its commitment to simplicity is dogmatic in many ways and it very much is missing milestone advancements in PLs from the past several decades. It could easily have been made in the 90s.
Throw in great compile to JS capabilities with small bundle sizes and the ability to map Typescript typings into the language so you can seamlessly consume well typed libraries, and man. Killer language, right there.
Viewed through this lens, the resistance on the part of the creators to changes that compromise these values even a little bit makes sense. Generics take time to get used to and any code base that makes extensive use of them will take longer to get up to speed in, even if it enables you to move faster later on.
That talk has really shaped how I look at Go. I think it solves problems that Google has (really large projects built by teams that have a ton of turnover) really well. But as with a lot of things that emerge from Google, it’s a solution to a problem that not too many other companies face. The ones that do will get an awesome tool that’s proven to work. But the ones for whom it’s 90% of what they need are going to get a lot of pushback getting that last 10% accepted because it already does almost exactly what Google needs it to do and any departure from that will be, in their minds, counterproductive.
It just tantalizes me because of how close it is to my ideal general-purpose programming language. There is a large middle ground between the minutes-long compile times of Rust and the seconds-long compile times of Go.
* Option? I don't mind if err != nil, but sure, it would simplify some things.
* Result and real tuples? awesome.
* real enums? sign me up.
impl<'a, H, Fut, Tail> Execute<'a> for Dispatcher<H, Tail>
where
H: Fn(&'a Update) -> Fut + Send + Sync + 'a,
Fut: Future<Output = ()> + Send + 'a,
Tail: Execute<'a> + Send + Sync + 'a,
{> "Go is a good alternative to Rust because it is easy to write performant, concurrent code"
> "Go is not very comparable to Rust. I won't describe why, here's a quote by Rob Pike and I'll strongly imply it's because its creators deliberately avoided complexity, even where useful."
> "You did not explicitly criticize anything about Go, therefore it must not have flaws"
Then I came in and described exactly where I feel Go ignores the state of the art in PLs.
> But what does any of that have to do with (Rust-shaped vomit)
Go doesn't need all those type system gymnastics because it does not have the problem of the borrow checker to deal with and doesn't promise to avoid segfaults for you.
- Go has nil where Rust has Option.
- Go has weird not-quite-tuple returns & if err != nil where Rust has Result.
- Go has no real enum concept, where rust has its powerful enums and matching constructs.
And the point on generics coming late is unfair. All programming languages got major features introduced late (for example async/await in Rust).
But I admit I'd love sum types, a less verbose error handling (but to be honest I'm not sure exactly how), and that I missed generics.
The more I think about it, what I really want is something with the ML feeling of Rust, but in the space that Go occupies (good performance GC languages). Go frustrates me because it nails the runtime and tooling side of things but falls far short of it in the other ways I mentioned.
The usual objection is that it requires a .NET runtime, whereas Go produces a single self-contained executable. But .NET can produce self-contained executables these days.
That is why I find Rust and Go to be dissimilar. Rust is a language full of good ideas, almost all of which didn't originate in Rust. Go feels like it was designed with a very specific brief - "we want C but with GC and easy concurrency" - but whose designers otherwise had an NIH syndrome-like aversion to good ideas and common sense.
I am not saying that Go and Rust are similar or not. I don't really agree with GP's comment where Go should be in the running for a Rust-with-GC/slightly-higher-level-Rust, but the frankly dismissive Rust Good therefore not similar to Go Bad is not justified. Although the conclusion regarding similarity is probably correct.
Also, this is a little off topic, but I have seen multiple people say that Go 'was designed with a very specific brief - "we want C but with GC and easy concurrency"' and then go on to complain about the lack of things like generics, destructuring match syntax, functional concepts, etc. But, all of those discussion, including your comment, start out with what seems to be an acknowledgement that Go's design had a very specific target. I agree that Go is basically the fulfillment of the brief you gave, i.e. C with GC and easy concurrency. So, when the target is C with two unique things, why does everyone then seem confused that Go doesn't have all of these extra 'good ideas and common sense'.
I'm not trying to turn this into a thread on Go's merits or lack thereof. I just don't understand why so many people seem to think that Go somehow didn't do exactly what it set out to do. You don't have to think what they decided to design was a worthwhile language, but to expect a lion to be a shark, or an apple be a steak, is just illogical.
The reason I like and recommend Rust is the number of decisions it gets right which are completely orthogonal to the borrow checker. It's clear that a lot of thought was put into the unexciting parts of the language. That's why I like using it even though I don't particularly need the borrow checker and I'd be happy with GC. Some examples off the top of my head:
- Expression-oriented nature makes code easy to write and nice to read
- Compilation errors are as clear and helpful as possible
- Comprehensive yet skimmable API documentation
A lot of the things which strike me as nice about Rust can't be said about Go. For that reason I think Go is a surprising suggestion for someone who likes Rust but doesn't care about ownership and lifetimes.
There are a number of minor but valid frustrations I encounter when writing Go which are completely orthogonal to the brief of "C but with GC and easy concurrency". I'd understand if these problems were a result of the language's goals but often they seem to exist for no particular reason. In that regard I think Go is quite dissimilar to Rust.
I hope that explains my viewpoint more clearly :)
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.
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.
Nim is indeed going in the right direction with ORC/ARC
I think F# might fit this role.
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.
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
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.
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;
let a = Arc::new(String::from("bcd"));
let b = Arc::new(String::from("xyz"));
let c = format!("{}{}", a,b)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.
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 :)
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.