I write billing apps because I'm a masochist and feel there is deeper meaning to be gained through suffering. Lot of data and rules to process. Torn between learning Go or Rust next.
I do love Rust, but one complaint is that early design decisions because of my weak understanding are extremely hard to refactor out later on. Poor type choices can end up bleeding into the entire project that become nightmares to improve.
My advice is to use cargo workspaces to break up your project into small self contained modules early so when you will inevitably need to refactor, it will make your life less painful.
> Temporal databases aim to make our programming lives easier around time, by baking time itself into the engine. One major feature of temporal databases is the ability to query the database as of a particular point in time.
Having learned SML / Haskell in the past I've got a bit of a soft spot for languages that are utterly cruel to you with their compilation errors but lead you straight to bug-free code. What I've heard about Rust puts it in this camp.
One thing that does concern me about Rust: when I (now and then) look at what's changing in C++ it feels like a lot of new mechanisms and abstractions are required to address problems created by previous design decisions. I sometimes read about Rust and worry that I might need to embark on a similar journey.
https://drewdevault.com/2019/03/25/Rust-is-not-a-good-C-repl...
Can you find the flaw in this statement?
No spec doesn't mean there's nothing keeping rustc honest, it just means there isn't a spec keeping rustc honest.
> Any behavior it exhibits could change tomorrow.
And pigs could fly tomorrow as well. This is not a serious engagement with the ways the Rust developers go to great pains not to change behavior (such as crater runs). In many ways empirical evidence like crater is more valuable than some random document that might or might not be fully obeyed at any given time.
> That they can’t slow down to pin down exactly what defines Rust is also indicative of an immature language.
Rust has slowed down a lot, just not to Drew's liking. And he isn't acknowledging the ways in which the risks of moving fast(er than he would like) are mitigated.
> Safety. Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.
Please leave the software industry. This is embarrassing.
> I especially refuse to “rewrite it in Rust” - because no matter what, rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would.
What evidence is there for this position? My contention is that a Rust rewrite would maybe not start that way, but rapidly exceed the C version in quality because it is just a more modern language.
Your concerns regarding "feature creep" are reasonable and would be expected for a language trying to displace C++.
Edit: grammar
For Rust, you can likely encode most rules and transitions between states in the type system itself. It’s a super power in that niche.
Screenshot of the Golang website from ~2010: https://i.imgur.com/AYeUvuE.png
https://learn.microsoft.com/en-us/events/lang-next-2014/pane...
- TinyGo (https://tinygo.org/), which is acknowledged by people in the industry[0][1]
- TamaGo unikernel on USB Armory secure key (https://www.withsecure.com/de/solutions/innovative-security-...)
And then there is the question if writing compilers, assemblers, linkers is systems programming or not.
[0]-https://www.cnx-software.com/2019/08/28/tinygo-go-compiler-f...
[1]-https://twitter.com/ArmSoftwareDev/status/131680481331796787...
Just because you can provide some niche examples where Go is used as a systems programming language doesn't mean it is a general purpose systems programming language.
Putting Go in the same category as C/C++/Rust/Zig is ridiculous.
Ridiculous is being a gatekeeper lacking imagination.
Thankfully for mankind's progress they tend to be a minority, even though they sometimes get into the way.
Yes, it is gatekeeping, back in the 8 and 16 bit home computer days, or even before during the computer revolution, it was anything that could help to develop the whole stack.
From the gatekeepers point of view, Xerox PARC never did any systems programming.
Like I said, I think the main issue here is terminology, but you brushed that aside. From a cursory glance, Xerox PARC definitely did low-level programming so I'm not sure what "the gatekeepers point of view" is supposed to mean.
What is low-level?
Coding in C back in the 8 and 16 bit home computer days when C was useless without piles of compiler extensions beyond K&R C, requiring either inline Assembly or an external Assembler, and even BASIC provided better primitives for hardware access?
On the Go web site there wasn't anything in that direction, for example.
Closest I found by web searches was references to this 2014 post from an analyst company: https://redmonk.com/dberkholz/2014/03/18/go-the-emerging-lan... - in there it's opined that Go has a strong position in cloud infrastructure (but doesn't imply that it's designed or suitable only for that).
Fastest compile times vs slow compile times. Excellent type system vs very basic type system Complex language vs Simple language
If I were to learn a new language it would be rust because I like it's type system.
That being said I use many cli tools written in rust and golang.
fwiw - I learned Rust, was painful at first, but now I love it.
However, the type checking in Rust is fantastic. The confidence in correctness that you have when it is complete is much higher than many other languages.
Use case would probably be a major factor in the decision e.g. picking up rust from scratch to write a basic network service would probably be stupid unless it had very strict requirements known in advance (and even then you might want to write it in go anyway in case that works out or to quickly uncover issues you’d hadn’t predicted).
If you know in advance you have very strict resource constraints however, or you really need the reliability (of extensively encoding things in the typesystem), or you’re writing native extensions (python + rust via pyo3 is great, python + go is something I’d avoid unless the entire solution already existed in Go and I could expose it to python over a pipe), etc… then the investment would likely be more worth it.
Basically, how much return would you expect, Go requires very little investment, Rust a lot more.