Portability: Rust - Go Comparison

,

I agree with everything you said. I have some personal preferences to keep sharing with you though.

I am not arguing Rust’s benefits. I am just saying that if it’s not your 1st language then it’s probably gonna be a struggle to get used to that model. I admit I am looking at that solely from my point of view of a programmer that’s not very keen on learning several new languages or frameworks every year anymore. So if anything has a better tech-marketing (if that term makes sense) I’m much more likely to pick it up compared to if it has a lot of if-s and but-s in terms of where and how it’s supported. That’s all I meant; I am not arguing the merits which seem quite obvious and good.

Eh, that’s assuming Golang’s creators even entertained the idea of ever competing with C in the microcontrollers space. It’s a fair choice if they decided they didn’t want to bother.

Sure. I have to admit I am starting to itch for static typing and that’s why I’ll pick up OCaml this year, it’s a done deal (I’ve also done some reading to understand the implied types mechanic and that to have a highly-optimized machine code you should try and not make your functions generic but rather very type-specific – a notion I very much agree with).

As for Golang + K8s, I’ve heard the story and it’s quite absurd. Additionally, K8s seems to try and emulate OTP just on multi-machine & multi-region level which is admirable but it leads to a lot of duplicated effort. Oh well, it’s their time they are using, right? :102:

See, that’s why I said I am not informed well. I looked at it a year and something ago and wasn’t satisfied with that aspect. I am very glad they are rectifying this! It is often a make-or-break sign for the language’s future. Imagine if we had 5 competing Ecto-like libraries; many people wouldn’t take Elixir itself seriously if that was the case. That was my main point here and it seems we’re in agreement, plus that the Rust community is trying to converge and gravitate towards agreed-upon-libraries for more things than before. This bodes very well for it!

That’s true of course. Sympathies that you had to go through that! :101:

That’s a really huge discussion but overall I disagree: C++ was IMO borne out of the necessity to commercialize this whole computer programming thing and do it fast. Also it accidentally clicked with the lowest common denominator of programmers back then and was thus well-positioned in terms of marketing – at the time anyway. Its success is more a combination of an incident + corporate pushes than any technical merit or proficiency at all.

I don’t have a hard proof for those claims, just impressions of my work with it and the comments of 45+ year old very hardcore programmers who 17 years ago were commenting over their coffee break: “if there was something FP-like and with less undefined behaviour parts in the spec than C++ I’d take it right away even if it meant I have to rewrite 2 million lines of code to use it”. And these were people that wrote libraries running on 20+ different embedded boards in an afternoon. These were people that couldn’t rely on if (ptr == NULL) because on certain boards 0x00000000 was a valid addressable memory address. Etc.

C++ didn’t have the benefit of 20+ years of experience with something before it that made so many mistakes as it did. That’s true. But I’d go on and claim that the C++ committee and community didn’t even want to admit it was making mistakes for the longest time. Most of the C++ discussions on the forums I’ve seen ended with “you are doing it wrong” or “get good, noob”. I suspect this is largely unchanged even today.

My point with this is – I really do hope Rust doesn’t end up the same way. With what you said you are giving me hope that things will be better this time around.

2 Likes