leecommamichael

I read the study. The wager is:

  $0.10 awarded for a correct answer

  $0.10 deducted for a wrong answer

  $0.00 (no change for a refusal to answer)

I am inclined to believe the effects of the study are real, but not nearly as pronounced as the data. If there were more serious amounts of money on the table, I think common sense would prevail.

You're getting downvoted because your argument is cosmetic, egotistical, and useless.

Ouch. (sincerely) I hate to think my ego might be so large and detailed that it could be so irritating to someone through such scarce writing. Are you certain you're identifying me correctly?

if I give 100 engineers your criteria and then ask them to categorize 100 different points against it, would give exactly the same results?

Fair point, I understand that things I find to be "unnecessary friction" were once very necessary, and are (not infrequently) still necessary today.

Systems programming lives and dies by the details you want to ignore.

I haven't really given you much to respond to, which is my fault, but I don't think you're yet identifying what I want to ignore, because how could you if I'm not specifying myself entirely? Frankly, I was being too casual with my discourse for many of the people responding to me, I see that now and graciously accept my downvotes. I'd rather have a good conversation than internet karma points, so here goes.

So let me box this in more. A lot of my students just want to get some practice with programming the computer. They want to learn some basic graphics, whether they're using the GPU or not. They want to be direct about programming the computer, and often want to use systems-languages but find C and C++ too difficult to use. It is now common for university students to complete a bachelor's degree while strictly writing Python. *This is the current against which I swim.* I do not think this is a healthy situation. I want there to be: more incentive for students to do "fine grained" (systems) programming. Ultimately, it needs to be more economically relevant _and_ to seem accessible to them. So, in my eyes, if enterprises attempt to use some of the "rounder" (less sharp) tooling *where possible*, students might think they've got a shot and can feel assured there's a point to putting in the effort to learn how to use things like pointers, allocators, profilers, debuggers etc.

I do not want C or C++ to die tomorrow, or next year, or next decade, but in my time writing these languages and their "successors" I do think there are enough meaningful improvements that we owe the next generation a chance to take ownership of something that seems a little less hairy-- even if it is so they can make it hairy and start anew. I simply want them to feel the responsibility and freedom of control.

So what are the improvements? Let's start with C. Let me preface by saying I am aware there are a few tools that are a "must" with C, otherwise you're going to get bit by things like integer conversions or memory corruption. Know your compiler-flags and tools like valgrind and you'll be okay. But what if you didn't have to learn that the hard way? Some of the new languages can put friction in the way of these mistakes, whether by way of incompatible numerical operations on mixed types, or various restrictions on what you can do with a pointer. These are small things, and I hesitate to list many more, but there are so many! I realize I won't be exhaustive enough for you, but we can take it further, sometimes bugs can be introduced via aggressive backend optimizations which operate on undefined/platform defined behavior. Again, in this case, there are languages which simply forego these optimizations by defining the behavior.

Again, I realize there are genuine losses due to these design decisions which I'm advocating for, and I appreciate the pressure you're placing against me to distinguish these from flaws. I don't mean to point at the inventors of the past and to say they just did it poorly, I simply believe the trade-offs are out of calibration now. e.g. C's pre-processor and linkage strategy is to write a bunch of little atomic things so that it all fits in memory. That is still crucial for a lot of the largest systems out there today, but for anything else PLEASE let me write something like `go run .` and be done (this is not an endorsement for Golang specifically.)

The point which inspired me to write any of this is this: the software we run could be faster and lighter if we know how to make it that way. I think C and C++ are good tools to make the absolute fastest and lightest software in a great many cases. Probably the best tools. But what about the people who just want to make a GUI application without learning the framework of the month, or the programming language of the decade? What if you want to know something you can use for the foreseeable future without investing the kind of energy it takes to be a discerning user of C or C++? We're missing out on better software because students are giving up on "finer" tools.

These are legitimate complaints, and I meant for "if you can afford it" to do a lot of lifting in my first comment.

I'm talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it's kind of a mashup of recent pop-culture things. I'm literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?

I started bowling in my teens and as a programmer have often wondered about how these things work, and have had a few opportunities to peek under the hood of the machines. Incredible stuff. Thank you for this work, I'll point my alleys to your creation when it's public.

If you're starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, whatever are better. There will be growing pains with respect to collective knowledge and performance, but they are surmountable.

Context: I am a programmer and educator. I am so tired of informing people of these minutiae.

The real problem lies at a more fundamental level. The holdover of borders from the X10 protocol is a mistake. Borders cause complications in the protocol, servers, and clients, but don’t provide enough payback to justify their existence.

We can’t justify removing borders from the X protocol, given the large number of clients that would need modification. However, future window systems should let clients deal with window borders. Programmers using X11 should take care when performing geometry computations.

I really like this idea. I was reading a post earlier about how Go generics are implemented, and how they're sort of leveraging root GC-types in the "runtime" to avoid the same bloat as monomorphization causes in, say, C++. I wonder how Solod will do that? I guess plain monomorphization? I guess that's fine since C compilers are so speedy.

What does your application do?

Yeah, I tried to just tuoch that because it is highly personal. I don't think I entirely understand the post's point about "inherent traits that don't depend on usage." All tools have these traits as well, don't they?

Yes, almost all work people share which seeks to measure the capabilities and differences of models needs to get more precise. We are clamoring to say something meaningful about these things.

Tokenizers define the alphabet on which the language model is trained. I don't want people to get the impression it's a module which can be swapped out or modified on its own. Alphabet size is a design consideration related to correctly encoding the training data.

k

I expected a blog on how to write a button using a graphics API and basic OS interface; but instead I completely mistook (what the comments are saying is) sarcasm as advice on how to program for the web. I'm not a web guy, so I'm not really even sure why this is sarcastic, isn't semantic web good? I can't keep up with the opinions.

I'm of the opinion that it can be a tool if used as one, but that most people are currently interested in experimenting with various sci-fi visions. I don't ascribe any emotion or judgment to that, either. We should be doing the things we're excited to do if it doesn't cause too much harm.

There are boring and reliable uses for these things, but then the wins are smaller, so they're not as worth talking about. We all want to say something insightful about the current topic of discussion, and per usual some of the worst behavior gets the most attention.

To add context to what I'm proposing, I think they're good for dealing with issues of scale:

1. search dense files for a precise thing

2. refactor from a "bad way" to a "good way"

3. generate short (<200 line) scripts *

4. getting started with third party SDKs *

5. generate alternative procedures/approaches *

The asterisks denote potentially faulty usage. Short scripts are great to have roughly automated, but as ever the risk with these things has been that they might grow into programs, and that's a poor foundation to build on. This is similar to my rationale with generating example code for unfamiliar SDKs; sometimes usage is not as simple as most guides on the internet, which means you get a sub-par result from the LLM. I think this is pretty much the case with things like win32 or AppKit programming in C. As for the final point, you've pretty much got to be an expert to avoid going through the trouble of entertaining poor suggestions; I find this to be the primary failure-mode of LLMs, they can waste your time.

So it's a templating language.

And it's not because he's cranky or something, he was holding out for something worthy to possibly use instead of C.

Good point.

Turned out to be Rust.

He was evaluating C++ in the 90's, you make it sound like he recently decided to write Rust instead of C. The reality is that Rust is allowed in limited ways into _some parts_ of the kernel codebase. Rust got so much further than C++ ever did, that is true.

Absolutely yes 100, I've been saying this for like a year now! Even things that were good and usable before are getting really weird quirks.

How you distribute software is a consequence of the user’s relationship with it. If I “take a number” online for the License Office before driving in, that most certainly shouldn’t be an app. Installing is harder than “taking a number.”

Apps are great for tools which the user needs to depend on regularly. A consequence of this is that apps shouldn’t change their UI too frequently.

It would, but the book has existed for a while now, which is a good thing for anyone looking to learn Odin. The author, Karl, has had time to polish and update the text. He has his own Discord and is also available in the Odin Discord and makes helpful posts there as well.

We’ve seen several already, just search it.

Pedantically I’ll say it’s reference counted, and someone else will say that’s still a form of GC and I’ll just save us the mini-thread.

Reference counting has deterministic timing, you can run a deconstructor without registering objects for deletion and running any known finalizers (what you need to do in all GC langs I’m aware of.)

What baffles me is that so many people treat that friction—the effort of working around a tool’s limitations—as the “fun” part, and then advertise it as evidence that the tool is great.

I'm confused by this because I simultaneously agree with Bill by the examples given in the article; things like "ricing" Linux and Vim, but I also advertise Odin as being great due to this friction which may be seen as a limitation.

My favorite example is Odin's approach to metaprogramming and compile-time features. Odin is featureful in this regard, but not nearly to the extent that other languages are (D, Zig, Nim, C++, C) and it may have been the deciding reason I've written far more Odin than any of those other languages.

I _can't_ just do whatever I want at compile-time in Odin. That's a blessing for people like me. I toy with the compiler. I admire languages and language design, and toying with them, learning all of the features, is an expression of that interest. For Odin, there really aren't many novel features for you to toy with. It's just not a toy at all. I don't mean "toy" in then derogatory sense, or to designate others as such. I simply mean that Odin is just not fun to fiddle with, you use it to do something.

Speaking as someone who has also given courses at university teaching a programming language (Swift,) the students also do not know how fast computers are and that when their brand new super-computer lags and hitches for full seconds while coding it's pretty much "working as expected" to them. I haven't written Rust in a few years, but I remember it being remarkably similar to Swift both in API design ergonomics and compiler quality. I am open to this having changed, and I can appreciate @stymaar's frustration if it has done so drastically.

Personally, of that sample I prefer Go and Odin. I find compilers to be terribly fun puzzles, and I love to learn languages inside and out. That's great and all, but I also have to get things done, and I find Go and Odin have a certain... rudimentary feeling which keeps me focused. Go less-so than Odin. I've written quite a lot of Swift in my life, and find it to be the absolute worst language for me in terms of this kind of "distracted energy." There are so many ways to abstract things in Swift, the tool bag is just so deep, and I do get a bit frustrated by the sluggishness of the compiler. I had a work project take us 30 minutes for a clean build, and those of us who have used Xcode know that unfortunately a clean build is not as rare as in some other systems. Maybe this has changed. It's been 4 years since I've done serious work with Swift. Glad to see they stopped making so many breaking changes, though.

EDIT: Actually Typescript is more distracting than Swift. I could spend days toying with the type-checker to make the program sturdier against one change or another.

So, is taste another way of saying you still know better?

I think that's part of the picture, and that applies to "how to respond to LLM output" but I think people are getting at the stuff that happens before you even reach for the LLM. Taste dictates what you decide is non-negotiable, i.e. the goal of what you're doing. So yeah, what you choose to do differentiates you because it's an expression of your goals and values. It's kind of vacuously true, and probably worth each of us thinking how we can be more authentically ourselves and how to guide ourselves through decisions. No one can make them for you, letting others make your life's decisions has always resulted in slop. So how much can you outsource and still be yourself? I know I could ask someone to make my breakfast each day and I'd still be me, but I wouldn't expect that to be true of everyone. Maybe it's true for a lot of chefs, but probably not all of them. We're complicated like that.

This is something that concerns me about this technology. It's just not going to serve some people well to reach their goals. The odds weren't right. Not enough context. No clear way to surface the right context. The result is a kind of loneliness, but it's the kind when you've got a bunch of shallow "friends," when you really need a mentor who doesn't have a plan for you, who is truly wiser than you, or can see you from the distance required to advise, can step away, has real life experiences.

I see that now, thanks. There's a lot to say here, especially with other approaches to memory management. My overall goal was to give them some context that wasn't their own.

Go famously used machine translation to remove dependency from C. It's a nice way to retain structural familiarity with the target language. I imagine they could've saved a large portion of that $165,000 using this route. Hard to say for certain, though. You wouldn't want to scope that transpiler at "being able to transpile all programs generally," and so scoping the project does become a serious task.

As an aside, I don't know why anyone would not want to use a memory-safe (and possibly race-safe) language in 2026.

The rust compiler is very slow. The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article) without any added friction, whereas Rust asks that you think in terms of ownership. This is not preferable ergonomics to many.

I realize what I'm saying above, while true, doesn't give a clear example. Many gamedevs would rather iterate with a language that is lower friction, not only because game code is finnicky (like frontend UI code) but because the build process can be unique. Many gamedevs prefer to iterate with hot-reloading, and asking them to use a slower compiler is asking them to accept greater latency in that cycle.

I do not claim that these reasons apply to everyone.

https://odin-lang.org/docs/overview/#integer-overflow

For signed integers, the operations +, -, *, /, and << may legally overflow and the resulting value exists and is deterministically defined by the signed integer representation. Overflow does not cause a runtime panic. A compiler may not optimize code under the assumption that overflow does not occur. For instance, x < x+1 may not be assumed to be always true.