So, after a night of sleep, I just realized there is a very important point I didn't make in the post. I'll update it as soon as I managed to get out of bed. ;P

Done. There is a new point about why Rust and not Go, which I do believe is the central point of this whole discussion.

@juliobiason maybe you should make it a fediverse recruitment drive by putting in the footer that in lieu of blog comments people can respond here?

@bkhl Good point. I need to update some things and I'll add that at the bottom of the post.

@juliobiason I lost all respect for Go when I realised it codifies things like broken opt parsing and its designer's personal preferences source code repo directory layouts.

It's great when a language has opinions but in Go's case they are all terrible ones.

@juliobiason As an exercise, I wrote the same code in Rust and Go. It's a simple computation function but with the constraint that the code can be called from C/C++ (from dlopen).
The Go version looks like a dirty hack compared to the Rust version (Go uses comments for compiler directives, and it requires the declaration of a useless main function).

@juliobiason A lot of interesting observations in that. I really do wish I had the time to better check out Rust.

I haven't fully digested the post, but I have a few remarks.

Go fmt is more of a cultural question than a technical one. Publishing code that hasn't been run through it is frowned upon. So not really the same as with other languages I've seen, even those with good auto-formatters/pretty-printers. No idea where Rust lands there.

@tfb Then it is akin to Python and non-PEP8 code, and nothing that actually stops you from not following the community style.

Rust has compiler warnings for out-of-style code.

18 | let theContentOfTheFile = toml::to_string(&example).unwrap();
| ^^^^^^^^^^^^^^^^^^^ help: convert the identifier to snake case: `the_content_of_the_file`
= note: #[warn(non_snake_case)] on by default

@tfb Again, that's a warning, not an error, so you can ignore it if you want.

As a sidenote, I do love Rust errors messages, 'cause they not only say exactly that is the problem ("warning: variable `theContentOfTheFile` should have a snake case name") but it gives a hint on what you should do ("convert the identifier to snake case: `the_content_of_the_file`") and some other option ("note: #[warn(non_snake_case)] on by default")

@juliobiason It's quite a bit stronger than in Python, in that people reformat every file on every commit.

But that Rust warning is fantastic. Related, do you know about misleading indentation being a syntax error in Haskell and F# ? I'm totally stealing that for the Scheme I'm working on.

@tfb The book I read about Haskell let me a bit down about it, due the way they describe they default coding style (like "prefer single characters for most of the stuff"). I may revisit that one day, 'cause the auto-currying is something that really impressed me.

F# seems a bit farther, as I don't think you can compile F# on Linux yet, but I may be wrong here.

@juliobiason Oh F# on Mono on Linux works just fine, and has for quite a while. Not all of the dot-Net world works with Mono, but you don't need all that to start checking out F#. I prototyped a CAD tool in it a few years ago, and had no problems; the mailboxes and concurrency and everything worked great.

I'd recommend F# over Haskell for you, at least to start. It's the easiest ML language to get into. For better and worse, but it would be a great starting point.

@juliobiason For example, much less use of overly short names. Still some, but they try harder to have a style that's readable by programmers, not mathematicians.

The big thing it's missing is either Type Classes or Module Functors. Instead you get OO to fill a similar role. Which is a practical concession to coexisting with C#. On the other hand it has cool stuff that neither Haskell not OCaml have (type providers, computational expressions).

@juliobiason I was positively surprised at how well Go scales ... not up to Google-sized problems, but down to an individual application. I was skeptical, exactly because of Google-scale. It compares favorably to C++ or Java there.

The garbage collector and the LWT scheduler are the real jewels here. Holy crap they're good.

@juliobiason The compiler being fast *is* important, but Go boosters don't like to admit why; you don't get a lot of help from the compiler, so it better be fast!

The amount of time a compiler spends should be proportional to the help it provides. Go is in the same camp as Pascal was: it helps you prevent stupid, very local bugs, and it quick about it. Contrast to C++, which is less helpful but sure takes forever.

Rust of course tries to be much more helpful. That's mostly a good thing.

@juliobiason A lot of Go's deficiencies are also benefits. I don't want to build a big system with the tools they give you. How on earth would you compose your small modules? The language gives you no help at all getting that right.

But as a basis for building such a system? There it actually provides a decent lingua franca, which is a role that C and Java were always terrible at.

If course, that means you *need* to build your own high level systems on top of it.

@tfb You see, that's exactly the kind of problem with the original post: He kept mentioning scope creep and domain changes, things that are hard to fix on a monolith, but should be somewhat easier in a small, microservice system.

So most of the points he makes are actually bullshit and not applicable. And that pissed me off: Trying to defend the language for a thing it wasn't designed for.

@tfb Worse: Defending in a way that we don't develop anymore. It was plain stupid argument.

@juliobiason The original post looks like a shitshow, for sure. There's a reason I'm replying to yours and not the original post 😛

@juliobiason Oh yeah, one more: "goroutine" LWTs are great. Channels are ok, but remarkably hard to use. It reminds me of C++ here: by carefully building a system on top of what they give you, you can make a sane environment. But you absolutely depend on someone setting things up correctly from the start, or you're screwed.

And the non-solution for error handling is great if you want to build your own continuation-based system on top of it. It just gets out of the way. Pretty shitty otherwise.

Sign in to participate in the conversation
Functional Café is an instance for people interested in functional programming and languages.