Firefox’s reader mode is a lifesaver here.

I removed the background and background color via inspector which makes it a lot easier to read.

I’ve done enough accessibility work on the web to announce: this site’s contrast is great, but its presentation is horrific.

I think the bigger issue here is how far the Hiveway people have gone to ensure that all connection with the original Mastodon project, including the authorship of individual commits, was removed. Does that violate the AGPL? I have no idea, IANAL etc, though I suspect it does. But, even if it doesn’t, that is a deeply shitty thing to do.

Just because it’s technically legal doesn’t mean it’s not a shitty thing to do.

Yep, he’s already on the list of people to interview ?

Yea, I usually count myself among Go’s detractors but this point even befuddled me. I think Go has it’s share of code-reuse issues but it seems like this particular issue would be easily solved by embedding data members or a better use of interfaces.

IMO, the fact that Google is now officially supporting it for android development is a pretty significant sign that it isn’t going away anytime soon.

I see this as a temporary hype.

Counterpoint: if you search by stories + newest for Kotlin, there are 3 pages of “Kotlin” stories. Roughly 3/4 of the first page of results has “Kotlin” in the title. The oldest story of the first page that has “Kotlin” in its title is 3 months old. Understanding that Lobste.rs moves relatively slow, I think it’s fair to say that people are definitely posting about the language SOME of the time on here.

Now, because it’s recently gotten the “officially supported on Android” greenlight is probably what’s giving it temporary hype. But, I’d argue that Lobste.rs is still going to get a steady stream of Kotlin-related stories, and I’d like to have a tag for that.

Maybe it helps if you’re familiar with the author? I’m pretty familiar with Yegge’s writing, so as soon as I saw his domain on the entry I understood the title to be tongue-in-cheek

I’ve lost the original source so I can’t properly attribute the joke, but:

they’re Medium posts because they’re neither rare nor well done

I can’t find the link now, but I remember one of the rust core devs explicitly saying that swift was the inspiration for the question mark syntax.

I think there is a typo in the “The Bad: Type Inference” section. As written, it is:

val nums4: List[Double] = List(1, 2, 3) // compiles

val nums5a = List(1, 2, 3)
val nums5b: List[Double] = nums4         // fails to compile

I believe it probably should have been

val nums4: List[Double] = List(1, 2, 3) // compiles

val nums5a = List(1, 2, 3)
val nums5b: List[Double] = nums5a         // fails to compile

or else I don’t know what nums5a is supposed to be there for.

Looks like a typo here: “In response, it was tried to put band-aid around it.”

All aboard the follow train - https://mastodon.social/@mulander

Something that I think would fit the federated model well, if @jcs wanted to do it (or let someone else do it with the domain), is if there were a lobste.rs server. In addition to being able to follow individual people who use any federated server, the client also supports viewing a global firehose (all federated servers) or a local firehose (just this server). The latter, on smallish servers, can provide a kind of IRC-like community, while also interoperating with the broader Twitter-like usage.

I think people are still working out what the social configuration of a federated system would look like, though. Some tech exists, but a lot is still up in the air.

I’m https://mastodon.social/@stevelord if anyone wants to follow me. Mostly posting AVR development and security stuff.

I’m there at @NinetyNine.

I’m there at pnathan.

My Twitter tends to be a blend of liberal retweets, bad jokes, and occasional tech remarks.

I also have some kind of other gnu social account I forgot somewhere, but it wasn’t interesting enough there…

I’m there, https://mastodon.social/@balrogboogie

That last largest group running a “IN RUST WE TRUST”-viral thingy was The Register. What should we do in this case? They are not “the Rust community”. There’s a notable bunch of people who never tried Rust in practice who root for this. It’s the more annoying part of my work to them that doesn’t make any sense.

You may note that the Rust project itself takes a very concious non-agressive stance on this issue (putting down other peoples work is generally frowned upon). We cannot do much more then this.

Re-implementations are obviously an interesting thing, but Daniel puts it right: he’s the maintainer of curl, not of of a curl-compatible library. He lays out the practical points very right. He also welcomes re-implementations in that post , which would be the very FOSS way.

Also note that he literally mentions Rust once, in the intro, I don’t think that’s his beef.

The kitchen sink, I’d rewrite though. Mine’s leaking again.

The nonce does not necessarily have to be randomly generated, and in fact it can have some semantic meaning if you want it to. For example, in “Practical Cryptography,” Schneier and Ferguson suggest using the message number plus some additional information as a nonce, assuming the messaging system has the concept of a message number. The most important aspect of a nonce is that it is used only once (hence, “Number used once”), and does not necessarily have to be high-entropy. If you want it to have some kind of meaning, then having the crypto library choose it for you is not always what you want.

He does.

From the post:

Crucially, the Rust compiler will verify that all callers of the getter prevent the returned reference from outliving the X object.

It doesn’t get much stronger then “crucial” when it comes to explaining a central point.

If you can, please see my response to @azrazalea. Rust strings are UTF-8 encoded, which means we give up fast & easy substring indexing, but the rust devs have decided that the gains are worth the losses.

Taking a substring in Rust by byte ranges is simple. If s is a String, then &s[i..j] is a &str substring of s from bytes i to j. If either i or j aren’t on a valid UTF-8 encoded codepoint boundary, then the expression causes a panic.

Doing this by Unicode codepoint index is generally considered an anti-pattern and something you should try to avoid. Both Rust and Go leave this type of slicing/indexing out of their standard library, so Rust is not alone in this. But if you wanted to do it, the way I’d suggest would be to get the byte offset of the corresponding codepoint, and then slice it that way. You can get byte offsets by using the s.char_indices() iterator. For example, s.char_indices().nth(5).unwrap().0 will give you the byte offset of the beginning of the 5th codepoint.

The reason why this type operation is not something you should generally do is because “Unicode codepoint” isn’t necessarily “one character” from the perspective of humans. A better approximation of “character” is a grapheme cluster, as defined by the Unicode standard.

As I see it, there are two good reasons to make this operation very explicit:

1. To give you appropriate pause that maybe it’s not what you want to do.
2. To make the performance costs obvious. Slicing by bytes is O(1), but slicing by codepoint is O(n) given how Rust represents strings internally.

it just felt like an extreme solution to something that the standard library should be able to solve

I’m a beginner/hobbyist in rust, but from what I understand their philosophy is to have very very little in the standard library and for you to pull in a dependency for many things that other languages have in their standard library.

In addition, strings are indeed just bytes in rust but from what I understand they went that way to avoid setting a “blessed” encoding for the language. Since they are just bytes, libraries can implement UTF-8, UTF-16, whatever support.

As far as unicode support in standard library, the situation isn’t that great with programming languages in general. I don’t see rust as much of an outlier.