This makes a lot of sense if you consider that it is consistent with the rest of the language. It is one more way to set up tripwires in your code to to catch your own programming errors. Similar to using asserts in your functions to vet input and output.
I use Array list a lot so excited to add this throughout the code to harden them.
I can imagine this is not everyone's cup of tea, but then you probably also wouldn't enjoy any of the other explicitness.
That's easily the strangest self-destruction I've ever seen. "Skewed gender representation"? Not sure how that matters or what the intended effect of salting the earth here was.
It’s a complex topic that’s usually treated with a lot of bias and very little nuance. Most mental health issues tend to be treated as something to be removed whereas in the case of gender dysphoria, the empirically proven treatment is (of course treated case-by-case) to transition. Similarly, dysphoria (when being trans, most commonly) is often treated as some form of perversion or threat. It’s complicated.
people think other people are 'toxic' for the silliest of things most times; and this person is saying some maintainer is toxic to put it out there but provides no information as to why.. so i figured my context is as good as theirs
That made me question who this is for. Looks like it's only for racing bikes that have taken off the rear mudguard. And those bikes are typically used to exercise..
Which makes me wonder about the cleaning after it rained..
It depends what you use them for. I use one as my commuter. Most days I ride it with the motor set to just overcoming the added weight of the system plus my heavy backpack. That is uphill, against the wind both ways, of course. I only use more engine power when I have a bad day or am just done pushing hard. But I am on my bike, not in a car. Life is good.
On the flats, I get no benefit since the motor cuts off at my normal cruising speed of some 20 mph. It just feels like a solid bike in that mode, a bit heavy, of course.
I have taken it on a few regular non-commute rides as a test and must say it did not make me lazy or weak, or suffer less. Easy of riding is not me. In the end, it is the rider that makes the ride.
We get old boys in our cycling club that want to keep going out on the Saturday social ride.
I don't have a problem with them riding an eRoad bikes, I like that they can keep coming out with us, but like you say I wouldn't want to ride one myself.
Only commuter and bikepacking bikes have mudguards, almost nobody puts one on a mountain bike or a proper road bike, regardless of whether they’re electrified. This looks like it’s more for these “sporty” categories of bikes.
My experience is that if there’s water and mud on the ground, a fender doesn’t help much. Especially on a higher travel mountain bike (I ride 150mm of travel front and back) where you can’t get it close enough to the tire. After a while it turns into a gunked up rattling sagging mess. I’ve tried a few and ultimately stopped trying, even on an XC bike. I don’t meet people using them either.
If you see someone with mudguards on a road bike it's a sign they're a proper cyclist.
I don't think you're allowed to entry audax events without guards and you definitely won't be allowed on a club run without them. Getting a face full of oily road water for the guy in front is not exactly fun. Even small clip on "racing blades" will get you a sniffy look.
You must be from somewhere where winter means rain vs. large amounts of snow. I can see if you're doing a road ride with a group (where they often run tight) they'd ask for fenders. Here a road bike would be useless once winter hits.
That’s interesting. Our winters are often wet and annoying. You don’t see many roadies out there before at least February. To be honest, I don’t think I’ve ever seen a proper road bike with mudguards in the wild.
I suspect people who are enthusiastic enough cyclists that they're doing 20mph+ club rides even in the winter have separate summer and winter bikes.
And yes, once your winter 'proper road bike' has mud guards, tyres with treads, and an all-weather-riding design people might start calling it an 'adventure bike' or 'gravel bike' instead.
What I've noticed in my area is that people just don't ride on rainy days. If I'm at work and it starts to rain, someone will offer me a ride. It doesn't occur to people that a bike can get wet.
Bikes are sold without mudguards, and the aftermarket ones are flimsy and don't fit very well. (The steel ones that came with my 1983 Schwinn frame being the exception).
"Who this is for" is the great un-answered question in American cycling. The reason is that our biggest untapped market is people who don't ride at all. The marketing looks like lifestyle marketing: Here's what's wrong with cycling and how we solve it. Here's what you will look like.
I remember many hikes in Snowdonia, the Peak District and a few in the Scottish Highlands in which those 62.5g Mars bars played a significant role in the nutritional planning and overall success.
By something that is going to replace my job by writing better code and shipping more features at a fraction of the cost, without asking for vacation? I don't know, boss; I'm also trying to understand why I'm tired.
We'll see about that, long term. The billions and trillions being wasted right now to get the foot in the door need to be earned back somehow at some point...
"Nice company you have there, totally reliant on our AI tech. Oh by the way we gotta increase the rent again."
Doesn't really make sense as there are already open weight models that are close to frontier models, and the compute to run them isn't outrageously expensive, and every indication that it will only get cheaper over time as has been the strong trend in terms of $/outcome.
Yes. Every great technology developed to date has been a net positive for the human race. Including the more controversial ones, like internal combustion engines or nuclear power. Why should AI be different? I think the critics always fixate on the negatives, but ignore the potential big positives.
Depends on your point of view. Has the web been a net positive overall? If your criteria is "instant access to any information" or "catalyze more technological progress" then positive, if your criteria is "young people's mental health" or "how easy it is to control the public's perception about a certain topic" then negative in my opinion. It's all relative.
Short form videos (tik tok, YouTube shorts, instagram reels)
Coming soon:
Deep sea mining
Some of these are not great technologies, you might say. Well if they're impactful enough to turn everyone I love into a phone zombie and make the political landscape violent and insane then that's enough.
30 years ago was the 90’s, when just about everything peaked.
The things I’d be truly missing from today 30 years ago, would be the advances in medicine really and the fact that we don’t have the ozone layer threat.
Most other things have peaked back then. Rising kids was definitely easier, and healthier.
There are many technologies that have not been a net positive for humanity. Leaded gasoline comes to mind immediately. For many other technologies it is also hard to determine because counterfactuals are hard to reason about.
Even then past performance is not an indicator of future results. Just because you think internal combustion engines were a great invention, doesn't mean AI cannot be bad for humanity.
I wouldn't say that leaded gasoline is a great technology like AI, it's a pretty niche tech. Gasoline in general is comparable to AI, and the pros of that outweight the cons. Modern civilization would be impossible without gasoline.
>Even then past performance is not an indicator of future results.
It is not perfect or guaranteed, but it can definitely be an indicator. Technological progress is the main reason for the massive standard of living increases that we have witnessed in the last ~200 years. If someone wants to argue that this trend will stop or even reverse, they need very strong arguments, IMHO.
> Gasoline in general is comparable to AI, and the pros of that outweight the cons.
This analogy is great, because your grandchildren will probably not consider gasoline to be a great technology, they'll consider it the thing that caused the wars and the famines.
> This analogy is great, because your grandchildren will probably not consider gasoline to be a great technology, they'll consider it the thing that caused the wars and the famines.
They will also realize that industrial civilization enabled by gasoline was a necessary step towards the renewable energy utopia they are living in. Developing advanced technology takes a lot of energy.
I am only considering great, consequential technologies because AI is such a great technology. Comparing it to some niche techs would result in false analogies.
> Do you have an argument why "normal" technology can be good or bad, but "consequential" technology is always good?
Because consequential technology has many applications in diverse fields. And applications of technology are more often beneficial than harmful. So if the technology is broadly useful, in aggregate the beneficial applications will outweight the harmful ones.
Transportation fueled by fossil fuels is the foundational technology of modern civilization. It is comparable to electricity or the printing press. AI will be like this too in the future.
You're arguing against a point I never made. I agree that AI will be an important technology. I also think that it'll affect people that have to work for a living negatively (both in the short-term and assuming there is no foundational change in the structure of society, also in the long-term).
A common thing is to lump things together like a tech tree. Is it possible to conceive of a world where nuclear power is invented but not nuclear weapons? Combustion engines but not let everyone have a car and then cause cities to be planned around cars?
we'll be better off - assuming we'll generate revenue on our own. LLMs have opened up an enormous new frontier of micro-SaaS opportunities. One person can now build what used to require a small team.
The real problem is zero-sum work, especially when the only moat was knowledge asymmetry that is now public knowledge.
I'm in agreement with your claim, though if you recall some of these micro SaaSes went hyperfocused on niches. The value proposition is then smaller, with larger data liability than with some behemoth's of SaaS.
Though for the later ones, one might also ask themselves if they are worth their cost when using 20-30% of provided functionality.
This will also make it harder to compete because it holds true for everyone, not just you. I am already, this year, seeing vibe coders put out some decent stuff on App Stores but the problem is marketing it. You no longer automatically stand out just because you have a cool app. You may not even do so with reasonable early traction via social media. And then what? Throw venture capital onto the problem? In an AI saturated world? Really?
Also the drive to innovate goes down. It took weeks for the creator of 2048 to make a low quality clone of Threes. Now people can make relatively high quality ripoffs in days, even hours.
Working with AI has been way more tiring than just working. Sure the productivity is up, at the cost of having to keep up many thought threads, having no calm moments, and needing to consistently dig into large unknown code cases to find weird bugs.
I’ve been on leave for a month, and am super excited (/s) to re-learn everything because all the tooling and ways to prompt “correctly” will have also changed.
Because the ability to create software has little inherent value to me and is only valuable to me because it allows me to earn enough to make this life somewhat bearable.
LLMs that can build a computer vision pipeline are a direct threat to my ability to sustain myself. At the same time, being able to prompt an LLM to build a computer vision pipeline doesn't really positively affect my life at all, because personally I don't care that much about computer vision pipelines (or frankly, any software).
> The ability to create software accelerates technological progress, which has direct and indirect benefits for everyone.
It has benefits for people with enough leverage (money and formerly labour) to obtain those benefits.
> It is true that competition could have short-term negative effect on people who sustain themselves by creating software, though.
I'm guessing that even if the unlikeliest of all unlikely things does happen and we all live off of some UBI some day, the short-term negative effects won't be "short-term" in the context of a human life.
> It has benefits for people with enough leverage (money and formerly labour) to obtain those benefits.
That's pretty much everyone. Even poor people benefit from technological progress.
> I'm guessing that even if the unlikeliest of all unlikely things does happen and we all live off of some UBI some day, the short-term negative effects won't be "short-term" in the context of a human life.
That depends on the pace of technological acceleration. It could be just a few years, or a decade. Which is why I am a pedal-to-the-metal accelerationist. The quicker we get through the short-term negative/turbulent phase towards the long-term positive phase, the better for me. If reversing is not possible, then going quicker is actually better than going slower. Let's get this shit over with.
It’s unlikely to stop here. Today is a proprietary 5T parameter model, tomorrow it’s 5 100B parameter models that each specialize to specific applications and you can run them on your phone. The direction of travel is not like you think. The real victim will be medium to large software companies that can no longer rely on the difficulty of reproducing or maintaining or hosting their software as moat.
> This is just so weird to me, because I would say the same about Zig.
I think you missed his point. He's arguing against homogeneity of (cyber) culture. For example, programming languages that promise to do everything.
Rust fanatics indeed can be a bit like that. Every time I see a thread here about someone building something in Zig, they storm in and start arguing 'why not rust!?'.
The fact that you don't like the zig community is healthy and not weird. Don't worry about it. You don't have to like everything and you can disagree on taste.
Sounds like you've never built something. Even with small products you have to keep correcting yourself as it's hard to foresee how each component interacts.
Now try building a self-hosted C replacement lol
Programming language development have been happening for 60 years. We have tonnes of prior art, we have a rich history of experimentations. If you're a language developer that doesn't study the history, and keep making the same mistakes that other people know to avoid, I don't respect your product.
Rust language mistakes are understandable, because they do a lot of novel stuff so they encounter situations that no one have seen before. For the three languages that I mentioned, their mistakes are fairly well-known errors with obvious consequences. How hard was it to foresee that lacking generic in Go is a mistake, when the language was created well after Java had generics?
Not being sarcastic but genuine because I do not know: are there any previous languages that have a build system like Zig?
I found really cool that you have a bunch of options to configure compilation of source code itself. Not just the compiler optimization but you can automate all kinds of things: https://ziglang.org/learn/build-system/#build-system
Languages, no. But for language-agnostic package managers, Nix/Guix and Gentoo are similar.
Sadly, Gentoo is not great for managing per-project dependencies in the same way as is done by npm, pipenv, etc. Nix however works great (if you can stomach its stdlib).
Ironically Rust (hence the name) was originally billed as the language that did nothing novel at all, but just productized a bunch of concepts that were already well understood in the PL field :)
I think that a programming language — much less a programming language _ecosystem_ — is such a large space of decisions that statistically you're inevitably going to let a few of them slip. And even (as in Rust's case, initially) if you don't aim to do anything new, the combination of the interactions between features and the ways people want to use your language culturally can land you places you never anticipated when doing the initial language design. I don't think anybody in the early years of Rust could have anticipated how async would look today, for example, and IIRC Graydon Hoare still doesn't like where it ended up.
Then, there's the old software adage that the right decision for one level of adoption doesn't necessarily translate to another level. Because it's so hard to predict the impact of early decisions, early versions of programming languages are basically prototypes: your aim is to get out enough of the core differentiators of the language that people can start playing with it and _imagining_ what it will be like to work with the final thing. Part of that involves making the barrier to entry as small as possible (e.g. bundling a full build system into the precompiled compiler executable) but it also implies that you don't want to spend more time than necessary on things that work the same as other languages. If you can see the ‘obvious omission’ in the language then that means you can already imagine how it will work when that thing is implemented! As an implementor you can always flesh it out as you approach 1.0, or, if the right thing to do is so obvious and you have an enthusiastic open-source community, you can just wait for the community to build it for you.
Go's generics case is a bit different, I think. I don't claim to be an expert here (I haven't followed Go development much) but as far as I understand it the omission of generics from Go was a deliberate ideological choice: they hoped to get by with the absolute minimum of generic functionality, and the experiment was how little they could get away with and still have it adopted. (Unfortunately, I think the experiments Go was trying to run were stymied by Google and Kubernetes throwing their weight behind it, which led to a pattern of adoption that had little to do with the language design itself: we may never know what would have become of it if it had been left to stand on its own.)
Creating a part of C compiler, most frequently a working optimization pass, is a regular assignment. The entirety of C compiler is too large to give it as a student assignment.
Depends which ISO C version, C89 is quite doable, and clever students might dust off a copy of "A Retargetable C Compiler:
Design and Implementation" or "Compiler Design in C" as starting point.
Back on my day, high school students would learn C on introduction to programming classes, while 10 year olds were able to write Z80 or 6502 Assembly and some of them would go on to create the games industry we have today.
I guess education system went downhill since then, which I guess it is kind of true, given the poliferation of header only libraries, as if C was a scripting language.
If you are going to write your own allocators, I think it doesn't matter too much which Zig version you are on. Most drastic changes since 0.15 are done to the standard lib and the language itself stayed pretty much the same.
That said, they did clear a lot of bugs which I would never run into, because I make relatively simple programs. But with writing things like allocators, you might reach those edgecases a bit sooner.
I use Array list a lot so excited to add this throughout the code to harden them.
I can imagine this is not everyone's cup of tea, but then you probably also wouldn't enjoy any of the other explicitness.
reply