-- Leo's gemini proxy
-- Connecting to bbs.geminispace.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini; charset=utf-8
I think there are two larger problems with using Rust, at least for the kind of programming I want to do, that didn't start coming into focus until I went back and starting using C again.
A lot of people complain about binary size when they come to Rust. That's with good reason, too. A simple "Hello World" in Rust, as of just now, comes in at 334128 bytes. In the case of a simple project that is down to compiling in the standard library statically, but the problem compounds as you grow your code, particularly when you add dependencies. There are multiple reasons for this.
Take traits and macros. Every time you use #[derive(Debug)] the compiler writes some code for you. What most people don't get is that when you manually implement the Display trait, the compiler is writing code on your behalf again, even without your knowingly invoking a macro, because there are generics involved in how Display works. Basically any time you implement one of the traits out of 'std' on your types you can expect a disproportionate increase in code size. I don't care for this. I'd rather have only the code I actually wrote.
The other issue I have is the friction you get when working on low level code that has to interact with the OS directly. Funny, but the official way to do most low level things is to use the libc crate. Memory safety goes out the window the moment you use ffi, and yet the moment you try to suggest this is bad there will be an angry mob of rustaceans with torches and pitchforks.
While I'm on ffi, allow me to point out a related gripe. Since Rust is still calling into libc under the hood everywhere in 'std', and the vast majority of Rust devs are using x86_64 Linux with Glibc, by default every other platform is a second class citizen with lots of potential for undefined behavior and regressions on every compiler upgrade. I've seen it plenty of times, and the problem compounds the more you use ffi. It's why I haven't done much with Eva in a long time. I got tired of my code compiling perfectly fine, but on Void with musl it would immediately segfault as soon as Gtk is initialized. Things like that get old.
2023-08-21 · 9 months ago
@jeang3nie What I meant is, nesting is a problem when it makes the code less readable, reduces the team's development velocity and makes it harder to collaborate (when it creates conflicts). When the language encourage nesting, it encourages bad patterns I usually see in code written by people who use C++/Java/C#, or grew in that culture, which sometimes emphasizes 'elegant' OOP and heavy use of namespaces/classes/try blocks/... over readability or easy collaboration.
@gemalaya In many projects, performance doesn't matter enough to make big sacrifices in development velocity, ease of collaboration with new people and general developer experience (good documentation, tooling, stable ecosystem, etc').
@dimkr I agree. What's your favourite language ?
I've just read your article after finding a YT video about Rust... and while it started pretty well... they lost me the moment the guy at the video says "You can write everything in Rust".
Hm, yeah, the same was said of JS, C, C++... and we all know, that not all problems are nails. It made me think "What kind of people are the so called rustaceans" and your article just made my suspicions right.
And yes, the community is important, specially the attitude of the language developers, in how the language itself evolves.
@gemalaya I think it's Go. It's not perfect but I love it for various reasons (most of them translate into good productivity) and I have success stories with it at work. I use it when I can compromise on executable size and sacrifice some performance (i.e. when I can't just minimize memory allocations, etc' in hot paths) to gain easy collaboration, easier development overall and a good performance+scalability vs. attention to detail ratio (especially when I mentor a junior developer). Most of my toy projects, including my Gemini client, are still in C I think I should fully translate at least one to Rust (or zig?) instead of giving up at an early stage.
@dimkr Cool. I have nothing bad to say about Go, one of my favourite projects, kubo (IPFS implementation) is written in Go.
I'm into GUI development, this is what i wrote recently (Gemini browser written in QML):
https://gemalaya.gitlab.io/
i have been written similar comment recently in other thread (even 3 comments) but let me try to express myself again.
i am someone who was talking about safe programming and strong typing for at least 20 years.
we had ada, modula-2, modula-3, oberon, well even pascal freepascal or gnu pascal are much safer than c/c++ and these pascal implementations had modules.
nobody was even trying to use these languages.
today go is successful in part because it has google, and rust is successful in part because it has corporate promotion.
it is good that people started to care about safety. i personally like go (it is very much inspired of oberon, and i like oberon) and i personally dislike rust.
i dislike rust because it is slow to compile. it takes days on pinebook, and that is a bad sign for me. i don't want to use something that builds long. and i build everything i use on my laptops.
go builds very fast. the compiler itselg builds in 2 minutes.
my oberon compiler builds itself in seconds and most of the time is wasted by gnu tools behind it.
recently there was a thread on openbsd mailing list. why openbsd project would not write more in rust or rewrite some code in rust? and one of the answers was by theo - the founder and leader of the project: rust even cannot build itself on x86 because it needs more memory than 32 bit address space allows.
so i would say, if you are interested in modern and safe programming then
if you need libraries, big community, or master skills that can help to get a job then take a look at go - i am glad it exists.
i am not glad that rust exists.
otherwise if you want to tinker with interesting modern tech (even if it is from 80ies it is modern and some badly designed things today aren't, those are just contemporary) then take a look at ada (it is a big language for some people's taste) or modula-3. modula-3 is a small language which has everything programmers usually want: parallelism in language, exceptions, oop.
if you want even something smaller then oberon is a great language.
here as a side note some words about contemporary pascal. i dislike it because the de facto standard (not iso) was driven by a company, and it had to market it, add features, closely tie to an ide, etc.
i like that there is floss compiler fpc, and though it mostly (but not always) follows the language standard defined by a company behind delphi, it has many valuable properties and it is very underappreciated (though not as much as ada, modula and oberon).
no dependency on libc by default. compiled binaries are statically linked with runtime library which uses kernel syscalls directly, bypassing libc.
those binaries are of very small size: about 20kb.
stand alone commandline compiler, no dependency on the ide, i usually use vim, support in gdb, almost every architecture and os is supported.
very efficient memory manager: programs compiled with fpc are outstanding in compiler benchmarks by very low memory usage.
enegy efficiency: if you look at
you'll see in the table 5 (pareto optimal sets for different combination of objectives) that there is always c on the first line, but also there go twice and there is pascal three times.
time & memory: winners are: c, pascal go
energy & time: c alone
energy and memory: c and pascal (pascal is better than c if we take only memory usage)
energy, time and memory: all three share the first line; c, pascal, go.
unlike other languages i mentioned (ada, modulas, oberon) pascal has a reasonably big community, many libraries.
lazarus is a great tool to create gui programs. same program can be compiled with gtk backend or qt backend, or for winfows or macos. or amigaos or morphos. or by using a toolkit written in pascal.
you dont need anymore to change your program because underlying ui toolkit gets deprecated: community updates the lcl (lazarus component library) backend, lets say it also supports not only gtk2 but gtk3, or newer version of qt, you just recompile your program and you get a version which works with newer or different ui toolkit.
wide list of supported platforms also mean you can write with fpc for an old palm pda or for game boy advance.
[gemini link] I've been using Rust for about five years now, but I'm beginning to sour on it. I'm curious about perspectives here.
-- Response ended
-- Page fetched on Sun Jun 2 11:17:43 2024