TehPers

But this case is bigger than JavaScript. It’s about whether trademark law works as written, or whether billion-dollar corporations can ignore the rule that trademarks cannot be generic or abandoned. “JavaScript” is obviously both. If Oracle wins anyway, it undermines the integrity of the whole system.

If the law costs $200k to enforce, then the law already doesn’t work as written.

Anyway, good luck Deno! We’re all hoping you win this.

Storing UI assets in a database is unusual because assets aren’t data, they are part of your UI. This is of course assuming a website - an application may choose to save assets in a local sqlite database or similar for convenience.

It’s the same reason I wouldn’t store static images in a database though - there’s no reason to do so. Databases provide no additional value over just storing the images next to the code, and same with localizations.

User-generated content changes things because that data is now dynamically generated, not static assets for a frontend.

I know I probably sound like an ass but it really is that bad

Nah I work in shitty codebases on a regular basis, and the less I need to touch them, the happier I am.

With regards to other localization changes, it’s not important to localize everything perfectly, but it’s good to be aware of what you can improve and what might cause some users to be less comfortable with the interface. That way you’re informed and can properly justify a sacrifice (like “it’d cost us a lot of time to support RTL interfaces but only 0.1% of users would use them”) rather than be surprised that there even is one being made.

Also, user-generated content explains why these are in a DB, and now it makes a lot more sense to me. User-generated translations used as-is makes more sense than trying to force Project Fluent (or other similar tools) into it.

Localization is a hard problem, but storing your translations in the DB is a bit unusual unless you’re trying to translate user data or something.

I’d recommend looking into tools like Project Fluent or similar that are designed around translating.

As for the schema you have, if you’re sticking with it, I would change the language into an IETF language tag or similar instead. The important part is that it separates language variants. For example, US English and British (or international) English have differences, Brazilian Portuguese and Portugal Portuguese have differences, Mexican Spanish and Spain Spanish have differences, etc.

Using an ID instead of the text content itself as part of the PK should be a no-brainer. Languages evolve over time, and translations change. PKs should not. Your choice of PK = (TextContentId, Language) is the most reasonable to me, though I still think that translations should live as assets to your application instead to better integrate with existing localization tools.

One last thing: people tend to believe that translating is enough to localize. It is not. For example, RTL languages often swap the entire UI direction to RTL, not just the text direction. Also, different cultures sometimes use different colors and icons than each other.

it is the same code as you produce manually.

LLMs do not create the same code that I would, nor do they produce code at the same level that I would. Additionally, LLMs are not deterministic (normally - there are ways to manually seed some but it’s rare). Determinism has a very specific meaning. Compilers supporting reproducible builds are deterministic. LLMs producing a different output each time are not.

it is a task of a programmer to review it before publishing it.

Tell that to my coworkers. It’s honestly insulting the code I have to review and contribute to. Having used these tools myself, I’m better off writing the code myself.

Currently everything on the Internet is assumed to be free.

This isn’t true at all. Content on websites is protected by copyright laws as well.

As a Rust dev who has to target Windows, more support for Rust from MS is very relevant and important to me. And I can’t imagine I’m alone here.

Maybe you mistook this community for !opensource@programming.dev?

It’s not open source? The repository doesn’t seem to include the Rust source code.

Being closed source, I have no reason to believe it isn’t malicious. Open source means auditable. Closed source means “trust me bro”.

Edit: nevermind, I think I found the right repo. The package links to another one. Might want to fix that. Also, your profile on GH says it’s still closed source.

Mentioned this to the other commenter, but this doesn’t use the type system to enforce the mutual exclusivity constraint. In Rust, the main way to do that via the type system is through enums.

This doesn’t represent the mutual exclusivity through the type system (which is what the article is all about).

I love clap and I use it a lot, but the only way to represent the exclusivity through the type system in Rust is through an enum.

I like the concept, and it’s great in TS. Unfortunately, not as doable in other languages.

I’m a bit curious if it’s possible to extend clap to do this in Rust though (specifically mutually-exclusive arg groups).

That’s not an alternative, it’s removing let-else entirely. It’s equivalent to this:

let i = if let Some(i) = opt_number {
    i
} else {
    return 0;
};

let-else is specifically a feature that allows you to use a refutable pattern to deconstruct a value by providing a diverging else branch.

Their suggested replacement is closer to C#'s is keyword:

if foo is Some(foo) {
    // ...
}

The issue here is that we still have let-else, which can’t be translated as easily:

let Some(foo) = foo else {
    todo!();
};

Or both? Functional languages are good to be familiar with, but so is Rust’s strict ownership model. Both lead to better code in all languages.

Next.js is a highly opinionated framework. “Our way or the highway” is what should be expected going in. Good luck if your requirements change later on, and I hope your code is transferrable to a new framework if needed.

Unfortunately, I have never need to follow “our way” because my projects are more complex than whatever basic blog setup they document. I always end up just building my own stack around Vite. I’m also not much of a fan of fighting against my tools when what I need isn’t something the tool devs already thought of.

I completely forgot that unit structs/variants define their own associated consts. I wonder if in patterns the type can be used instead of the associated const though? That might resolve a lot of the headache. It’d mean changing the way the ident is resolved to looking in the type namespace though.

const <block> already works as a pattern I believe? That could be used instead for constants.

Literals would always work in-place as constant expressions.

Interesting perspective. Not sure I agree with most of the suggestions though.

Some of the earlier ones remind me of C#'s records. Were they inspired from them?

Some of the later ones just feel like Go to me.

I like the idea of dropping syntax for ranges. It does feel like the syntax just leads to confusion.

Named parameters are problematic because of parameter names becoming significant to the API. See Python’s * and / in parameter lists (like def foo(a, *, b) for example).

This. It’s just like “this dude is cool” and some fun Q&A and circlejerking, which is fine, but he probably should not be used as a credible source for understanding younger stuff.

Nah I ignored that because responding with just a number is boring and leads to no real discussion. A poll would have been better if that’s what was needed.

As in using consts (or variables you think are consts) as refutable patterns? Yeah this was an oversight I’m sure.

One option is an edition change requiring a const keyword, so

match foo {
    const BAR => {},
    baz => {},
}

Right now they use a lint to try to warn the dev though.