Earlier quoted context omitted.
Nah, learning Rust is trivial. I've done it 3 or 4 times now.
In how many lifetimes?
‘static
Thoughts on Go vs. Rust vs. Zig
481–490 of 599 posts
Re: Thoughts on Go vs. Rust vs. Zig
#482Earlier quoted context omitted.
> But you only need about 5% of the concepts in that comment to be productive in Rust. The similar argument against C++ is applicable here: another programmer may be using 10% (or a different 5%) of the concepts. You will have to learn that fraction when working with him/her. This may also happen when you read the source code of some random projects. C programmers seldom have this problem. Complexity matters.
No, this is overly simplistic. The features in the quoted comment are largely things that nobody other than stdlib developers need to understand. There is no bespoke subset-dialect of Rust where people are tossing around the `fundamental` attribute--it is strictly an obscure detail that not even an expert Rust programmer would be expected to have even heard of.
The main issue with "fundamental" is that it's currently unstable, but a stable version of it could definitely be useful for lessening the "orphan rule" constraints on implementing traits. Probably would want a different name such as #[deorphan] though.
Re: Thoughts on Go vs. Rust vs. Zig
#483Re: Thoughts on Go vs. Rust vs. Zig
#484Earlier quoted context omitted.
so does the rust compiler check for race conditions between threads at compile time? if so then i can see the allure of rust over c, some of those sync issues are devilish. and what about situations where you might have two variables closely related that need to be locked as a pair whenever accessed.
No, it does not. Rust approach to shared memory is in-place mutation guarded by locks. This approach is old and well-know, and has known problems: deadlocks, lock contention, etc. Rust specifically encourages coarse-granular locks by design, so lock contention problem is very pressing. There are other approaches to shared memory, like ML-style mutable pointers to immutable data (perfected in Clojure) and actors. Rust…
> There are other approaches to shared memory, like ML-style mutable pointers to immutable data (perfected in Clojure) and actors. Rust has nothing to do with them, and as far as I understand the core choices made by the language make implementing them very problematic.
Would you mind elaborating on this? At least off the top of my head a mut Arc seems like it should suffice for a mutable pointer to immutable data, and it's not obvious to me what about actors makes implementing them in Rust very problematic.
Re: Thoughts on Go vs. Rust vs. Zig
#485Earlier quoted context omitted.
Also Haskell, Java, Kotlin, Scala, OCaml, D, and the list goes on.
Out of all those only Java and Kotlin captured significant market like OP mentioned
Those two aren’t natively compiled. They can be, but it’s not the norm, and it’s hard/time consuming.
Java’s type system isn’t as strong as it could be either. It is still lacking proper compile time support for null and there’s been no investment in making error handling better. I’ve written it every day for 10 years and the type system definitely doesn’t help you write correct programs.
Re: Thoughts on Go vs. Rust vs. Zig
#486Earlier quoted context omitted.
Me too. There’s a huge market for a natively compiled language with GC that has a better type system than Go. The options I’ve seen so far are: OCaml, D, Swift, Nim, Crystal, but none of them have seen to be able to capture a significant market.
C#?
Is not natively compiled.
Re: Thoughts on Go vs. Rust vs. Zig
#487Earlier quoted context omitted.
> But you only need about 5% of the concepts in that comment to be productive in Rust. The similar argument against C++ is applicable here: another programmer may be using 10% (or a different 5%) of the concepts. You will have to learn that fraction when working with him/her. This may also happen when you read the source code of some random projects. C programmers seldom have this problem. Complexity matters.
There's also the problem of the people who are either too clever for their own good, or not nearly as clever as they think they are. Either group can produce horribly convoluted code to perform relatively simple tasks, and it's irritating as hell everytime I run into it. That's not unique to Rust of course, but the more tools you give to them the bigger mess they make.
And this is amplified by LLMs.
Before LLMs, only the author had a firm grasp of how their convoluted solution works.
Now sometimes not even the author knows wtf is going on among thousands of added lines of code.
Re: Thoughts on Go vs. Rust vs. Zig
#488Earlier quoted context omitted.
Lately rust is my primary language, and I couldn't agree more with this. I've taken to using typescript for prototyping - since its fast (enough), and its trivial to run both on the server (via bun) or in a browser. The type system is similar enough to rust that swapping back and forth is pretty easy. And there's a great package ecosystem. I'll get something working, iterate on the design, maybe go through a few rewr…
I'm in a similar place, but my stack is Python->Go With Python I can easily iterate on solutions, observe them as they change, use the REPL to debug things and in general just write bad code just to get it working. I do try to add type annotations etc and not go full "yolo Javascript everything is an object" -style :) But in the end running Python code on someone else's computer is a pain in the ass, so when I'm done…
I'm in the camp of "If your target is Go, then prototype in Go." I don't bother with the intermediate step. Go is already so very close to being a dynamic language that I don't get the point. Just write "bad" Go to prototype quickly. Skip the error checks. Panic for fun. Write long functions. Make giant structs. Don't worry about memory.
You mentioned running someone else's python is painful, and it most certainly is. No other language have I dealt with more of the "Well, it works on my machine" excuse, after being passed done the world's worst code from a "data scientist". Then the "well, use virtual environments"... Oh, you didn't provide that. What version are you using? What libraries did you manually copy into your project? I abhor the language/runtime. Since most of us don't work in isolation, I find the intermediate prototype in another language for Go a waste of time and resources.
Now... I do support an argument for "we prototype in X because we do not run X in production". That means that prototype code will not be part of our releases. Let someone iterate quickly in a sandbox, but they can't copy/paste that stuff into the main product.
Just a stupid rant. Sorry. I'm unemployed. Career is dead. So, I shouldn't even hit "reply"... but I will.
Re: Thoughts on Go vs. Rust vs. Zig
#489Earlier quoted context omitted.
Chill with being condescending if you want a discussion. The error type in go is literally just a string type error interface { Error() string } That's the whole thing. So i dont know what your talking about then. The wrapped error is a list of error types. Which all include a string for display. Displaying an error is how you get that information to the user. If you implement your own error, and check it with some r…
> The error type in go is literally just a string No, like I said before, it's literally an interface. Hell, your next line even proves it. If it were a string, it would be defined as: type error string But as you've pointed out yourself, that's not its definition at all. > So i dont know what your talking about then. I guess that's what happens when you don't even have a basic understanding of programming. Errors ar…
This guy can't help his self except to act like an ass
Re: Thoughts on Go vs. Rust vs. Zig
#490Earlier quoted context omitted.
> The error type in go is literally just a string No, like I said before, it's literally an interface. Hell, your next line even proves it. If it were a string, it would be defined as: type error string But as you've pointed out yourself, that's not its definition at all. > So i dont know what your talking about then. I guess that's what happens when you don't even have a basic understanding of programming. Errors ar…
This guy can't help his self except to act like an ass
It is always curious when a comment on the internet is anthropomorphized. Where is the logic found in that?