TechNom (nobody) @ technom @programming.dev

Posts

0

Comments

160

Joined

2 yr. ago

Not to mention the fact that they trained copilot using code on it, without informing or taking permission from the authors and they justify it citing fair use policy.

Neither has reached 1.0. They're perpetually unstable.

That being said, I still don’t mess around with rebase for anything

Rebasing has a worse reputation than it deserves. It's something you just get used to - just like how git use is, when you started using it. There are a couple of strategies to make it easier and less anxiety inducing:

1. Before starting a rebase of a long branch, create a new branch. That way in case you seriously mess up, you can just delete the rebasing branch and rename the old branch to restore everything (you can usually get away with rebase abort. This is just added safety). Even in case of a successful rebasing, you can just keep the backup branch around, as a faithful record of actual development history.
2. Do only one (or max 2) operations in a single rebases. Do this over multiple rebases to get what you want.

After a while, rebasing becomes as simple as commit or merging.

I too use Rust for what normal people use shell scripts for. But I have a feeling that Rust is falling into the same trap that other languages with similar easy dependency management fall into (Python and NPM are good examples). You end up with a dozen direct dependencies and hundreds of indirect ones with dozens of levels of hierarchy. C and C++ programs have fewer dependencies because each additional one adds more headache for the developer. Drew Devault's Hare language is giving language repo and package manager a skip for the same reasons. And I'm starting to think that he may have a point.

Exact same story here. Bash -> Python -> Rust.

Generally speaking, people should settle on a compiled language if they can. They can iterate as fast as interpreted languages these days.

Edit: If you want to try something different in scripting, try the execline language. Its interpreter processes the script and exits immediately even before the script execution begins. Traditional shell interpreters (like bash) stay active till the entire script is finished. Execline achieves this by a clever chaining of Unix execs, forks and variable substitutions. This makes execline scripts lighter (useful in embedded systems), more secure and less error-prone than traditional scripts. The downside is that writing them will feel a bit weird - since the fundamental paradigm is different from regular shells. However, that will be a refreshing change if you're someone who likes to experiment and try new things.

What makes Perl or Raku interesting? What are some applications where they are the ideal languages?

The problem is everyone shilling someone else's personal opinion as if it is a fact. I use Rust. I have no difficulty iterating or refactoring (did that just now). Granted, you are under no obligation to take my word. But why would someone's blog post be more authoritative than my own experience?

Somebody did that on HN. They seemed receptive to it.

Epilogue: She got what she asked for and completed the work 5 years ago.

I have been programming in Python for nearly two decades now. This is the first I'm hearing about the Optional improvements to Python's type hints/annotations. Thanks a lot for this. I'm going to take a re-look into type hints.

As for Rust, recall that Result is also a very similar union type.

I'm aware that Rust enums, including Result, are tagged unions. However, my understanding is that it's not like that in Python. Python's duck typing is enabled by typing the values, rather than the variables. A variable can point to a value of any type. Am I getting this wrong? Or is Optional different somehow?

I don't know how useful Options are in Python, with its duck typing. Python had something similar to Option::None all along - None. It's possible to use None in Python is very idiomatic and surprising ways. Rust's Some and None are tagged unions. And Rust forces you to address them - unlike Python.

a misleading statement at best

The monstrous thing is locked down tightly on a hardware level that even they can't repair it. And the hoops you have to jump through to install a software is getting ridiculous by the day - I'm saying this from my unfortunate opportunity to use a Mac. And you say that my statement is misleading? It's true what they say - you Mac fanbois have deluded yourself out of touch with reality.

Did you miss the part where I said they use the security argument to lock down the device and restrict the user? In addition, Linux distros in their default configuration may not be secure - but there are plenty of packages that can secure it down to a deep level. It just depends on the user's threat level assessment. That military establishment vs homeless tent analogy is just pure hyperbole and FUD.

I strongly disagree about generics / syntax. IMO they’re fine and you’ll learn to love them.

True! Rust's design is very orthogonal. The generics, lifetimes and other similar features work very well together.

The main issue for me is the syntax, specifically generic types, traits, and lifetimes.

After working almost exclusively with Go for years, reading it seems unnecessarily demanding.

Like someone else said, this is a complex subject to answer. The syntax looks perplexing and frustrating, until it doesn't. These days, Rust syntax is nowhere in my thought while coding - it like when you drive, you are thinking about where you want to go rather than about manipulating the controls.

Why should I learn and use rust?

Rust''s rules are about enforcing memory safety. But it also ends up forcing you to write better programs than what you imagined you could. It's hard to describe that feeling - you have to experience it. That alone is a good reason to learn it - even if you end up not using it in the future.

Rust's unique design also leads to many design patterns not normally seen in most other languages. That's also worth exploring.

I have fallen in love with Go. It feels like ‘home’ to me

That's a perfectly good thing. It's hard to find that sweet spot. However, don't let that stop you from exploring the alternatives. You might find ideas you could use in Go.

Most of the “automation” work that I do involves parsing data with regex, restructuring the data, converting the data into a modeled format and transforming something with that data.

These are the highlights of rust - regexes (the regex library that powers ripgrep), serialization/deserialization (serde, nom, pest, capnproto, etc), data manipulation (too many. perhaps apache arrow deserves a mention), etc. The language is designed for this sort of stuff.

Has anyone used Rust for network automation tools?

I'm in the same boat as you. I use python to manage an LXD cluster. I didn't choose Rust because Python has an API binding, but Rust didn't. It wouldn't have been too hard, considering that the API is mostly just JSON.

With familiarity, can Rust’s intuitiveness match Python’s “from idea to deployment” speed?

Unfortunately no! (in my personal experience). I have been using Rust for a decade (since before 1.0) and am more or less comfortable with it. I no longer fight with the compiler as most beginners do. Still, the compiler complains a lot and you have to think about why. This is not bad, IMO - all that thinking make you design better programs. There is always a sweet satisfaction of writing excellent code when you finish a Rust program - probably the reason why Rust developers love it so much. But you have to sacrifice some speed for that.

Intuitiveness is also subjective. My introduction to programming and computers was from the hardware side - from ALUs, DRAM, hardware pipelining etc. Rust's rules are very well defined, but is obscurely related to real problems you encounter in the hardware. In other words, Rust rules look confusing at first, but it makes sense once you see the error messages. You know what problem could have happened on the hardware if Rust didn't stop you. It's as if Rust's simple rules magically cover the problems you dread on the hardware.

All this means that Rust is easy to grasp for people who are already using C - OS, game engine, web engine and embedded system developers. For others who are mostly used to GC languages, it's an uphill battle with the compiler, until some day it clicks somehow. With Rust, it's very important to start right away with the (c lang) memory model and Rust's aliasing rules.

Or should I only learn Rust if I intend to create applications that need tight performance?

I wouldn't say no to learning a new language. But I always recommend a few languages because they introduce a radically different idea. Rust is one of them. My rant above probably gave you an idea why I would recommend Rust. The first is that Rust forces you to design programs properly - even though the rules are meant only to enforce memory safety. Second is that Rust gets you very close to the soul of the hardware. Python and even Go has some opaque layers in between you and the hardware. With Rust, you'll get every opportunity to get the best the hardware can offer. You get the same in C and C++ - but they also allow you to screw up.

I use Rust for even trivial tasks where a shell script would suffice. Besides the language features, Rust has excellent tooling and a rapidly growing library ecosystem. In many ways, it's easier to package Rust programs than Python ones. So Rust will work for your use case. But if development speed is more important to you than performance, then Go (similar to Python), Nim (much more similar to Python) and Zig are probably better choices. Repeating something here - Go is designed for the web. Numerous web backends are already on Go. And almost the entirety of Kubernetes is written in Go.

You're right - though I don't know about the 'control memory' part. However, the other person is addressing the use-case of 'network automation', not of microcontrollers. There it really doesn't matter what the exact memory layout is, or if GC stops your job for a microsecond. Go is sufficient for that. Go is sufficient even for many web backends and network infrastructure. In fact, much of kubernetes is written in Go.

I use Rust for where one would normally use a shell script. But I have been using it for nearly a decade now (yes, I started before it reached 1.0). I have gotten used to the strict type system and even rely on it to write proper code. I also have a background in hardware - so much of it makes sense to me. Even so, I can't recommend Rust to a beginner who values productivity. Rust takes a lot of time getting used to. And no matter how you try, you will never be as fast as you are with python or go. It's not always bad considering what you get in return for the sacrifice. But it's better to set your expectations straight.

Sadly, it also suffers the same problems Nim suffers: dearth of libraries.

That might change once the language stabilizes. Imagine creating a library now and the language changes breaking it.

So many praises for Windows and Mac about 'premium features', 'corporate environment' and 'device support'. But not enough talk about how they treat customers like crap and cash cows. Windows is replete with spyware and ads. It doesn't respect the user's choices, like when not to do an update or opening the links with a browser of user's choice. Heck! Some versions don't even allow you to register users without a cloud account. And now they are taking definite steps towards ensuring that you can't do anything they don't approve - with TPM and pluton non-sense. Praising windows is like being in an abusive relationship and finding justifications for it.

Mac is on the other extreme. They lock down their platform more and more in every revision in the name of security. It's getting harder to side-load apps. Why? For security, of course! No mention of how security comes primarily from platform design. Then there is the hardware, where everything is glued, soldered, riveted, digitally locked, etc, etc. Any small issue, and it's garbage. Not even parts from another genuine Mac can be used. Macs also have the strange distinction of needing calibration and signing of any part that can be replaced at all. It's deliberately designed to extract more money from you and create a tonne load of e-waste (iWaste?). Mac fanbois have a habit of justifying it in the name of 'miniaturization' and progress. Honestly, that's just hand-wavy and completely wrong technical argument. And Apple says it is all for 'privacy' and 'security' while their actual reason is the pursuit of double-digit growth (not just profits). So, in effect, Apple is saying to their customers "Oh honey! You're are just too stupid to take care of it. So let me just decide for you" - all the while squeezing you for money. Does it end there? Oh no! They need developers to pay a yearly fee and want to take a huge cut from their profits. All that for "providing the engineering, platform and services". As if the exorbitant price they extract from their customers isn't enough.

The hardware situation on Linux distros and frankly even BSDs isn't as bad as it is projected by some. Most devices just work even on a live installation medium. Even Nvidia works. (Have you considered the possibility that if any device doesn't work, it's the manufacturer's fault and not the OS's? There are plenty of devices for which the community maintains the drivers, just because the device manufacturer isn't an utter trashbag). There are tonnes of games too - thanks to Valve and Proton. And as for the 'corporate env', you are probably just locked in or too used to them. There are users who have been on these platforms for decades now without complaints. And there are companies built entirely on them. Can you say the same about any of the company that makes your OS/devices? Is there one among them that doesn't use Linux or BSDs?

Look! I'm not claiming that everything is rosy on the Linux and BSD side of things. Sometimes you have to find an alternative way of doing things (there are plenty of options). Sometimes, you have to configure a lot. Sometimes, you have to carefully choose your hardware so that your life is easier with Linux and BSDs. But there is one thing they don't ask you to do- and that is to surrender your self-respect. You don't get treated like cash cow. You don't get spied on as if you are a thief. You don't get restricted like a school kid. You're not told that your choices are wrong. Your choices are not disrespected. You don't get treated like you owe them after you paid your hard earned money on the devices they make. Ultimately, it's up to you to decide if the little conveniences are bigger than your self-respect.

Source available