Go vs. Rust? Choose Go
matthias-endler.de
matthias-endler.de
Rust has the complexity of C++ plus additional complexity from the functional community. Plus lots of fancy template cruft.
The trouble with language extensibility is that people use it without an overall plan. The end result is a Winchester Mystery House language.[1] LISP went down this rathole, and Scheme had to be developed to get out of it. C++ went that way when nobody stopped the Boost crowd before it was too late. Now it's happening to Rust.
(Anyone involved in language design should see Václav Havel's "The Memorandum". Or at least read it; I've seen it performed, but it's not performed often.)
This is so patently false. C++ contains an order of magnitude more complexity than Rust (as one would expect for a language that continues to evolve radically 30+ years after it was designed; for better or worse, complexity is C++'s game).
Not even close. C++ has IIRC whole books just on exception handling. And it's crazy how many styles of writing C++ there really are. Exceptions or not, standard library or not, templates or not, boost or not, etc, etc. C++ templates are a language of their own. A lot of times, if your code made a particular choice, you are stuck with a set of libraries that made the same choice, or you'll be writing an insane amount of boiler place to duck tape it together. This code tends to be some of the most sucky code in existence.
Rust on the other hand feels very cohesive and there seems to be like one style of really writing it.
What parts of Rust do you find experimental? The only thing that's new (in a popular language) is the borrow checker but we can all agree that despite it's novelty, it's a huge step forward.
Another thing about Rust is the community. Just about every Rust package I've come across was very well written. Some even teach me a thing or two. E.g. I haven't seen trees implemented the way they are in this package previously https://github.com/PistonDevelopers/history_tree.
Go packages are more all over the place. Also the community seems to concentrate mostly on web stuff. The recent Vulkan tutorial by the Khronos group (i.e. the people behind the standard) used Vulkano.rs which blew my gourd. https://www.khronos.org/blog/beginners-guide-to-vulkan
> Now it's happening to Rust.
Please elaborate.
> Václav Havel's "The Memorandum"
It's crazy that you are aware of this, I always thought that his work had only a local appeal.
I've written a modicum of Go and the boiler plate was driving me crazy.
> Václav Havel's "The Memorandum"
It's crazy that you are aware of this, I always thought that his work had only a local appeal.
Saw it at Fort Mason in SF in the 1990s.
I've written a modicum of Go and the boiler plate was driving me crazy.
That's how I felt about Rust. See some code I wrote at [2], at "Return type and its error handling". Now that's boilerplate. The last time I mentioned this, it was brushed off with "Oh, you'll be able to do that with the '?' operator when it's implemented." Feel free to submit a pull request for the rewrite.
[1] https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...
[2] https://github.com/John-Nagle/rust-rssclient/blob/master/src...
Re error handling, Option's map method doesn't do the trick? Sorry on my phone and reading code is hard.
Meaning, the entire programming community hasn't quit on C++, CL, Java, etc in favor C, Scheme, Go or pick your simpler language. Most of the JS community seems very pleased with ES6 & 7 additions.
I should start a tally of the number of times that I have told you that Rust doesn't have template metaprogramming. You've been saying this for years; what have you actually written in Rust?
int x = factorial<5>::value;
and have 'x' initialized to "120" (i.e. execute computation at compile time, not just define new types). Can you do anything like that in Rust? I only read a few about Rust, but my feeling was that it has powerful generics, but NOT template metaprogramming.
When you have to get what done? Seriously. There are different reasons to pick different technology stacks, some of them because of language features, some of them because of technology stack. Getting it done at my current job is generally Java, b/c that's the tech stack used by most.
> The Go guys knew when to stop. Arguably they stopped too early...
The stuff you mention Go not having is exactly what Rust brings over Go, is it not?
> But that doesn't seem to be a big overhead item.
I disagree, it's the fundamental reason I don't use Go by choice, and instead turn to languages that allow for more expressiveness.
> Rust has the complexity of C++
You say you like Rust, but I find this statement hard to believe if you've learned the language. It has almost none of the complexity of C++. That's not to say that the language isn't more complex than Go, it is. But to say it's anywhere near C++ feels disingenuous.
The Rust RFC process is very good IMO at preventing inappropriate changes from being introduced into the language, "Winchester Mystery House language" is unnecessary FUD.
Look, you don't have to like the language. But, making statements that seem unfounded isn't really appropriate.
This is a weird euphemism for "get it done correctly". It seems to come up in any discussion about languages that help you to write correct code.
I totally subscribe to the view that advanced experimental programming constructs are neither a guaranteed way, nor the only one, to write correct code. Doesn't a language which helps you to get code done (and makes it easy to iterate on it, and has the right psychology to let you move on instead of trying yet another way to get at the old problem) help you write correct code, as well?
Lightweight formal tools like those available in Rust do guarantee that your program satisfies certain correctness properties that Go cannot.
To guarantee correctness in all aspects you need more heavyweight tools than Rust provides, but they do exist.
No, languages that let you "iterate" and don't provide any sort of formal guarantees don't help you make correct code. They help you pump out a lot of mediocre code that probably works acceptably enough to satisfy a business with a medium-low focus on correctness.
I don't do Rust (but I did some Haskell), and apart from the fact that both are very small elitist communities, some idioms are definitely evolving or changing as people try to find out what actually works in practice. So, from this practical standpoint, yes, experimental.
What's lightweight lies in the eyes of the beholder. I certainly don't think of the line noise that is Rust code in the wild (again, to an outsider) as "lightweight".
Nor do I think of the bazillions of ways you can obfuscate the simplest things in Haskell (moving 10, 20, or 90 percent of the perceived required invariants from value to type level), requiring large and possibly incompatible sets of language extensions, as lightweight. It's a burden of choice, and changing choices has huge ramifications on the rest of the code (these decisions are inherently unmodular, which is BAD).
> No, languages that let you "iterate" and don't provide any sort of formal guarantees don't help you make correct code. They help you pump out a lot of mediocre code that probably works acceptably enough to satisfy a business with a medium-low focus on correctness.
I'm sorry, but that's a very one-sided view. You can absolutely write correct code in them, and something that helps you to do it faster does help you write correct code. Simple as that.
You seem to think that there is exactly one reasonable, justified level of formal correctness. And that is the level where you stand, Rust in this case.
But that's wrong. Everything has a cost. And formalisms like Rust are still pityful attempts at constructing "formally correct" software. There might be some software that is "completely" verified, but at a cost that is simply not justifiable for the vast number of applications. Ignoring the fact that most real-world problems are ill-specified from the start.
There is more than one valid approach to do things, and more so, to do many different things. It's cool what you're doing, but there are other valid approaches to find things to do and make them work.
Get out of your little corner mate.
Yet another irrelevant, unjustified, negatively connoted description that has no basis in realty; first "experimental", now "elitist". Come on.
> What's lightweight lies in the eyes of the beholder.
In terms of formal methods that exist, both type systems simple enough for decidable inference and lifetimes are absolutely "lightweight". But sure, I guess every description is subjective.
> You seem to think that there is exactly one reasonable, justified level of formal correctness. And that is the level where you stand, Rust in this case.
This is untrue. I don't believe Rust is a paragon of correctness-oriented programming; I just think it's a hell of a lot better than something like Go. Rust at least lets you prove a sizeable chunk of practical safety and correctness properties.
> And formalisms like Rust are still pityful attempts at constructing "formally correct" software.
What Rust provides, including type and memory safety and completeness checking, gets you a surprisingly large way towards complete formal verification, imo.
> Get out of your little corner mate.
What was your goal with this statement? This is a fairly technical discussion, not a Reddit politics thread. There's no need for you to stoop to vague insults.
Not true in my perception. The things I do with conventional languages, I seldom worry about invariants that could be guaranteed by a more structural language, like null pointer safety or absence of side effects (I seldom worry about them because I seldom get them wrong).
Much more I constantly juggle invariants like "this integer is a power of two and that integer is an odd positive one. This other pointer resource is the one that correlates with the integers in that specific way."
These types of invariants are not practical to encode even in advanced type systems; I've even had a quick look and Agda and what-was-that-other-system-called, but it went quickly over my head.
> Yet another irrelevant, unjustified, negatively connoted description that has no basis in realty; first "experimental", now "elitist". Come on.
Not meant as an insult at all.
>> Get out of your little corner mate. > What was your goal with this statement? This is a fairly technical discussion, not a Reddit politics thread. There's no need for you to stoop to vague insults.
Dito. Your counter-arguments seemed to be heavily implying that there is no way way of getting code done correctly in a language that is somehow "lesser" than Rust. And furthermore you seemed to be preconceived about what others' judgement of the relevance of "correctness" is (which is a vague term - it sometimes seems to be more than "it runs correctly all the time and we could even prove it correct or actually have done so, even if not in some fancy modern type system").
So that little punchline at the end was not meant in an insulting way at all. Just to give note how your comments were perceived. Not that I really need to tell you, but it's good to admit other viewpoints / take interest how problems are typically approached in other domains.
(By the way, I took an interest in John Carmack's recent engagements with static analysis and functional programming. I, for one, LOVE Carmack not only for being undoubtedly a genius who gets shit done, but furthermore for being so undogmatic about his approaches and views. You might have followed some of it, too -- for example, https://www.gamasutra.com/view/news/169296/Indepth_Functiona... , and it's also interesting to see that in the end he backed away after having seriously considered Haskell for game programming. I'm not sure if he backed away from his (actually existing) VRScript implementation written in (untyped) Racket as well)
You can easily represent exactly these sorts of constraints in a language with something like newtype wrappers (e.g. via a wrapper over integers with an associated injective function from the newtype back to integers).
> These types of invariants are not practical to encode even in advanced type systems;
As I explained, you don't even need an advanced type system if you take the most straightforward approach. You just need a marginally powerful type system like rust's. You could probably even hack it in Go if you wanted, but it would be annoying.
However, these specific examples are also quite easy to represent in either dependent type systems (like Agda's; I'm not sure what your objection is there) or liquid type systems like that of Liquid Haskell.
> a language that is somehow "lesser" than Rust
So you're mad that I think Go is inferior to Rust? Would you like me to expand on why I think that?
> but it's good to admit other viewpoints
Unless you have good reasons for disagreeing with them, which I do. You're not obligated to agree with everyone on everything. I think you're wrong about languages with poor formal systems being acceptable for correctness-oriented programming, so I'm not going to "admit your viewpoint" just because it's polite or something.
This is not even close to reality. In the end they are integers. You will have to add/combine values with different qualities, which means at some point you need to unwrap all these layers of abstraction. The only difference it makes is that you can't recognize anymore what happens in this sea of useless wrapping and unwrapping. You constantly juggle more invariants than you can make newtypes for. Instead of simply writing "x & FOO_MASK" I will not follow some vague idea that if you wrap it in another layer of ad-hoc concept, the complexity will just magically go away and it will all just magically be "correct".
In one sentence, you can move everything to the type level if you insist, but at some point you have to DO it. The complexity does not go away, all you can hope to do is implement a given artifact only a single time. (And plain procedures are pretty good at that for >90% of what I do). Most things are done exactly once in a code base, so moving them to the type level is just a crazy bad idea.
>> a language that is somehow "lesser" than Rust
> So you're mad that I think Go is inferior to Rust? Would you like me to expand on why I think that?
I'm not mad at all. In fact I've never done Go either; I do most of my work in C and Python and sh (and some coding competition style things in C++11 if I need the quick container). I'm perfectly happy with the expressiveness they provide.
Actually I did read your blog post and regarding missing generics I even agree somewhat. But what I think you're missing is that it's not the biggest deal under the sun. I actually like to throw a few void pointers around in C, and it has considerable advantages, for example being highly modular (does not enforce any dependency hell crap, compiles quickly...).
I don't care about NULL-pointer safety. It's one of the least problems I encounter.
I don't care about formalized error handling. In many simple applications you simply die right away, and for many more complex and long lived ones, explicit error handling is the right choice and leads to a consistent code base, and does not force me to second-guess what conditions are "errors" and what not. Frankly error handling in Haskell is a huge mess.
I don't care much about operator overloading either. It wouldn't have been helpful in more than a handful of situations for me, so far. Instead of implementing extra syntactic sugar it's no big deal to simply call the relevant function three or five times. Again, that approach has advantages as well, for example I can easily search the locations where these functions are called. Also I can be sure that '+' means really an add instruction on the CPU.
And as I said I sometimes use std::map<K, V> et. al as well, but actually it's often only an interim solution until I realize I don't need that at all, because a V* would do, or I need an intrinsically linked map instead (which can't really be made as a template class, the only alternative being allocating the V's separately and making std::map<K, V* > instead), or I absolutely die suffering the compile times due to the added dependencies, or I can't bear the allocation overhead.
> Unless you have good reasons for disagreeing with them, which I do. You're not obligated to agree with everyone on everything. I think you're wrong about languages with poor formal systems being acceptable for correctness-oriented programming, so I'm not going to "admit your viewpoint" just because it's polite or something.
That's exactly the point: nobody pulled the correctness-first card. No, you can't disagree that people are productive and stuff EXISTS and works to a large extent, and advanced type systems are niche. I used to play CS:S for example and can't recall having any problems. I'm a heavy Linux user and the kernel is seriously rock solid, with the exception of a few reverse-engineered device drivers.
Not saying that there are not many buggy projects as well. Most of those are financially terribly undersupported.
Also not saying people are not looking for improvements to their methodologies, but you need to acknowledge the methods with which people get their work done, and that correctness-first approaches have largely not worked out so far. I'm not aware of any serious kernels or performant 3D Games written in Haskell. In fact, one of the highest-profile Haskell applications, GHC, does indeed have quite a few bugs, and this is because the type system simply can't encode all THAT many invariants, especially if you need to get something done in the end. (Besides that it's god awful slow sometimes, although I'm in no position to judge whether the implementation language is the reason, or the type system extensions are just not practical from a performance standpoint).
If you can make a little Tetris game in 3h in Haskell (or even Rust), I will tip my hat to you. Tried to do that but eventually gave up due to unsufferable compile times and terrible non-essential complexity due to opionionated framework (and I do have a basic understand how Haskell works, and I went with the most basic dependencies possible). But I did make a working Javascript+CSS Tetris in <3h and I don't think my C version with SDL (no fonts) took much longer.
You seem to be saying "it's hard to verify everything, so we shouldn't even attempt to verify anything," which is silly. I've found having memory safety to be a huge win, even if the Rust compiler can't verify that my program is doing the right thing.
Okay ... so is Python, Ruby, Perl, ... and they will beat Go by a mile on quickly constructing small programs.
Even if it must be fast, there's still C#, Java and quite a few others.
I don't feel that C++ is complex at all. It just has more crap and every programming language has crappy parts.
Or Java? I mean, I've never seen any reason to use Go over existing, better languages.
Never thought I'd call Java better than anything, but there you go.
No need to get into specifics. I think I understand your point and I must admit I am inclined to share your feelings about it too. Hopefully soon Nim's concepts will become stable enough to be used in such places too.
No, Go isn't a systems programming language because it has a GC.
This matters in constrained environments, like when doing embedded development, or for real time systems.
Sorry, but Go isn't in the same category as Rust or C/C++.
Go is in the category of Java and C#. And IMO its only advantage is that it can produce lighter binaries.
And while Java and .NET are evolved towards building lighter binaries, you can't evolve a GC-ed language towards one without a GC.
> Go is not even a systems programming language.
I would personally not assimilate system programming to embedded.
Java is running on so many smart cards, TV and set top box nowadays. It's almost everywhere.
Go is for distributed SERVERS.
Its niche is more in boring servers and command-line apps where an interpreted language would be too slow, too memory hungry or harder to ship, where you can get away with only the simplest concurrency, but still prepared to deal with time-consuming concurrency bugs. Like a typical commercial CRUD app, a command line automation and data processing utility, a quick one-off program.
Any server app where python/perl/ruby are too slow, and you can't use java/C#/C++ for some reasons.
I don't think a GC excludes a programming language from being considered a "systems programming language".
(JavaChips were interesting, thought iirc it only ran a certain subset of Java?)
At that point you'd better off using C or C++ directly. Go gives you absolutely no advantage, only costly abstractions.
advantages of writing the Go runtime in Go might include, just spitballing here, avoiding ffi cost for runtime calls, enabling better optimizations around/into runtime calls, simplifying the build process, or even just enabling Go enthusiasts to contribute to the runtime without learning C. talking about actual language features, i think I'd almost be tempted over just by Go having a module system, but there's probaby a few other subjective ergonomic benefits that you can use without falling into the GC requirement. I'm not sure what exactly decided it for them, maybe i should look that up.
there's probably gonna be some OS-level non-Go shims written in either C or assembly or the weird Go way to write assembly but i feel that's fair as C-written runtimes probably need to have at least some inline asm somewhere as well.
High-level blog post: http://dylanmckay.io/blog/rust/avr/llvm/2017/02/09/safer-mic...
Tracking bug on GitHub: https://github.com/rust-lang/rust/issues/42450
From the article:
> 99% of the time, Go is "good enough" and that 1% where it isn't, you'll know. And then take a look at Rust, because the two languages complement each other pretty well.
The various variants -- Oberon OS, Active Oberon, Bluebottle OS, A2, EthOS [2] -- were entirely written in Oberon (plus assembly), with GC at the OS level and I believe in some (all?) cases even in the kernel.
Oberon had a huge influence on Go, as did Wirth's other languages. Robert Griesemer worked at ETH Zürich (where all of this was conceived) for a while.
Then there's Singarity [3].
[1] https://en.m.wikipedia.org/wiki/Bluebottle_OS?wprov=sfti1
[2] http://www.progtools.org/article.php?name=oberon§ion=com...
[3] http://en.wikipedia.org/wiki/Singularity_(operating_system)
That's basically what I got from this article.
There's a reason why the lion's share of code written today is Java or C++ and Rust compares much more favorably on the more "enterprisey" merits (stability, expandablility, performance) than the startup merits (how fast can we ship).
Its funny to compare Rust, whose sole purpose was to enable garbage collector free semantics, designed to reimplement an efficient and small memory web browser to languages with a GC.
Go is great, because compared to most other GC languages, it has small self contained binaries and comes with a great toolchain. Its AOT is better then C# and Java, and bundles its runtime with every app. It's not great, because people would really just want a more expressive language that had those same qualities. That's why there's effort for Kotlin native and Scala native.
If anything, the fact that some people are thinking to pick Rust over Go is a testament to Rust. Rust should have nothing of interest over Go, except for no GC. But apparently, even with the added complexity of a borrow checker, it has enough to entice people from GC languages.
Similarly with Go and Rust, as I'm following Rust development since like 0.3, I am very productive with Rust, while I find Go noisy, verbose and constantly dragging me down with its limitations. I don't have to be "architect astronaut" to need generics or decent macros.
On top of that: how do you measure productivity? Many people seem to measure it by "perceived productivity when writing new code". "I am writing this new service in Go, and I was able to do 500 lines today. I feel very productive!" Never mind that 30% of that lines are verbose error checks and other error-prone boiler-plate, reviewing it might not be pleasant, there are multiple errors that will have to be ironed out when production starts to exhibit them, everything needs refactoring because performance is not good enough under load, and that the next person might not have a such a wonderful time modifying the original code, as the first person writing it, and so on. The project might be in such a bad shape, then it will just get rewritten from scratch, so the next developer will feel "productive" again, ironically. I am NOT addressing Go and Rust particularly here - just overall. It is very hard to measure long-term productivity, while it is easy to lure yourself into believing the perceived short-term productivity matters a lot.
Having said all that, Go is easy to understand, so it is easy to find people that are able to use it (huge business reason to prefer it!), has a nice ecosystem, fast compilation, nice scalability with goroutines and many things that are going for it.
I find Rust's "quality", trump Go's "productivity", but that's like ... my personal opinion, man. :)
Having said that, since Rust 1.0 was released, I'm not planning to use any other language unless paid for it. My favorite part of Rust is that it might not be the best tool for a particular job, but is reasonably close for anything I might throw at it: embedded, system tools, networking, web, whatever. Since I'm a generalist, I enjoy having a reliable multi-tool.
It's enterprise-ready. Seriously.
Hate the syntax? Wait a little bit and try out ReasonML (new syntax for OCaml), e.g. the following OCaml
channel
|> Channel.push "new_msg" [%obj { body = "a" }] ~timeoutMs:10_000.0
|> Push.receive "ok" (Js.log2 "Created message")
channel
|> Channel.push("new_msg", { "body": "a" }, timeoutMs::10_000.0)
|> Push.receive("ok", Js.log2("Created message"));You can get all the type safety benefits of OCaml right now, on NodeJS.
Yup. Opam (package manager) + Merlin (editor integration, type hints, error messages) + VSCode are a killer combo. And if you use ReasonML you also get refmt, which is the equivalent of gofmt.
> ecosystem?
Yup. The opam ecosystem is high-quality, growing, and has all the essentials. If you need something out of the ordinary you can call out to C libraries, or even compile to JavaScript and use (almost) the entire npm ecosystem with BuckleScript.
> is there even another stl than jane street's library?
That's odd. Usually people criticise OCaml for having more than one stdlib. But yes, there's a minimal but useful stdlib that ships with the OCaml compiler: https://caml.inria.fr/pub/docs/manual-ocaml/libref/index.htm... . And there's also the community-driven Batteries library: http://batteries.forge.ocamlcore.org/
The author of pgloader[1] said the other day "When I told people I was going to use Lisp, I was told it was stupid because there weren't any libraries; when I packaged it for Debian, I was told that I had too many external dependencies"
It was probably different groups, but there were complaints both about not enough and too many libraries!
Portability libraries[1]6: bordeaux-threads, CFFI, command-line-arguments, trivial-utf-8, trivial-backtrace, usocket
Parsing 6: abnf, esrap, markdown, py-configparser, simple-date, quri
Database interfacing 5: csv, db3, postmodern, qmynd, sqlite
Build-tool/dependency management 3: asdf, asdf-finalizers, asdf-system-connections
utilities 3: alexandria, split-sequence, utilities
portable I/O & character encoding 3: unicode, fad, flexi-streams
sugaring 2: metabang-bind, interpol
Other 6: drakma(HTTP), log, lparallel, md5, ppcre(regex), uuid
abnf: parser generater for augmented BNF
alexandria: utility library
asdf-*: build-tool
bordeaux-threads: mutithreading primitives
cffi: foreign function (i.e. calling C)
command-line-arguments: exactly what it says on the tin
csv: comma separated variables (also supports similar things like tsv)
db3: dBASE III reader
drakma: http client
esrap: Parser generator
fad: Files And Directories (portable file-system)
flexi-streams: in-memory streams (file-like objects) and encoding
interpol: interpolated strings (e.g. variable substitution in strings). Also includes regex literals.
local-time: timestamps &c.
log: logging
lparallel: high-level threading
markdown: markdown
md5: md5
metabang-bind: macro library for doing various fancy bindings (setting a variable to a value for a particular lexical or dynamic scope) in a single construct.
postmodern: Postgresql interface library
ppcre: perl compatible regex
py-configparser: parser for .ini like files (compatible with the python "configparser" library)
qmynd: MySQL library
quri: fast URI parsing/emitting library ("quicker" than puri, the Portable URI parsing library)
simple-date: date/time; not sure what it offers that local-time doesn't
split-sequence: Splits sequences based upon value or function of value
sqlite: sqlite3 interfacing
trivial-backtrace: tool for getting backtraces
trivial-utf-8: Portability for UTF-8
unicode: things like character classes for Unicode
usocket: socket library
utilities: utilities library
uuid: UUID library
1: wraps commonly available, but not standardized behavior in lisp implementations: sockets, threads, debugger &c. often named "trivial-"
On the other hand, in a weekend of casual hacking, I was able to learn the language (sort of) and make a project from scratch in Go that actually did something useful. I'm sure the code is awful, and it'll take months of weekends of casual hacking to be able to recognize why, but Go is damned near comparable to Python or Ruby in terms of being able to go from zero to writing working code.
I'll still keep learning a little rust here and there when I have some free time. I'd really like to know a good, modern, systems language. I used to work on some C projects, but C++ was just too daunting, it's just to big of a language for casual use, so I never went down that path. Rust seems to be a good compromise.
It's not even a "Go is better than Rust" situation; the Rust team has made reasonable, occasionally brilliant, compromises on ease-of-use and ease-of-learning vs their other hard requirements. Go just has different requirements and they result in a language that is easier for new programmers.
Much more time is spent maintaining software than writing the first version. Some poor sob is going to have to go and fix all those "silly" mistakes that were made and the bugs they caused (but of course, as we all know, they would have been avoided if the programmer had just been a better programmer). Save yourself (and us) the bother. Please use languages that stop you from shooting yourself in the foot.
(Not that rust will avoid bugs, but it seems to catch a lot of stupid "mistakes" before compile time. We're all humans and make mistakes, please accept that fact before inflicting software on us.)
In my experience, project managers care more about how long it's going to take to build than about how maintainable it is. It's literally always the first question they ask:
"How long do you think this will take you?"
I don't believe I've ever heard anyone in management ask, "How maintainable will this be?" I'll ask around. I bet none of my peers have gotten that question either.
Are they competing for the same user base? As far as I can understand, Go is mostly being used in distributed software systems (like kubernetes) while Rust is being used for more "systems" software where performance is critical (like a web browser).
If you like artistically crafting small bits of code, Python may work fine. If you're building something to last and need to shovel large amounts of code around while migrating API's, a statically typed language with a fast compiler will do more to help.
Python in the large is not very maintainable. I expect that a Rust codebase will eventually be pretty nice to maintain, after the tooling matures more. Currently, Go is probably easier, and quicker to write.
Could you elaborate on that?
I hear this a lot, but I work on a large Python project, and I don't think it is hard to maintain. We do have some strict requirements, though:
1. Test coverage; if it's testable there must be tests for it
2. Type hinting; for large projects it's actually really nice to know at a glance what the expected type is
3. PEP8 & Pylint; how we write code should be standardized and easy for others to read
Here's the sort of scale I'm thinking of: consider a company with many teams, many apps, and many shared libraries. Some of the apps and libraries won't have anyone working on them, because it's generally not the case that a company is willing to fund maintenance forever on everything; people need to drop them for a while (to work on more important stuff) and someone else will come back to them later. (This is being "walk-away friendly".)
Suppose you need to fix a security bug in a shared library and update all the apps, most of which you haven't seen before. How easy is that to do?
Yes, very much it is. It just need good developers, not only juniors...
Open to suggestions for projects to take inspirations from so that my future Go code will not be "quickly written AND it works AND it looks horrible" :)
Maybe Go isn't so simply the answer, but the spread of "write everything in Rust" or "Rust is the salvation of software" is crazy. It's got huge advantages but it's really a very difficult language for what it does. 80% of software (nonsense percentage) that gets targeted to Rust would actually be better in another language. Rust's focus is on (for most devs and software) the wrong things.
It's too bad something like a better OCaml or Nim weren't what people were going nuts rewriting stuff in but they don't have the mindshare. Rust evangelism is like using a very advanced hammer to do everything. We've got screwdrivers, chisels, and multitools, yall, use them! Is Rust actually the right tool for the job? As programmers we do tend to seek the one true language which doesn't really exist.
Rust is a big sidestep in usability, which makes sense if you want to replace C and C++, but not much sense elsewhere. Humans are really, really good at juggling multile languages, it's why we make a new one whenever we can.
There are applications where a garbage collector is simply unnecessary and possibly extremely detrimental.
And if you get down to it you'll find an amazing truth: once you learn how writing programs is about as easy without a garbage collector than it is with one and your programs run a lot faster.
Using an automatic transmission is a lot easier but manual is not hard and you save a lot of gas.
So, the reason to use one of these languages is to get away from the "you can use a GC"-space and then the count of interesting languages gets very small very fast.
But sure, if your problem is in the "GC can be used" space, but you like to use new languages .. go for it. It's certainly fun to use a new language to tackle a problem. Just not the most efficient use of someones time in my experience. (But: Fun!)
Unless you have a language with immutable data structures, ownership is still a problem with a GC.
E.g. Consider the case where you have some class with some member variable. You want to provide a getter to obtain the member. Now you have an ownership problem: you could return a reference, but now the caller could mutate the data structure in such a way that it breaks invariants of the wrapping class. So, instead you return a copy, but this can be prohibitively expensive.
Omg, what are gRPC, avro, thrift, and cap'n proto meant to do?
I bet if we could all just agree to pick one of those then the interoperability problem will be solved. I know you were referring to C ABI etc, but as others have pointed out, having two GC languages communicating with each other over a C ABI is tough, which is why IPC/RPC exist.
Oh, and once we settle this single ABI/Interoperability problem, let's come back to this one-true-language idea... I think there's something there ;)
If you only need an spa use react or bue. If you only need a website use php or ruby. If you only need a webservice use node or go. If you only need an operating system use rust or c.
Using rust for client side validation is probably not going to work.
Back in the 90s, people were thinking Java would be The One. Didn't happen. Good luck with convincing everyone that it should be Rust and not their preferred language.
More fundamentally Rust is poorly suited to programs that don't have a hierarchical ownership model. UI programming is a good example. UI elements tend to have lots of cross-references to each other: think event handlers, etc.
Of course Rust can support non-hierarchical ownership, but only by applying constraints that don't make sense in UI programming. Imagine if JavaScript's `getElementById()` threw exceptions if the referenced element was already on the stack. That would be silly! In this context, Rust's borrow checking is not a seatbelt but a footgun.
In theory this is problematic, but I'm not sure how often it comes up in practice: a lot of systems-y use cases for dynamic linking are writing low-level libraries that many other languages can use, which currently means exposing a C interface. This is supported and stable in Rust.
Of course, this doesn't cover every thing, e.g. pure Rust plugins for pure Rust programs. Although one still can dynamically link, as long as all pieces are compiled with the same version (annoying, but, depending on circumstances, not a complete roadblock due to tooling like rustup).
> Imagine if JavaScript's `getElementById()` threw exceptions if the referenced element was already on the stack
I'm sure you realise it, but Rust does offer a wide variety of functionality for working with shared data. It is definitely syntactically more verbose than in languages that don't try to tame mutation, but it's essentially equivalent functionality (at least, to languages that use reference counting).
UIKit is an example of a high-level dynamically linked library. Rust isn't ready for that category of use case - but to be fair neither is C++ :)
> Rust does offer a wide variety of functionality for working with shared data. It is definitely syntactically more verbose than in languages that don't try to tame mutation, but it's essentially equivalent functionality
My point regarding shared data is not about Rust's verbose syntax, but about its unwanted runtime checks which no other languages perform.
Here's what I have in mind (doing my best pseudo-Rust):
struct CounterWidget {
count: u32,
limit: u32,
didClick: fn(),
};
impl CounterWidget {
fn clicked(&mut self) {
if self.count < self.limit {
self.count+=1;
didClick();
}
}
fn setLimit(&mut self, limit:u32) {
self.limit = limit;
}
}
This crash is hard to test for and doesn't add any value: why shouldn't the callback be able to adjust its limit?
You must mean that you stored your `CounterWidget` in a RefCell, which does have the semantics that if you mutate it while holding a mutable reference to it, it will crash. But your code sample didn't include a RefCell at all, so this is very unclear.
Yes, its true - Rust provides a hard guarantee against simultaneous mutable access to the same data. This is invaluable even in a non-concurrent context, both because of memory issues like iterator invalidation & higher level logic errors that result from silent mutation at a distance.
I can assume looking at your code that didClick() doesn't mutate this CounterWidget - or even access it. This means I know that if I rearrange the counter increment with the didClick callback, I know nothing is semantically different. I can introduce additional code to the function, knowing that the state is the same after didClick as before it. All of this information is very useful to me when I'm trying to maintain this codebase (not to mention useful to the optimizer).
If you want to be able to provide mutable access to the callback, just make it an `fn(&mut CounterWidget)`.
That's fair.
> My point regarding shared data is not about Rust's verbose syntax, but about its unwanted runtime checks which no other languages perform.
FWIW, I think Swift is the only language with implicit checks of this form (for global variables and class properties). Rust only performs such checks if the programmer opts into it by using types like RefCell or Mutex.
> It also has a landmine: if the click callback attempts to call setLimit on the same Counter, it will crash at runtime.
Specifically, the callback will be statically unable to call setLimit unless the programmer decides to use one of those tools, in which case the location of the crash is clear.
> This crash is hard to test for and doesn't add any value: why shouldn't the callback be able to adjust its limit?
That specific case seems like it's okay, but there's a pile of problems in code that is only slightly different. For instance,
- if `clicked` held a reference to an element of a vector stored inside CounterWidget across the callback call, allowing mutation would allow that reference to be invalidated (this is less contrived than it sounds: e.g. iterating through a vector calling the callback for each element has this problem). This is undefined behaviour.
- if the callback enables results in the data being manipulated on multiple threads, you get a data race. (Also undefined behaviour.)
- stepping away from undefined behaviour, there may be things inside the `if` statement after the callback that are relying on the invariant the condition established (e.g. `let remaining = self.limit - self.count` and assuming it will be > 0), the callback can invalidate this in surprising ways, both for the programmer, who didn't expect the circular chain, and for the compiler's, which is thus forced to be defensive/pessimistic, meaning slower code (this is one major reason why Swift adopted exclusivity).
Sorry to burn down your straw man, but the overwhelming majority of "Rust evangelism" points out that Rust is not always the right tool for the job. The intersection between people who write both Rust and Go (for instance) is substantial, and people in the Rust community (more precisely: communities) go to great lengths to point out that it's not an either / or proposition. Most of the RIIR! hyperbole is something that happens to the Rust community, not on its behalf.
> As programmers we do tend to seek the one true language which doesn't really exist.
This seems somewhat at odds with your denunciation, mere sentences ago.
stevekalabnik and pcwalton show up in every Rust discussion for a reason (no knock on them), the Rust evangelism strike force meme is real, for a reason, this post called "Rust is Software's Salvation" got 172 upvotes and 176 comments for a reason:
https://news.ycombinator.com/item?id=13280150
The marketing is real, nuance is good.
I pointed out that there were multiple communities before you did.
> stevekalabnik and pcwalton show up in every Rust discussion for a reason
I agree completely; their calm, constructive engagement with the HN community has been a tremendous help to Rust's adoption.
The meme is more real than the strike force itself. For every once I've seen it appear I've hundred times seen that tired meme appear.
From that POV Go wins hands down in my opinion. Harder to get wrong. Easier to get right.
Even though Google/Fuchsia is using Go for it's networking[1], I wouldn't really consider Go to be a system language.
[1] https://groups.google.com/forum/#!topic/golang-dev/2xuYHcP0F...
This post just about sums up my feelings on Go vs Rust.
I see a lot of people considering Rust/Go because they are looking for something much more modern than C++ and at the same time not running on JVM due to the above
But I am probably not typical. I'd no problems learning a language I'm interested in (but Haskell. Monad pattern recognizer somehow can't take a hold in my head for long).
Ok, yeah, that's totz the way forward. Repost this if you are strong independent developer who doesn't need no good engineering practices.
...yadayadayada...
If you don't require any of these features, Rust might be a poor choice for your next project. That's because these guarantees come with a cost: ramp-up time. You'll need to unlearn bad habits and learn new concepts. Chances are, you will fight with the borrow checker a lot when you start out."
If you don't require...seriously is there any case ever in the world of programming when you don't require those?
I can't even believe this article exists. Why would anyone ever use Go for anything? It's the worst programming language ever invented. Yeah Im sure it makes things fast just like jumping down from rooftop makes you go fast but there is small side effect of dying.