* Posts by ssokolow

158 publicly visible posts • joined 3 Feb 2021

Page:

Rust haters, unite! Fil-C aims to Make C Great Again

ssokolow

Re: Differing purposes

> But, I believe that significantly changing the syntax style of programs (which I see in Rust, and in Zig)

The funny thing about Rust is that, aside from the bits of syntax they changed to avoid needing the Lexer Hack, Rust used C++ syntax wherever it could.

Rust is literally a GC-less OCaml derivative with syntax designed on the principle of "In the name of not being Just Another Research Language, let's take C++ syntax where such syntax exists and then fill the gaps with Ocaml syntax".

That weird, ugly 'a syntax for lifetimes is OCaml's equivalent to <T> because, on an abstract level, lifetimes are a special kind of generic type parameter.

->, let, match, Some, None, option, colon-separated postfix type declaration... all OCaml.

Rust's decision to call its tagged unions "enums"? That's standard in the academic/functional world where they're known as "data-bearing enums" because, in the reverse of a C union, the discriminant is mandatory but the payload is optional.

Apple macOS 15 Sequoia is officially UNIX. If anyone cares...

ssokolow

Re: But Toronto sucks

See also:

DOS/4GW (of DOS gaming fame) = "DOS/4G, Watcom Bundle Edition" → Watcom C/C++ → University of Waterloo.

(Basically, so many big-name DOS games showed that DOS/4GW banner because Watcom C/C++ struck a deal with Tenberry Software to include a limited-but-good-enough build of their DOS/4G extender with the compiler without the usual "the same as the whole compiler, paid again" license fee that was standard for commercial use of DPMI extenders at the time, and Watcom C/C++ was a product of Waterloo, Ontario, founded by former UWaterloo people.)

Heck, when Mr. Tenberry Software died a few years ago, he was in the middle of digging through his old floppies trying to find a newer version of DOS/4GW Professional (the paid-for upgrade with limitations removed) to donate to the Open Watcom C/C++ v2 project. Open Watcom is also what was used for the DOS and Windows 3.1 prototype builds of Retro City Rampage that buyers of the game get, so the ripples of UWaterloo continue.

Anthropic's Claude vulnerable to 'emotional manipulation'

ssokolow

Re: That is assuming they can fix these issues

> It's not emotional manipulation

It's shorthand for "querying for responses to cases of emotional manipulation that occurred in the training data", because it's hard enough to get people to say "Ubuntu Linux" instead of "Ubuntu".

Deno 2.0 looks to backward compatibility to move forward

ssokolow

Re: All going so well till the end

https://en.wikipedia.org/wiki/Capability-based_security

TL;DR: The web is "secure by default" because the APIs are designed so that they "lack the words to describe" things like reading a local file the user didn't explicitly choose to share.

Compare WASI (WebAssembly's capability-based POSIX analogue) vs. POSIX.

Vulnerabilities involve finding ways to break the system to synthesize new verbs, rather than having a full vocabulary with some having been declared taboo and needing to find ways to speak euphemistically like when when you're speaking POSIX and trying to break out of Firejail.

In essence, finding a vulnerability in a capability-based system is akin to breaking memory protection by finding a way to refer to phsical memory addresses that don't receive virtual memory mappings while your process is executing.

Torvalds weighs in on 'nasty' Rust vs C for Linux debate

ssokolow

Re: Hard truths

Ada's biggest problem was that, at the time, you probably got a C compiler for no extra charge with your copy of UNIX but you had to go out of your way to pay for an Ada compiler.

ssokolow

Re: If Linus had known Rust 30 years ago ....

> Do we really want things like "trait objects" and "fat pointers" in an operating system? The code is difficult enough to debug as it is, without introducing opaque abstractions. I think you're making my point for me.

My points were that:

1. You can already do this in C and, from what I remember, the Linux kernel already has these sorts of things where it's deemed appropriate... just with extra clutter because the language doesn't know them natively. (Sort of like the syntactic bloat Glib-based libraries like GTK see to implement C++-style OOP in C.)

2. Rust's design is pretty good at making dynamic dispatch and trait objects feel unappealing unless you actually need them. I think the only fat pointers that get used regularly are slices, which are (*data, len) fat pointers to subsets of strings or arrays. (They're great for zero-copy parsing.)

3. Unlike C++, Rust's support for polymorphism doesn't require you to be on your guard about whether the definitions of data structures have been modified. It's just a helper so your vtables and function pointers can play more nicely with any generic container types you might implement.

> Besides, even if the OOP in Rust is light weight at the moment, there's no guarantee that it will stay that way. The language isn't even standardised yet. What's to stop some clever person adding C++-style OOP to Rust "because it makes programming so much easier"?

1. Over the last decade, the RFC process has demonstrated that the Rust team aren't swayed by "because it makes programming so much easier". Heck, one of the things they've actively been focusing on is a proposal's effect on the language's complexity budget.

2. People have been clamouring for it for a decade now. The Rust team has stood fast on "There's no single design that's objectively better than the others, and all of them make trade-offs. We'll revisit this discussion when one of the implementations of this (via procedural macros) on crates.io has seen runaway success". (And none of them have. It turns out that classical inheritance is one of those things that people are loud about, but there's underwhelming little in-the-wild use of compared to other things implemented as procedural macros.)

3. Why did Rust add async/await keywords when you could do it using the futures crate? Not because the futures crate was a pain to use... but because it was demonstrated that it needed to be a first-class language construct for the borrow checker to behave in non-hair-tearing ways when you wanted to hold borrows across await points.

4. The whole reason Rust doesn't have an official, toolchain blessed executor for the async/await keywords is because they want it to remain suitable for both embedded and big-scale servers.

5. The Rust team have strong opinions that features added to the language must be orthogonal and harmonious. That makes adding C++-style OOP highly unlikely because it would overlap too much with the existing design.

6. Standardization does nothing to prevent a language from adding footgun-oriented programming features... it just means they have to live within the undefined/implementation-defined portions of the spec, or be stuff that wouldn't compile in a purely standard-following implementation.

> Is it really? I wasn't aware of this. I believe Linux has been built using Intel's C compiler. Can you give me an example of the use of non-standard "GNU C" in, say, Linux 6.6.52? That is, a file name, line number, and a short description of the quirk? I'd be most interested to see this.

I'll do one better. Here's a blog post that does a run-down of the GNU extensions Linux depends on, including example code snippets:

https://maskray.me/blog/2024-05-12-exploring-gnu-extensions-in-linux-kernel

Both LLVM Clang and ICC have implemented a bunch of those extensions with the intent of being able to compile the Linux kernel. (Getting those extensions implemented was the lion's share of what the project to get the Linux kernel building on LLVM Clang was doing... though there was also patching done to retire use of ones the kernel devs were less fond of than they used to be. For example, the kernel was using GNU C's pre-C99-style Variable Length Array support and removing that, though desirable in its own right, also avoided the need to implement them in Clang. I think the project was called LLVMLinux but it's been a while.)

ssokolow

Re: About programming language standards and the choice of language

And there are other compilers for Rust in various states of development, from the specifically-for-re-bootstrapping mrustc (which is already usable but assumes you already got it to pass borrow-checking under rustc) to the intended-for-general-use Rust-GCC, under the paradigm of "If this compiler and rustc diverge, unless it's agreed to be a bug in rustc, this compiler is wrong".

In real-world terms, how is that different from what Linux experiences from being written in GNU C?

ssokolow

Re: If Linus had known Rust 30 years ago ....

> It's even got object oriented stuff in it; who needs OOP in a kernel?

Let's look at Rust's "OOP":

1. Encapsulation: Rust has "pub" and stuff not marked "pub" will be inaccessible outside the module that defines it. In Rust, a module is a file or a `mod foo { ... }` block within a file. ...sounds not that different from C's "static" to me.

2. Objects: Rust has `struct`, just like in C, and it has "data-bearing enums" (a concept from functional languages) which are just tagged unions with first-class language support. Method syntax is literally syntactic sugar for free functions with the "parent" type as the first argument and they can be called as such. In C++ terms, Rust structs are always POD (Plain Old Data) with no vtable snuck in.

3. Inheritance: Nope. Rust doesn't have the implementation inheritance you're thinking of. It does have "interface inheritance", but that's just the ability for an interface definition to say ""To implement the Error interface, you must also implement the interface for Debug printk".

4. Dynamic dispatch: Same as C... if you take a function pointer or specifically create a vtable, you get dynamic dispatch.

5. Polymorphism: Rust supports generics, so you can define "List of [insert type here]" and have concrete instances generated at compile time for the types you use, and it supports "trait objects", where you can ask to create a fat pointer instead of a normal pointer, with the fat pointer being a (*struct_instance, *interface_vtable) struct under the hood. (eg. for "List of [Debug-printable thing]") It also supports macros, as C does.

> Besides which, the language isn't even standardised, yet. Using it in Linux is creating maintenance time-bombs for the future.

Linux is written in GCC's extended GNU C dialect, which is no more standardized than Rust, and the Rust team have a policy called the v1.0 Stability Promise which is akin to Linux's "don't break userspace" rule.

The only reason the Rust for Linux efforts currently require a specific compiler version is that they're using API-unstable experimental language features (which require a nightly compiler and a special #![feature(...)] annotation to access) which they're working with the Rust team to shake any design faults out of and get stabilized... at which point they fall under the v1.0 stability promise. (Basically, the effort is in a state akin to when Android required a bunch of out-of-tree patches which eventually got upstreamed.)

That's part of the reason they don't WANT their efforts to extend beyond the odd driver here or there yet.

ssokolow

Re: About programming language standards and the choice of language

And Linux has "Whatever GCC does is correct. If your other compiler does something different, it's wrong". Linux isn't written in ANSI C, it's written in GNU C and depends on GNU extensions.

...and Linux isn't an exception. It's very commonplace for C and C++ projects to have one compiler (maybe two) they support per platform and, if you want to go beyond that, you're on your own.

ssokolow

> he said that it is difficult to map something like the DOM onto a language that isn't all that object-oriented

That's a fair criticism. The experimental Servo browser engine that various Firefox enhancements were taken from (eg. the multi-threaded CSS engine) is still just reusing Firefox's SpiderMonkey JavaScript engine and they just let SpiderMonkey handle the DOM. (Granted, probably for the same "let's not prematurely make work for ourselves" reason that rustc is built on LLVM.)

ssokolow

Rust was more or less created as "OCaml with less weird syntax and a more low-level-friendly memory management strategy". The original Rust compiler before it became self-hosting was written in OCaml and any syntactic element you don't recognize from C++ is 99% guaranteed to be from OCaml.

(Which is funny, because, in the early days of Rust, people who didn't recognize that were making jokes about Rust being a conspiracy to trick C++ programmers into writing Haskell.)

ssokolow

Re: Why the push?

Network effects.

Same reason I continue to write my GUI apps using PyQt and Python instead of cloning Qt's QWidget APIs in Rust. Hell, I don't even have the free time to take up the dormant Ritual bindinging generator for QWidget from Rust and push it to the finish line.

ssokolow

Re: Unusual syntax

It's because Rust is a language of the ML lineage (ISWIM (1966) → ML (1973) → Standard ML (1983) & Caml (1985) → OCaml (1996) → Rust (2015)) which slapped on a liberal coat of C++ paint to make itself more appealing to mainstream developers. All the syntactic elements you don't recognize are from OCaml, which the Rust compiler was originally written in before it became self-hosting.

(Yes, even that weird `'a` syntax for explicit lifetimes. It's OCaml's equivalent to C++'s <T> because, on an abstract level, lifetimes are generic type parameters. "foo is generic over all lifetimes `a and all values T".)

Using -> to denote a return value is common in the world of academic/functional languages, which got it (and many other quirks C lacks) from mathematical notation and the whole "postfix types" thing, combined with that fixed `fn` keyword, is to avoid needing the lexer hack and to avoid needing some kind of placeholder like `auto` when you want type inference to be the default choice.

ssokolow

Re: My understanding...

I've only heard of the Rust developers asking for clarification on how C APIs are supposed to be used beyond "do what X downstream C code does and, if it goes wrong, you didn't mimic it hard enough".

ssokolow

Re: About programming language standards and the choice of language

...and Rust has RFCs which serve the same role... as well as a very comprehensive regression/conformance test suite.

ssokolow

Re: About programming language standards and the choice of language

Rust "has been moving a lot" in the same way that C89 gave way to C99 gave way to C11 gave way to C17 gave way to C23. Existing language elements continue to work as new ones get added.

Aside from the exceptions made for soundness-breaking compiler bugs and the odd hiccup along the lines of "I hung a method `foo` off this standard library type using a custom trait and now there's an official `foo` and the compiler wants me to disambiguate the call", today's Rust compiler will build anything back to Rust v1.0 in 2015 so long as you didn't use the experimental APIs you can only access in nightly compiler builds which need to be explicitly flagged on with `#![feature(...)]`.

You can write 2015 Rust and compile it in a modern Rust compiler... it'll just look inelegant compared to 2024 Rust.

For example, originally, you used a macro to early-return, so you'd do something like `try!(try!(try!(dom.find("span[foo]")).attr("bar").find("baz"))` and now, thanks to the "try operator", you write `dom.find("span[foo]")?.attr("bar")?.find("baz")?`.

ssokolow

Re: My understanding...

The problem is that, fundamentally, anything which solves the problems being faced will have the same effect Rust does, because what Rust is asking for that C doesn't provide is machine-checkable metadata about lifetimes and invariants.

It's like an assembly-language project pushing back against C for wanting each value in memory to have an explicit type associated with it instead of just using ADD or FADD or what have you, and complaining that the C code should be responsible for magically guessing what type a pointer's destination is.

ssokolow

Re: My understanding...

The "changes" being requested are basically "Please document how this API is supposed to work in enough detail that the Rust compiler can enforce it on Rust code".

To put Ted Ts'o's tantrum in more measured words, he's concerned that having Rust in the kernel will be a de facto push for C developers to either stabilize kernel-internal APIs or take responsibility for learning Rust so the "you fix whichever downstream consumers your change breaks" policy can be extended accordingly.

(Were I in his situation, I'd have politely made my cooperation conditional on extracting a binding promise that Rust in the kernel is an exception to that rule.)

ssokolow

Re: Hard truths

"On the whole, I think Preparation H feels good." -- Dr. Evil

Google says replacing C/C++ in firmware with Rust is easy

ssokolow

Re: Embedded? Don't think so

https://caniuse.rs/

You're welcome.

ssokolow

Re: Wanna give some examples?

History tells us that languages gain standards for two reasons:

1. A wild west of incompatible implementations exist, which need to be tamed to the degree the competing interests will allow their divergent behaviours to be reconciled. (C, C++, ECMAScript, etc.)

2. A single vendor is trying to check a box to appeal to government agencies and big enterprise. (Java, .NET, etc.)

...and, would you look at that. Rust is trying to court government agencies and big enterprise, so they're working on that:

https://ferrocene.dev/

https://github.com/rust-lang/rust/issues/113527

ssokolow

Re: Wanna give some examples?

> C/C++ compilers have had decades of refinement behind them

...which is why rustc built on top of LLVM instead of reinventing it.

> It looks like only x86 and ARM-64 are well supported ("tier 1").

Rust's standard for Tier 1 is quite literally "access to affordable CI servers running on that architecture so we can do a build and regression-test run on every commit pushed to the repo". No affordable vendor offering ARM32, MIPS, PowerPC, or SPARC colo beefy enough to compile the Rust toolchain and run its test suite in a reasonable amount of time? No Tier 1 status for those platforms.

(Before Microsoft started donating Azure time maybe five years ago, waiting on their CI servers to check patches was starting to become a bottleneck on their development velocity.)

Tier 2 would be more comparable to what GCC devs do.

> A lot of that problem would go away if they'd switch the focus to adding a GCC frontend, where almost every other major language and target architecture is supported.

In progress:

https://blog.antoyo.xyz/

ssokolow

Re: Wanna give some examples?

...plus, Rust's `String` type and corresponding `str` slice (the default, as opposed to its `CString` type and `CStr` slice for FFI) being Pascal-style counted strings makes it better than C for zero-copy parsing because you don't need to copy or modify the thing being parsed to introduce null terminators for string fields.

I've actually implemented something similar in the Open Watcom C/C++ retro-hobby project for DOS that I need to get back to for exactly that reason.

ssokolow

Re: Wanna give some examples?

Umm... yeah. It's called a hobby.

ssokolow

Re: Wanna give some examples?

"C/C++" is a shorthand for "C and/or C++" in the same way that semicolons are how you represent the "tone-of-voice shorthand" for conjunctions like "and", "or", "but", etc. (eg. "Scripting languages like Perl/Python/Ruby/etc.", "American car manufacturers (Ford/GM/Chrysler)", etc.)

C and/or C++ developers are the only people who try to dodge addressing actual points by acting like ill-mannered children about a syntactic shorthand that's used throughout the English language. I hereby politely request that you cease discussing in bad faith post haste.

The empire of C++ strikes back with Safe C++ blueprint

ssokolow

Re: Rustification of C++?

1. Rust's rationale for having a fixed "let" token instead of prefixing the type is twofold: First, it simplifies writing a parser because you don't need the lexer hack and, second, the presence of `let` or `auto` distinguishes variable shadowing from variable assignment when you've got no explicit type because you're letting it be inferred. (It's also one of those places where Rust's Ocaml heritage shows through.)

2. In Rust, it's not an "int". Instead of having automatic numeric type coercion, the types of numeric literals are inferred and fixed at the point of declaration/assignment. (Though floating point literals will default to f64 (i.e. double) and integer literals will default to i32 (32-bit signed int) if unconstrained.)

3. Due to type inference, you generally only need to explicitly specify the type in a `let` if there is insufficient information to infer it. Type signatures are "infallible patterns" so, outside of places like function signatures where inference is disallowed, it can be left incomplete. (eg. the `.collect()` method on iterators can return multiple different types, so it's common to write something like `let result: Vec<_> = the_iterator.collect();` to specify you want to collect into a Vec if the way you use it doesn't make that clear. ("Fallible patterns" are what you see in constructs like `match`, `if let`, and `while let`.)

4. I'm not sure I follow your point about mutability. Could you elaborate?

ssokolow

*nod*

`unsafe` doesn't alter how the main body of the language works. It just grants access to a few extra operations.

(dereferencing raw pointers, calling functions and methods marked unsafe, implementing traits (basically interfaces) marked unsafe, mutating mutable statics (as opposed to putting something like Mutex<T> with interior mutability into an immutable static), and accessing fields of untagged unions.)

Stuff like creating two mutable references (references, not raw pointers) to the same memory is still undefined behaviour and will run afoul of things like the LLVM IR noalias attributes rustc sticks on them (what Clang turns the C `restrict` qualifier into).

ssokolow

No, because "barfs on your code" in the context of a borrow-checker means "compiler needs you to clarify your intent".

For example, if you have a Rust-style borrow-checker with shared/mutable borrow semantics (i.e. compile-time reader-writer locking) and you get a lifetime error, you probably don't want the GC-esque solution of "automatically promote it to a heap allocation behind a std::shared_ptr to make it live long enough". You're using C++, so I assume you want a high degree of control over allocation behaviour and how it affects memory footprint and performance.

Likewise, if it sees you trying to take a shared and a mutable reference at the same time, should it make a copy? Wrap it in a mutex? Reorder the code so neither is needed? Each one will sometimes be the correct reaction to a borrow-checker error of that type.

It's sort of like how PHP tried to "just make it work" and wound up with `echo 10 + "10,000 eggs";` producing "20" as output.

ssokolow

Re: I'm doomed

The key detail is the word "may".

It's not "Indexing into arrays is bad"... it's "Indexing into arrays is such a generic construct that it enables you to easily write access patterns that can't be mechanically verified".

(Though, in Rust, aversion to array indexing is more about "Array indexing performs runtime bounds checks unless you use the unsafe-marked getter. Use iterators where possible.")

ssokolow

There's unsafe and then there's "unsafe"

The Rust ecosystem has a bunch of crates like abi_stable (Rust<->Rust), PyO3 (Rust<->Python), and so on which let you write high-level, safe-Rust APIs and have it generate the marshal-through-C-ABI code under the hood for you to provide a compile-time guarantee that everything matches up.

Given prior art, it's part of the Rust philosophy that they're very conservative about putting stuff into the core language or standard library (and, thus, promising to include and maintain it in the core Rust toolchain download forever) when it can be implemented as a crate. (And, thanks to procedural macros, a lot can fall under that "prove there's that much demand for a specific design first" heading.)

...and, so far, it's served them well, with things like once-cell getting into the standard library instead of precursors with less comfortable APIs like lazy-static.

Can AI shorten PC replacement cycles? Dell seems to think so

ssokolow

Re: re. Generally speaking profit is not good for the environment.

The planet's not going anywhere. We are! -- George Carlin

ssokolow

Re: Quick survey...

Personalized porn. It's the only thing appealing enough to large numbers of humans to make all that time shepherding a "plausible gibberish generator" feel worthwhile.

ssokolow

Re: Where's the incentive?

*nod* Until this January, when it got too annoying to have to try to figure out how to swap an AVX-less build of Tensorflow into a Conda environment, I was doing quite well with my Athlon II X2 270 from 2011 running Linux, up to and including Rust development. (Granted, I'd just upgraded it from a 2014 GeForce GTX750 to an RTX 3060 that Cyber Monday.)

Here's hoping my new Ryzen 5 7600 lasts me another decade at least.

Microsoft shows venerable and vulnerable NTLM security protocol the door

ssokolow

Samba when?

Here's hoping Samba doesn't drop it too quickly. It's annoying enough to have to maintain my own build of Netatalk 2.x if I want network browsing between the retro files share on my main PC and the classic Mac OS side of my retro-hobby subnet to work.

Having read the room, Unity goes back to drawing board on runtime fee policy

ssokolow

Re: Too little, too late

I know it's months late, but, for anyone else who wanders in, it doesn't "depend on the license".

"Open Source" has a concrete definition laid out at https://opensource.org/osd which rules out that sort of license. That's why you see licenses like that being referred to as "source available" instead.

(Which makes sense. The Open Source Definition is essentially a derivative of the Debian Free Software Guidelines with the political implications of "free software" filed off, and debian-legal has a test named "the tentacles of evil test" specifically for checking whether a license is suitably good at protecting users of a project from a buy-out by a company like Oracle.)

Sleuths who cracked Zodiac Killer's cipher thank the crowd

ssokolow

Or they ask what the heck IPA means and are given a beer.

Rust developers at Google are twice as productive as C++ teams

ssokolow

Re: I wonder...

In Rust, the general answer is "If you don't recognize the syntax, assume it's from Ocaml". Rust is more or less a GC-less ML derivative wrapped in some borrowed C++ syntax to make it friendlier. (Right down to rustc originally having been written in Ocaml.)

In that specific case, 'a is the Ocaml equivalent to <T>, because, abstractly, lifetimes are a special kind of generic type parameter.

ssokolow

I finally got around to watching the talk itself. The question wasn't "How confident are you that your code is correct?", it's "How confident do you feel that your team's Rust code is correct?"

...that is, it's asking "Having experienced reading and reviewing your teammates' code, do you feel more or less confident that they've done it properly when they write in Rust?"

Still not saying whether they did do it properly, but Rust appears to make reviewers feel better about what they're reading from other people at least.

ssokolow

Re: "Testing Code"

Or, as Dijkstra put it, "Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence."

ssokolow

Re: Have to wonder....

"I have to wonder whether the increase in programmer productivity is in part due to much smaller Rust teams than the "huge" C++ teams."

I hope not. Rust's raison d'etre is to extend the type system to be able to effectively act as a lockout-tagout system for programming to limit the ability for defect rates to climb as team sizes do. (i.e. to protect you from changes you didn't see someone else make and vice-versa and to minimize the need to reason globally about the codebase's behaviour.)

ssokolow

Re: confidence

"Call it "Csafe" or something. It can compile C code but will include bounds checking and all that guff to make it a little bit slower but a lot safer. After all, C++ exists and didn't replace C..."

Various efforts have been made and even more proposed over the years. (eg. the splint linter has been able to enforce a surprisingly large subset of what Rust can do via annotations for 20 years now and I remember seeing at least one mentioned on LWN years ago) ...the problem is getting actual interest from programmers.

Hell, some of them, like Cyclone, were direct inspirations for Rust.

What really makes Rust special is successfully achieving critical mass.

ssokolow

Re: Rust really is easier to write and maintain

They could have meant any of three things by that:

1. Rust isn't good for making GUIs because the ecosystem is particularly immature there.

2. Rust isn't good for making GUIs because Rust doesn't do classical inheritance and the big-name widget toolkits tend to be based on that type of OOP, so the bindings aren't as nice-feeling. (See, for example, how gtk-rs does it.)

3. Rust isn't good for making GUIs because existing toolkits have their own conceptions of object lifecycles which need to be adapted in any bindings written.

All three are true to some degree... but then I'd also say that Rust isn't the best for the niche that the Django framework for Python fills, because it's got a gigantic ecosystem of reusable components already written.

Keep an eye on the Iced toolkit. It's what's System76 is using to develop the COSMIC desktop for Linux.

Microsoft seeks Rust developers to rewrite core C# code

ssokolow

Re: JavaScript "Performance"

You are aware that an application server will want to service more than one request simultaneously, right? Wasted cycles are wasted cycles... especially in this era of "bill for every CPU cycle" cloud services being popular.

ssokolow

Re: Microsoft seeks Go developers to rewrite Rust core code

You're probably thinking of this Discord Blog post: Why Discord is switching from Go to Rust

ssokolow

Re: Rockstar

Whenever I see a hyperlink with some variation on "this" as the text, I assume Rick Astley will be on the other end and don't bother.

ssokolow

Re: Indeed

In Rust's case, it doesn't automatically insert mutexes. It instead says "Hold up. Did you mean to share this? If so, you'll need a mutex."

...because, sometimes, what you really want is to fix the bug that's causing it to keep a reference, so you can just send it to the other thread without sharing it.

Otherwise, you wind up with things like those JavaScript "something, somewhere, is still holding this alive when it shouldn't be" memory leaks.

ssokolow

Re: Efficiency

Which is what things like stack allocation are for, along with APIs designed to make reuse of heap memory without handing it back to malloc easy.

ssokolow

Re: JavaScript "Performance"

Plus, the elephant in the room with all these "high-level, in the 'let me focus on the business logic instead of machine details' sense" languages... it's very easy to fall off the fast path.

A statically typed GCed language like C# or Go will give the compiler more ability to say "Whoa, hold up there. Are you sure you meant that?" and something like Rust, C, or C++, where you explicitly choose things like inline/stack allocation vs. unique heap pointe vs. reference-counted heap pointer instead of letting automatic allocation handle it will do so even more.

(To be honest, my biggest complaint about Rust is that LLVM doesn't give them the APIs they'd need to viably make things like "this optimization used to get applied and now it doesn't" into a compile-time error.)

ssokolow

Predictability

Here's the most recent This Week in Rust featured quote:

The sheer stability of this program is what made me use rust for everything going forward. The social-service has a 100% uptime for almost 2.5 years now. It’s processed 12.9TB of traffic and is still using 1.5mb of ram just like the day we ran it 2.5 years ago. The resource usage is so low it brings tears to my eyes. As someone who came from Java, the lack of OOM errors or GC problems has been a huge benefit of rust and I don’t ever see myself using any other programming language. I’m a big fan of the mindset “build it once, but build it the right way” which is why rust is always my choice.

-- https://www.reddit.com/r/rust/comments/1ach3ir/what_were_some_of_the_first_useful_applications/kjuhaox/

Memory safety isn't the only thing under the heading of "predictability" that Rust is good at. Implicit control flow is also a big one.

For example, NPM experimented with doing something similar with one of their Node.js-based services and kept the rewrites because, while they performed about the same as the hyper-optimized mature JavaScript codebase doing things Node.js had been tuned to be best at, they eliminated the flood of uncaught exceptions they were constantly working to track down in their log files.

Gtk 5 might drop X11 support, says GNOME dev

ssokolow

Re: Opposites

I think the word you're looking for is "ModeLines".

(Source: I had to do it within the recent past to get 1080p working on an HDTV with broken EDID tables and I'm pretty sure the syntax was the same as it was when I first got into Linux in the 2000s. I still vaguely remember the two different iterations of "make me an XFree86 config" tool that we went through before finally getting autoconfiguration with Xorg and X11R7.)

Page: