It's great that LLMs provide opportunity for non-software engineers to make tech products, but I wonder how those "vibe-coded" products will fare when faced with actually maintaining the code (and also accounting for tech debt..)
Look at your tech stack, go down until you come to the level where things "just work". This is where the maintained software begins. The stuff you fill your docker base images with.
Feel free to judge for yourself what I am. Started in civil engineering, pivoted hard 6 months ago. That gave me a leg up in UI/UX, design experience, all that.
> faced with actually maintaining the code (and also accounting for tech debt..)
I guess they'll learn it as they come across it? "Oh Claude, my code is almost like a plate of spaghetti, how can I make it easier to add new features without breaking something else?" "Dear user, here is what technical debt and unit tests mean: ..."
Besides, all of us self-learned programmers mostly learned about those things the hard way as well, by experiencing the real drawbacks of not caring about such things until too late and stuff is already up and running with real users.
TypeScript & Rust don't "look nice to work with" because they force you to write maintainable code that doesn't just stop working because of a random runtime error. In my opinion, Go looks nice to work with but actually is a hidden monster full of footguns.
Curious to read that because I’ve always had the opposite opinion of the above:
Typescript looks nice to work with but the tool chain is horrible (this isn’t really Typescripts fault though, more a synonym of it having to compile to JS).
Go looks horrible to work with (too simplified syntax) but is actually really nice because the tooling is (mostly) spot on and it’s simplified syntax weirdly helps with maintainability for large projects that have evolved over multiple years.
I guess this just goes to show how much personal preference can be a driving force behind our platforms of choice.
> Typescript looks nice to work with but the tool chain is horrible (this isn’t really Typescripts fault though, more a synonym of it having to compile to JS).
It's not even inherent to TS that the toolchain must be a morass of moving parts and multiple config files, as shown by Deno in contrast to Node.
The constant incantation of if err != nil is bad for my aging hands and frankly hurts even more when you see Rust's single-character error marshalling using ? operator.
I have aliases for these kinds of general things (in vim) for most languages i use. Eg. if im inside a typescript file i have a mapping produces if ($obj) { $ } and i tab to enter the next "$" to insert the correct things.
The same goes fo Go. I have a mapping for if err != nil { ... } and the cursor is places inside the block.
I dont understand why people dont use this kind of thing for the most common programming constructs.
I would suppose they do and are free to do it - however, liberally having to spread it all over the code hurts readability. I'm sure people can say in response to that after a while you stop noticing or that their favorite IDE can collapse it and so on. It can be excuses all the way down instead of admitting that it is a shortcoming of the language.
You say it hurts readability but most of the time I want the unhappy paths to be visible.
Coding software that works when conditions are met is easy. Coding software that works when things break is hard. So I want error handling to stand out because it forces errors to be handled visibly and properly.
All too often I see Python programs drop to a stack trace under normal execution or JavaScript return cryptic errors that don’t mean much to anyone bar the core maintainer. But I seldom see 3rd party Go software bomb out in quite the same way. And I think that’s in large part because Go doesn’t try to hide errors away as an inconvenience that we shouldn’t be looking at.
So I’ll agree Gos approach is ugly. But sometimes good software does just look ugly. And the way I see it, it’s the quality of the compiled software that matters more than the beauty of the combination of characters that built it.
I am not questioning it's effectiveness. I have written Go code that is chugging along without issues in Production. My point is ergonomics and effectiveness are not mutually exclusive - hence the example of Rust's ? operator - effective and ergonomic (Rust also has issues with difficult to read lifetime+trait annotations).
The sad part is that people have been talking about this for years but Go team stubbornly refuses to make error handling more ergonomic.
Most of the stuff on there is just talking about general programming mistakes. Eg overly nested code is a problem a developer can make in any language.
Sure there are some Go specific stuff in there. But the whole thing reads more like someone preaching an irrational hatred for something rather than a fair breakdown of genuine footguns.
The issue is you need to explicitly recover each goroutine just so a nil dereference or a panic from a library you have no control over doesn’t bring down the whole application. Maybe this is the way it has to be, but it is a little known fact that might bite you.
The only time a library should be panicking is if they’ve reached a state they cannot continue from.
I’d be interested to know which libraries you’re working with where this has been a problem because I’ve only ever experienced one occasion where a 3rd party library panicked unnecessarily.
Simplified syntax helps with maintainability for large projects? You're talking about a "modern" language which had no generics for the better part of its life? The language filled to the brim with "if err != nil"? Go is horrible to work with.
Exactly, Typescript doesn't stop working because of random runtime errors, it stops working because you didn't update the toolchain tangle last Thursday and then some configuration file got out of whack with the tsc defaults ;-)
Technically TypeScript doesn’t force you to anything other than writing valid JS code. Its design was great for wide adoption but also suffers from the JS part.
While Typescript has the gaping hole that is typing external data. Your code can't enforce that in TS, but in Go you're forced to.
I do admit Go has an easily found foot gun: nil pointers. It's a small one though, in comparison to the original problems with nil pointers. More stubbing your toe than shooting your foot.
I wonder if there is something like this but open-source, so I could customize this. I'm looking for a tool to solve UWB positioning (for indoor navigation) - to be able to know where to optimally place various UWB anchor points.
That's on the companies for structuring their interviews like that. Actual technological competence is not measured, only skill in algorithms and data structures, 75% irrelevant for the job..
Impressive! I'm wondering if something like this is possible with other models, because of Gemini's extremely large context length certainly helping a lot with parsing such large documents.
I'll add another analogy of my own: "guy harvests his own ice, is mad at others for buying it from the store"
He is mad at others using AI on his favorite blogging website. I think it is an insult to himself, because most AI produced articles etc. are unreadable and full of useless filler information - I think the guy can do better.
Ex Shazam tech here. The signatures that the Shazam app sends are very small, so bandwith costs should be minimal. Of course, I speaking about the technology of my day 2001+, so times may have changed
Some phone plans like Google Fi will give you a data only sim card for free. It ends up being totally free as long as you have unlimited data plans. I use my old phone and a data only sim card for random projects.
I did some measurements on shazam and it seems to send about 7kb/minute, which corresponds to 300MB/month, i.e. no big deal. I suppose it helps that shazam was designed in the age of expensive bandwidth.
I've learned when setting up a family plan that depending on how many devices you already have (my wife and I each had 1 phone and 1 apple watch) we could get an extra line with unlimited data for functionally nothing. (The sim's sitting in my dashcam right now, been silently plugging away for months)
I like this! I always carry a screwdriver and various kinds of cables (along with my laptop) to school/work. Makes me think I should actually make a tiny toolkit out of it!
Not only that, but also hating on memory safety (for no reason at all) is just dumb. Most of his software is just simple projects, except maybe this, it's definitely not something I'd use in my day to day life.
My opinion on him is the same as my opinion on Terry Davis (if he would contribute to Linux (or other FOSS projects, instead of making his own useless TempleOS), he would leave a way better legacy)
I agree with your sentiment - and I apologize, I've since revised my comment.
Hating on memory safety as a concept is pretty cognitively dissonant for a programmer (and in this case [& many others], cognitive dissonance is a sign of some underlying mental illness). Memory safety is something a programmer should strive to achieve 100%.
Not only that, but static typing is absolutely unrelated to memory safety. (How can you even compare these two concepts???)
Depends on the use case, while you care about it when writing software for use on modern systems, low level programming on something where you can have unrestricted access to, for example, all of its 1024 bytes of address space at once can be fun too
But of course appreciating this doesn't equal "hating memory safety"
He's conflating memory safety with languages that provide memory safety (by which I think he means Rust, as that's another thing listed in his "disliked" things list) - that's what I feel is the dumbest about this. For me, this seems like the most of his code is riddled with use-after-free, double-free, not freeing etc. bugs. He may be intelligent, but if his intelligence goes to no use (besides making random C side projects..), it is not worth it. Also he claims he was a member of Mensa, no comment on that one.
