7 ms·
There's a statement that Rust is a systems programming language, but that in most cases one doesn't need this, and that Go or Kotlin are thus in most cases bett
by srer 5y ago
There's a statement that Rust is a systems programming language, but that in most cases one doesn't need this, and that Go or Kotlin are thus in most cases better alternatives.
This image of Rust as lower level than Go isn't one I agree with, but I can certainly see how people end up there. Go has it's garbage collector and userspace threading model, one gives up a lot of control to a runtime that you don't have to in Rust.
But as the author mentions if we're after good enough speed these details aren't important. So I don't most of the time care if there's a GC or not.
What I care about is the code I have to write, and Rust IMHO offers me nicer abstractions and more features.
The Go world in their desire for simplicity, use a for loop for everything, but in Rust we have the excellent iterator trait. The Go world offers me product types, the Rust world offers product and sum types. The Go world offers some mechanisms for codegen, but it is a far cry from Rust's macros.
Go I consider a modernized C, that is notable more for what you can't do than what you can, and how fast it can be learned - owing to a minimal and already familiar feature set.
I confess that I have a bit of a chip on my shoulder, I have for the last few years been working as a Go developer and in the last few months it's started really started to grate me how much work things are. I really miss things like '#[derive(...)]'.
- moldavi 5y agoThe author could have recommended Scala, which has all of Rust's type system benefits, plus garbage collection (and of course, minus the low level control over performance). YMMV though, as everyone uses Scala differently. A lot of Scala code goes in a more abstract direction, but if you use it in a more imperative Kotlin-esque way it's a very nice language.
- ncmncm 5y agoGo, like Java, was designed by people who intended never to write any code in the language, themselves. Both are languages which those individuals designed for use by people less intelligent, careful, and thoughtful than themselves. The case of Java demonstrates they were mistaken: their estimation of their own understanding was grossly outsized. I don't know enough about Go to say whether that is true of Go's designers.
- aredplug 5y agoEven if that were true, is it a bad thing?
- Skunkleton 5y agoGo itself is a huge project written in Go. What are you talking about?
- lucian1900 5y agoFamously, it even took many years for the compiler to be bootstrapped. That’s unusual in the extreme.
- tmp538394722 5y ago> Unusual in the extreme The most popular python and ruby implementations are written in C, right? Swift is written in C++ It seems not sooooo unusual.
- jacquesm 5y agoPython and Ruby are not from the get-go compiled languages but interpreted ones.
- atrn 5y agoThey had a functioning compiler and decided to concentrate on other areas and it's not too uncommon for a languages's compiler to NOT be written in that language. Afterall Rust relies on the non-Rust LLVM.
- adgjlsfhk1 5y agoOne thing that has been discovered over the past 50 years and applied over the last 30 or so is that writing a bootstrapping compiler for a young language tends to strongly bias the language towards being good at writing compilers (potentially to the detriment of other features). Compilers are essentially graph algorithms on loosely typed data. I think a lot of the reason it took so long for Rust and Julia to be invented is that they are both not very good languages for writing a compiler in, so in the era where all the new languages had bootstrapping compilers, no one would write a language with the sets of tradeoffs they have.
- Zababa 5y agoI only partially agree with you. The examples you gave are solid, but there's a big elephant in the room: async programming. In Go async is transparent, in Rust async tends to be a huge pain. Preemptive multitasking really makes everything easier, and I would take it over Rust's type system and abstractions. I'm personally patiently waiting for OCaml multicore, which should have the best from both worlds, except the large communities.
- johnnycerberus 5y agoI think the JVM would also be a good choice once Loom lands. I've seen that right now the Java architects are trying to unify the ALGOL flavored Java with ML in the sense of algebraic data structures, pattern matching, local type inference. As you said, OCaml does not have a big community, library ecosystem. It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me.
- Zababa 5y agoThat's a good option too, though in that case the tradeoff is that compiling to a single binary is a bit harder than in the other languages. Someone mentionned Scala too, which is even "higher level" than OCaml, but I think Scala has the issue of future/async (monadic) concurrency, and is even harder to compile to native. There are lots of options in that space, which is great! > It also does not have the 100B$ garbage collectors of the JVM, which are a deal breaker, at least for me. Can you expand a bit on that? I was under the impression that even with all that investment, Java code tends to be slower and more memory hungry than equivalent Go code.
- astrange 5y agoNo amount of $ spent on JITs and garbage collection can solve the problem that Java was designed with no respect for memory use. It just doesn’t have the features (such as but not limited to value types) that let you save memory. They’re adding value types of course, but I haven’t looked at how exactly they’ll work.
- ComputerGuru 5y agoYes, personally I think C#/.NET is a much better complement to rust than golang is, but it’s just not as hip a langauge.
- pjmlp 5y agoExcept in that ecosystem Rust is no match for C++/CLI and C++/WinRT tooling. Yes they are Windows only, but lets be honest most pure .NET shops aren't moving away from Windows, as .NET cross platform has left part of the commercial ecosystem behind and no one is willing to port those stacks into cross platform ones.
- nine_k 5y agoI'd say that Go is mostly taking the place of PHP4 of old. Go is much less ceremony than C, thanks to built-in data structures and GC. If you want something to be built quickly, using only the simplest expressive means, and with very little ceremony around coding and deployment, Go is a clear choice. Much copy-pasting needed? Screw it, we have to ship tonight, and we will. Rust is a clear replacement of C++, but with the flavor of OCaml and even Haskell added to it. It requires thoughtful planning, a good grasp of what you are building, how it should work, down to the lower levels, and significant knowledge of the CS fundamentals. Relatively few parts of the industry appreciate such an approach, but where it's needed and productive (see e.g. control software, system-level software, well, web browsers) it shines, and has no serious competition. Possibly architectural progress in libraries will one day make writing web services in Rust ergonomic enough to compete with Typescript, much like auto-ptr / unique-ptr made writing C++ less painful.
- pjmlp 5y agoMost of those domains have security standards, even when using Ada/SPARK or formal methods, so Rust still needs some work to get there.