Threads for user545
-
pljung
edited
4 months ago
|
link
| on:
What Do ChatGPT and AI-based Automatic Program Generation Mean for the Future of Software
Am… Am I the only one who doesn’t find ChatGPT or Copilot useful? To me, their output feels like code a beginner would write. I find myself spending more time debugging than using foundation models‘ code for that reason.
-
I found a few situations where it saves time, like writing tests for utility functions. But generally I’m of the opinion that if I find myself writing code that is too obvious or has a lot of repeating patterns, it means that my abstractions aren’t as good as they could be.
-
-
-
I ran out of ideas how to name things (especially ‘System’, ‘Entity’, ‘Object’, ‘Service’) related classes and functions – long time ago. So I started using lojban :-).
-
-
-
It’s both useful but not anywhere near as useful as people make it out to be. It’s pretty good at giving some simple english summaries on topics. It’s not filled with ads or blogspam like search results. But it’s pretty terrible at producing anything beyond trivial code.
It’s like an advanced rubber duck for me. It often helps me get unstuck on a problem but rarely gives me the final answer.
-
-
-
I’d love to get my hands on a Steam Deck at some point. But valve hardware is almost impossible to acquire in Australia. The Index only just became available late this year.
-
-
I really want one too. You can easily get them on eBay from scalpers at about 2x the price of exchange rate: https://www.ebay.com.au/itm/295421283361
But Valve said that all Asia region orders will be shipped by end of 2022 so I hope they’re looking to expand regions, since they’re caught up.
-
-
Kind of interesting. Reminds me of those python notebooks but 2D. Although this page was extremely slow for me. Very low FPS moving around on an M1 Macbook
-
To summarise as fairly as I can: the author sees people trying to write correct code via unit testing. They are puzzled by this because Erlang isn’t supposed to be correct, it’s supposed to have bugs and then do some work to isolate those bugs, to be able to crash but the whole system keeps mostly running in the face of that crash.
But like… wouldn’t you like to do both? Not have the bugs, and also safely crash when you have the bugs? I can’t tell if this is meant to be ironic or not.
-
The goal for the ‘let it crash’ mindset isn’t to ship buggy code, it’s to acknowledge that even formally verified code is not bug free (your specification can never be complete) and your system should aim to be correct in the presence of failures. Testing is important in Erlang, but testing should be of the form of killing processes at surprising times and ensuring that the system recovers and does not lose data. This gives you a far more reliable system than a quest to eliminate bugs via unit tests. You have a limited budget for testing, you should spend it where it will deliver the most impact.
-
-
I’m familiar with Erlang and with let-it-crash, but that’s not the claim the article is making. Here it is blow-by-blow:
- I see people writing a lot about unit testing in Erlang
- Do we really need all that?
- Erlang has some testing stuff
- But there are cases that it can’t catch, and neither would a type system*
- Erlang’s history includes environments that needed very high uptimes
- To do that, Erlang has a way to continue in the face of crashes
- If you write “clear code with modestly-sized routines” you don’t need tests
- Some specific classes of bugs related to mutability aren’t possible
- Erlang has supervisors that can restart and log buggy code
- ∴ “some Erlangutans [are] missing the point of using Erlang”
The only substantive thing there that could possibly mitigate the need for individual functions to be correct is the “clear code with modestly-sized routines”. Okay, yeah, if you never write wrong code then you’ll never have wrong code, that’s not unique to Erlang. But nothing here obviates the need for correctness. Let-it-crash allows your system that does 10 things to keep doing 9 of them while it’s broken. But it doesn’t make the other one not broken. It doesn’t make that function correct. I’m not even a TDD weenie myself but the idea that let-it-crash is in any way related to correctness, whatever form that might take, strikes me as absurd.
Let-it-crash is very situational. It’s good to allow a complex system to limp along in the face of temporary external problems or problems only involving parts of the system. But “the point” of Erlang isn’t that absolves you from writing correct code with a magical “On Error Resume Next” that still builds your widgets even if you close the exit hatch before you eject them from the chute. Let-it-crash lets one of your two widget-builders keep running after one trips the breaker, which is great and is actually the “point of using Erlang”. But if you don’t fix that bug you’ll still never build a single widget.
*: that particular case can be caught by some type systems like affine or linear types. I don’t claim that Erlang would be improved by those, just some fun trivia
-
-
How should we distinguish between foreseeable and unforeseeable failures? If I write a program that tries to read a file whose path is provided by user input, is it not foreseeable that this file may not exist? Under what conditions is it appropriate for the entire program to crash in response to this error? Under what conditions is it my responsibility as a programmer to explicitly deal with this error? What about errors during file reads caused by device errors? Or errors during file descriptor close or flush or sync syscalls? Or errors when connecting to a remote API? Or during network transfers? Or when communicating with a database?
If you want to define crashworthy errors as whatever the programmer says are crashworthy errors, okay! But then what does crashing mean? If you’re serving a request in an Erlang actor and you hit a syscall error then it’s pretty OK to “crash” that actor because actors are request-scoped and the crash just terminates that single request. But if you’re serving a request in a concurrent e.g. Rust program and that request hits a syscall error then you definitely shouldn’t “crash” the entire process, right? You can terminate the request, sure, but that’s not really what anybody understands by “crash” terminology.
-
At my (former) job, I used Lua to process incoming SIP messages. It uses Lua coroutines [1] to handle each transaction. If some unexpected thing happens (like a
nilreference missed in testing due to unexpected input for instance) only that coroutine “crashes”—that is, ceases to run. This is caught by the framework I’m using and logged. The “crash” does not affect the rest of the program. In my experience, most of the crashes were due to mishandling of input, or rather, a miscommunication about what, exactly, we could expect from the Oligarchic Cell Phone Company that was our customer [2]. We don’t expect crashes, but sometimes we do overlook some conditions (as I’m fond of saying, “bugs are caused by an inattention to detail.”).While Lua isn’t Erlang, I think the overall effect is the same—a crashed thread does not impinge on the rest of the program. Perhaps a better distinction is “let it soft crash [3].”
[1] Think threads, but not pthreads threads, but Lua specific ones cooperatively mutlitasked.
[2] Our service is only for the North American Numbering Plan. We did not expect to receive international phone numbers at all (and weren’t for the non-SIP legacy interface).
[3] Where a “soft crash” just stops the processing and a diagnostic log is issued.
-
Lua coroutine . . . [crashes are] caught by the framework I’m using
Great! Good! My point here is not to assert an absolute, or to deny your specific experience in any way. My point here is to say that the general notion of “crashing” usually does not describe the act of terminating entities under the management of an eg Erlang OTP, or your Lua framework, but instead usually describes the act of terminating entire OS processes.
a crashed thread
I’m trying to communicate that most people do not generally understand threads as things that can “crash”. Threads die or terminate, processes crash. The difference in terminology is my entire point.
-
Then what would you call it?
I have a Lua script. I try running it, Lua spits out “attempt to index a nil value (global ‘x’)” and ends the program. That is, if I understand your nomenclature, a “crash.” Yet if I wrap that same code in a coroutine, the coroutines fails to finish, yet the script continues. What did the coroutine do? Just terminate? I personally consider it a “crash.”
And what does it mean for a “process” to crash? On Unix, the system continues running. Yet on MS-DOS, such a “crash” will usually “crash” the computer. Yet both are crashes. Why can a “process” running under a protected domain (Unix) crash, and yet, threads cannot? I think the participants here are using a broader definition of “crash” than you personally like.
-
I have a Lua script. I try running it, Lua spits out “attempt to index a nil value (global ‘x’)” and ends the program. That is, if I understand your nomenclature, a “crash.” Yet if I wrap that same code in a coroutine, the coroutines fails to finish, yet the script continues.
If you can write a bit of code that runs (more or less) equivalently as its own OS process (scenario 1) or as a coroutine among other coroutines in a single shared OS process without modification (scenario 2) then whatever is orchestrating coroutines in the second scenario is necessarily enforcing isolation boundaries that are functionally equivalent to the OS threads in the first scenario.
What did the coroutine do? Just terminate? I personally consider it a “crash.”
If that code fails in scenario 1, is that a crash? IMO yes.
If that code fails in scenario 2, is that a crash? IMO no.
Why can a “process” running under a protected domain (Unix) crash, and yet, threads cannot? I think the participants here are using a broader definition of “crash” than you personally like.
My understanding of “crash”, or yours, isn’t important to me, what I care about is what the average developer understands when they see that term, absent any other qualifications. I don’t think most developers consider a thread termination to be a crash, and I think if you want to say “crash” to mean something like that you need to qualify it. That’s my only point. Could be wrong.
-
-
-
-
It’s worth pointing out that in the Erlang world, it’s not the entire program that crashes. Like, ever. Instead, whatever individual process that ran into the error is the piece that fails. In the context of a program loading a file, it’s likely that just the process responsible for loading the file would die. Which makes perfect sense, since it’s no longer a meaningful operation to continue loading a file that we can’t open.
The elegance of the “let it crash” mentality is that it lets you handle foreseeable, unforeseeable, and foreseeable-but-too-unlikely-to-care-about failures in the exact same way. Like sure, you could check to make sure a file exists, but what if it’s corrupted? Or someone takes a sledgehammer to the hard drive while you’re in the midst of reading the file? There’s an infinite number of failure states for a given operation, and for a lot of them there isn’t a meaningful resolution within the operation itself.
-
It’s well-understood that “crashing” in Erlang doesn’t mean crashing the entire program. The problem is that “crashing” in basically any context except Erlang does mean crashing the entire program.
-
-
-
-
-
-
I think size of the program, and the team maintaining it, is an important factor in the static vs dynamic discussion.
I’m in the “I don’t make type errors, and if I do, I can shake them out with a few tests” camp for as long as I can comprehend what’s going on in the codebase.
But when the code grows to the point I can no longer remember where everything is, e.g. I can’t find all callers of a function, dynamism starts to become a burden. When I need to change a field of a struct, I have to find all uses of the field, because every missed one is a bug that’s going to show up later. At some point that becomes hard to grep for, and even impossible to account for in reflection-like code. It can degrade to a bug whack-a-mole, promote more and more defensive programming patterns, and eventually fear of change.
I’ve had good experiences with gradually-typed languages. They stretch this “size limit” of a program a lot, while still allowing use of duck typing where it helps, without bringing complexity of generic type systems.
-
“Dynamic typing falls apart with large team/large codebase” is one of those cliché arguments that doesn’t really contribute usefully, though.
Also your presentation of it has multiple issues:
- Large team/large codebase projects fail all the time regardless of typing discipline. Static typing doesn’t appear to have a better track record of success there.
- Tooling for dynamically-typed languages has come a long way in the decades since this argument was first raised. You can just get an IDE and tell it to track down and rename references for you. And if your complaint is that it’s harder/impossible to do through “reflection-like code”, well, people can write metaprogram-y reflection stuff in statically-typed languages too.
- Ultimately, if your codebase has lots of functions or methods that are called from huge numbers of disparate places, to such a degree that you can’t safely work with it without an IDE doing full static analysis to track them all for you, that’s a code smell in any language, in any typing discipline.
-
-
Static languages can verify all metaprogramming is type correct.
This is probably going to get off-topic into arguing about the exact definition of “statically-typed”, but: I think that if you venture outside of languages like Rust (which seem to deliberately limit metaprogramming features precisely to be able to provide guarantees about the subset they expose), you’lll find that several languages’ guarantees about ahead-of-time correctness checks start being relaxed when using metaprogramming, runtime code loading, and other “dynamic-style” features. Java, for example, cannot actually make guarantees as strong as you seem to want, and for this among other reasons the JVM itself is sometimes referred to as the world’s most advanced dynamically-typed language runtime.
There also are plenty of things that seem simple but that you basically can’t do correctly in statically-typed languages without completely giving up on the type system. Truly generic JSON parsers, for example. Sure, you can parse JSON in a statically-typed language, but you either have to tightly couple your program to the specific structures you’ve planned in advance to handle (and throw runtime errors if you receive anything else), or parse into values of such ultra-generic “JSON object” types that the compiler and type system no longer are any help to you, and you’re effectively writing dynamically-typed code.
-
for this among other reasons the JVM itself is sometimes referred to as the world’s most advanced dynamically-typed language runtime
Aren’t runtimes always “dynamically typed”? What does it mean for a runtime to be “statically typed”?
or parse into values of such ultra-generic “JSON object” types that the compiler and type system no longer are any help to you, and you’re effectively writing dynamically-typed code.
It sounds like you’re arguing that the worst case for static type systems is equivalent to the best case for dynamic type systems, which doesn’t seem like a ringing endorsement for dynamic type systems. That said, I don’t even think this is true for this JSON-parsing example, because you could conceive of a generic JSON parser that has different unmarshaling strategies (strict, permissive, etc). Further, as static type systems are adopted more widely, this sort of poorly-structured data becomes rarer.
-
Aren’t runtimes always “dynamically typed”?
Some more so than others. Rust, for all its complexity as a language, is mostly shoving that complexity onto the compiler in hopes of keeping the runtime relatively simple and fast, because the runtime doesn’t have to do quite as much work when it trusts that there are classes of things the compiler simply prevents in advance (the runtime still does some work, of course, just not as much, which is the point).
But a language like Java, with runtime code loading and code injection, runtime reflection and introspection, runtime creation of a wide variety of things, etc. etc. does not get to trust the compiler as much and has to spend some runtime cycles on type-checking to ensure no rules are being broken (and it’s not terribly hard to deliberately write Java programs that will crash with runtime type errors, if you want to).
That said, I don’t even think this is true for this JSON-parsing example, because you could conceive of a generic JSON parser that has different unmarshaling strategies (strict, permissive, etc).
If you want truly generic parsing, you’re stuck doing things that the compiler can’t really help you with. I’ve seen even people who are quite adept at Haskell give up and effectively build a little subset of the program where everything is of a single
JSONtype, which is close enough to being dynamically typed as makes no difference.Further, as static type systems are adopted more widely, this sort of poorly-structured data becomes rarer.
My experience of having done backend web development across multiple decades is that poorly-structured data isn’t going away anytime soon, and any strategy which relies on wishing poorly-structured data out of existence is going to fail.
-
Aren’t runtimes always “dynamically typed”?
If you eschew these needlessly binary categories of static vs dynamic and see everything on a scale of dynamism then I think you’ll agree that runtimes are scattered across that spectrum. Many even shift around on that spectrum over time. For example, if you look at the history of JSR 292 for adding
invokedynamicto the JVM you’ll find a lot of cases where the JVM used to be a lot less dynamically typed than it is today.
-
-
There’s no reason you can’t parse a set of known JSON fields into static members and throw the rest into an ultra-generic JSON object.
-
Those are the options I said are available, yes.
-
I mean, you can do both at once for the same value, getting the benefits of both.
-
-
-
Dynlangs are definitely better for data that isn’t structured as well.
C#’s dynamic keyword feels like a perfect fit for this situation without having to give up static typing everywhere else. Hejlsberg is ahead of the curve, per usual.
-
-
-
Fail is too harsh. Unless you’re writing some rocket navigation system, a project is not going to outright fail because of software defects. Run-time type errors merely add to other bugs that you will need to fix, and I argue that bugs caused by runtime type errors are less of a problem in small programs.
I don’t know of any robust tooling for refactoring large JavaScript projects. Of course most languages have some type-system escape hatches, but I expect languages like JS to use hard-to-analyze type-erasing constructs much more often.
I disagree that having callers beyond your comprehension is automatically a code smell. It’s a natural state of things for libraries, for example. Ideally libraries should have a stable API and never change it, but it’s not always that easy, especially for internal libraries and reusable core pieces of large projects that may need to evolve with the project.
It’s not just about IDEs. Compilation will also track down all type errors for you, regardless of where and when these errors happen. When working with teams, it may be someone else working on some other component. In this case the types are a way to communicate and coordinate with others.
You can make a mess in any language, but how easy is to make a mess varies between languages. Languages that prevent more errors will resist the mess for longer.
-
I expect languages like JS to use hard-to-analyze type-erasing constructs much more often.
Why do you expect this?
I disagree that having callers beyond your comprehension is automatically a code smell.
Even if it’s an internal library, why don’t other internal codebases have a single clear integration point with it? And why does everything else need to have lots of knowledge of the library’s structure? This definitely is a code smell to me – the Law of Demeter, at least, is being violated somewhere, and probably other design principles too.
Languages that prevent more errors will resist the mess for longer.
This is veering off into another clichéd and well-trod argument (“static typing catches/prevents more bugs”). I’ll just point out that while proponents of static typing often seem to take it as a self-evident truth, actually demonstrating its truth empirically has turned out to be, at the very least, extremely difficult. Which is to say: nobody’s managed it, despite it being such an “obvious” fact, and everybody who’s tried has run into methodological problems, or failed to prove any sort of meaningful effect size, or both.
-
Why do you expect this?
Because the flexibility is a benefit of dynamic languages. If you try to write code as-if it was strongly statically typed, you’re missing out on the convenience of writing these things “informally”, and you’re not getting compiler help to consistently stick to the rigid form.
why don’t other internal codebases have a single clear integration point with it?
The comprehension problems I’m talking about that appear in large programs also have a curse of being hard to explain succinctly in a comment like this. This is very context-dependent, and for every small example it’s easy to say the problem is obvious, and a fix is easy. But in larger programs these problems are harder to spot, and changes required may be bigger. Maybe the code is a mess, maybe the tech debt was justified or maybe not. Maybe there are backwards-compat constraints, interoperability with something that you can’t change, legacy codebase nobody has time to refactor. Maybe a domain-specific problem that really needs to be handled in lots of places. Maybe code is weirdly-shaped for performance reasons.
The closest analogy I can think of is “Where’s Waldo?” game. If I show you a small Waldo picture, you’ll say the game is super easy, and obviously he’s right here. But the same problem in a large poster format is hard.
-
Because the flexibility is a benefit of dynamic languages. If you try to write code as-if it was strongly statically typed, you’re missing out on the convenience of writing these things “informally”, and you’re not getting compiler help to consistently stick to the rigid form.
You are once again assuming that statically-typed languages catch/prevent more errors, which I’ve already pointed out is a perilous assumption that nobody’s actually managed to prove rigorously (and not for lack of trying).
Also, the explanation you give still doesn’t really make sense. Go look at some typical Python code, for example – Python’s metaprogramming features are rarely used and their use tends to be discouraged, and easily >99% of all real-world Python code is just straightforward with no fancy dynamic tricks. People don’t choose dynamic typing because they intend to do those dynamic tricks all the time. They choose dynamic typing (in part) because having that tool in the toolbox, for the cases when you need it or it’s the quickest/most straightforward way to accomplish a task, is incredibly useful.
The comprehension problems I’m talking about that appear in large programs also have a curse of being hard to explain succinctly in a comment like this
Please assume that I’ve worked on large codebases maintained by many programmers, because I have.
And I’ve seen how they tend to grow into balls of spaghetti with strands of coupling running everywhere. Static typing certainly doesn’t prevent that, and I stand by my assertion that it’s a code smell when something is being called from so many disparate places that you struggle to keep track of them, because it is a code smell. And there are plenty of patterns for preventing it, none of which have to do with typing discipline, and which are well-known and well-understood (most commonly, wrapping an internal interface around a library and requiring all other consumers in the codebase to go through the wrapper, so that the consuming codebase controls the interface it sees and has onlyu a single point to update if the library changes).
-
I’ve worked on large codebases maintained by many programmers, because I have. And I’ve seen how they tend to grow into balls of spaghetti with strands of coupling running everywhere. Static typing certainly doesn’t prevent that . . .
No, definitely not, agreed. But static typing definitely improves many/most dimensions of project maintainability, compared to dynamic typing. This isn’t really a controversial claim! Static typing simply moves a class of assertions out of the domain of unit tests and into the domain of the compiler. The question is only if the cost of those changes is greater or lesser than the benefits they provide. There’s an argument to be made for projects maintained by individuals, or projects with lifetimes of O(weeks) to O(months). But once you get to code that’s maintained by more than 1 person, over timespans of months or longer? The cost/benefit calculus just doesn’t leave any room for debate.
-
But static typing definitely improves many/most dimensions of project maintainability, compared to dynamic typing. This isn’t really a controversial claim!
On the contrary, it’s a very controversial claim.
Proponents of static typing like to just assert things like this without proof. But proof you must have, and thus far nobody has managed it – every attempt at a rigorous study to show the “obvious” benefits of static typing has failed. Typically, the ones that find the effect they wanted have methodological issues which invalidate their results, and the ones that have better methodology fail to find a significant effect.
The cost/benefit calculus just doesn’t leave any room for debate.
Again: prove it. WIth more than anecdata, because we both have anecdotes and that won’t settle anything.
-
-
-
Because the flexibility is a benefit of dynamic languages. If you try to write code as-if it was strongly statically typed, you’re missing out on the convenience of writing these things “informally”, and you’re not getting compiler help to consistently stick to the rigid form.
I see most typing errors as self-inflicted wounds at this point. Don’t have time or patience for things that can be prevented by the compiler happening at runtime.
Dynlangs + webdev together is my kryptonite. If I had to do that all day I’d probably start looking for a new career. Just can’t deal with it.
-
-
-
I don’t know of any robust tooling for refactoring large JavaScript projects
Following up on this specifically: I’m an Emacs guy, not really an IDE person, so I don’t know the landscape that well. But everybody I know who goes the IDE route in Python uses PyCharm, so I looked up the rest of the JetBrains product line, and sure enough they have an IDE for JavaScript/TypeScript which claims to support refactoring.
I assume it’s not the only such product out there.
-
-
Large team/large codebase projects fail all the time regardless of typing discipline. Static typing doesn’t appear to have a better track record of success there.
Yes, projects can fail for lots of reasons; no one is claiming that static typing will make a shitty idea commercially successful, for example :) But I do think static types help a lot within their narrow scope–keeping code maintainable, reducing bugs, preserving development velocity, etc. Of course, there’s no good empirical research on this, so we’re just going off of our collective experiences. 🤷♂️
-
Large team/large codebase projects fail all the time regardless of typing discipline. Static typing doesn’t appear to have a better track record of success there.
I think it pretty much does, actually. Static typing moves an enormous class of invariants from opt-in runtime checks to mandatory compile-time checks. Statically typed languages in effect define and enforce a set of assertions that can be approximated by dynamically typed languages but never totally and equivalently guaranteed. There is a cost associated with this benefit, for sure, but that cost is basically line noise the moment your project spans more than a single developer, or extends beyond a non-trivial period of time.
-
I think it pretty much does, actually.
As I said to your other comment along these lines: prove it. The literature is infamously full of people absolutely failing to find effects from static typing that would justify the kinds of claims you’re making.
-
-
-
To be fair, any use of is_a? in ruby is a code smell
-
-
Yeah, the need for ruby devs is much larger than the supply of good ones or even ones good enough to train the others. I’ve seen whole large ruby codebases obviously written by Java and C++ devs who never got ruby mentoring. I expect this is an industry wide problem in many stacks
-
-
-
You seem to just be trolling, but I’ll play along, I guess.
I’ve seen a bit of Ruby, and a lot of Python and JavaScript, and I’ve never seen this except for code written by people who were coming from statically-typed languages and thought that was how everyone does dynamic typing. They usually get straightened out pretty quickly.
Can you point to some examples of popular Ruby codebases which are written this way? Or any verifiable evidence for your claim that dynamic languages are “unsuitable… for real world use”?
-
I’m not trolling at all. I’ve been a Rails dev for the last 7 years and seen the same thing at every company. I don’t work on any open source code so I can’t point you at anything.
I quite like Rails but I’m of the opinion that the lack of static type checking is a serious deficiency. Updating Rails itself is an absolute nightmare task where even the official upgrade guide admits the only way to proceed is to have unit tests on every single part of the codebase because there is no way you can properly verify you have seen everything that needs to change. I’ve spent a large chunk of time spanning this whole year working towards updating from Rails 5.1 to 5.2. No one else dared attempt it before I joined because it’s so extremely risky.
I love a lot of things about Rails and the everything included design but I don’t see a single benefit to lacking types. Personally I see TypeScript as taking over this space once the frameworks become a little more mature.
-
You made a very specific assertion about how people write Ruby (lots of manual type-checking assertions). You should be able to back up that assertion with pointers to the public repositories of popular projects written in that style.
-
I remembered hearing from my then-partner that Rails itself uses a lot of
is_a?, and that seems true.if status.is_a?(Hash) raise ArgumentError, etc...-
This is pretty misleading – a quick glance at some of the examples seems like many of them aren’t really checking argument types, and when they are, they’re often cases where a method accepts any of multiple types, and there’s branching logic to handle the different options.
Which is something you’d also see in a statically-typed language with sum types.
The proposition that this is a common idiom used solely as a replacement for static checking is thus stil unproved.
-
-
-
ill concur with GP: this is a fairly common pattern to see in ruby codebases.
however, to be fair, it’sa pattern most often introduced after attending a talk by a static typing weenie…
-
-
-
-
-
-
I would love to see broader adaptation of refinement types that let you statically guarantee properties like integer values being bound between specific values.
-
-
-
I’m in the “I don’t make type errors, and if I do, I can shake them out with a few tests” camp for as long as I can comprehend what’s going on in the codebase.
This is generally true for me, but writing tests or debugging stack traces makes for a slow iteration loop. A type error from a compiler usually contains better, more direct information so resolving these type errors is a lot faster. To the extent that I (a 15 year Pythonista) eventually began to prototype in Go.
That said, the biggest advantage for me for a static type checker is that it penalizes a lot of the crappy dynamic code (even the stuff that is technically correct but impossible to maintain/extend over time). A static type system serves as “rails” for less scrupulous team members. Of course, a lot of these less-scrupulous developers perceive this friction as a problem with static type systems rather than a problem with the way they hacked together their code, but I think Mypy and TypeScript have persuaded many of these developers over time to the extent that static types are much less controversial in most dynamic language communities.
Another big advantage is that your type documentation is always correct and precise (whereas docs in a dynamically typed language often go stale or simply describe something as “a file-like object” [does that mean it just has a read() method, or does it also need write(), close(), seek(), truncate(), etc?]). Further, because the type docs are precise, you can have thinks like https://pkg.go.dev complete with links to related types, even if those types are declared in another package, and you get all of this for free.
-
I’m in the Type everything if it’s even kinda big camp now. There are too many things I need to think about during the day to remember the state and usage of every variable of every program I’ve ever written, used or inspected. Typings are rails for my logic. Typings are documentation. Types help my IDE help me. I will take every single shortcut I can when the timespan I or anyone else could be interacting with the code is longer than 10 minutes.
Retracing steps is just so tedious and frustrating when you had it all in your head before. It just sucks. I just wanna build stuff, not fill my head with crap my computer can do.
/rant
-
-
Good self-hosted software really needs to have leak-proof abstractions. Too many leaks means too much admin intervention, which is in short supply for hobbyists.
Gitea is one that does this well IMO. A single binary, a single config file, and a single data directory are all key. Contrast this with my MediaWiki instance that needs a dozen packages installed, config is split between httpd.conf and LocalSettings.php, and data is split between the static files and database files. Not as bad as some, but still not ideal.
-
Configuration woes are exactly why I’m considering writing my own web server instead of using Apache or Nginx. My needs are simple:
- Static files only.
- TLS (that kind of sucks but I don’t have a choice).
- Content negotiation for languages (some of my posts are dual English/French).
- Nice to have: cache everything in RAM (my website is that small).
Then maybe one day I’ll stare into the SMTP abyss.
-
You sound like a person who is yet to discover the warm convenience of https://caddyserver.com/
-
I am indeed. Thanks for the tip.
-
-
-
Nice to have: cache everything in RAM (my website is that small).
Since you have a static site I’d assume that this is mostly handled by file system anyways, minus compression. I wonder how much one really gains from that, especially when using the right syscalls.
Then maybe one day I’ll stare into the SMTP abyss.
If you want a simple SMTP config OpenSMTPD is the way to go. See the examples section of their man page.
Of course that doesn’t cover delivery (IMAP, etc.) or anti-spam measures. The good thing here is that it doesn’t change much.
-
-
Making self hosting easy would be very possible, but I think the amount of work it would take is just too much. For an ideal system, everything needs to be standardized. There needs to be some way to just browse a UI and click “install”.
Yes I know there are many projects that advertise this, but none of them actually work well. It’s a monumental amount of work for the projects to patch and configure every service so it fits a set of standards for backups, SSO, webserver access, certificates, etc. And then last I checked these projects were not containerized so there were major issues doing things like OS updates because PHP/etc would update which would present major issues for running services.
And then there is just no money in it to make it worth the effort.
-
-
On Rust’s “diversity numbers being terrible” and worse than the industry – is it worse than open source? For example, I think the last time anyone checked, there were many fewer women open source programmers vs. paid career programmers.
That is, I think all open source projects have this issue (and lobste.rs and HN seem to as well :-/ )
-
My impression is that Rust’s gender ratio number is in fact worse than open source. One possible reason is that compiler is a field gender-coded to be masculine. That is, I think Rust-the-project’s number is worse than Rust ecosystem (e.g. bodil, the maintainer of im crate, is a woman) but similar to, say, LLVM.
-
-
While AVIF has decent compression due to using AV1, its container format (HEIF) is unfortunately a bloated designed-by-committee mess. We looked at implementing it in libavformat in FFmpeg during GSoC 2019, and the conclusion in short was “no”. I might write a blog post on its many failings if there’s interest, but in short: it is not just a still image format. It also supports albums, compositing and a whole slew of other junk. This makes implementing a decoder for it in a project like FFmpeg a monumental task.
In my opinion it would be vastly superior to just define a FourCC for AV1 and stick it in a BMP file. BMP parsers are common, the format already supports compression. There’s no need to come up with anything new. A similar argument can be made for audio formats, which can just be stuck inside WAV files with an appropriate TwoCC.
-
I’d love a bog post that explains it in great detail (the format, the existing ffmpeg software architecture, the assumptions, the goals, the conflicts). I’d also like to hear about non-technical side of this - I think there’s lots of value to be derived from talking about projects that didn’t succeed.
-
Out of curiosity, is any container format NOT a mess? I’ve heard people complain about ogg, MP4 and a few others, but nobody seems to dish out much praise anywhere. Container formats in general seem to be a somewhat obscure topic, nobody seems to say much about tradeoffs in them or what makes a good vs. bad design.
-
Well, BMP and WAV are fairly simple and find wide use. They have their quirks though, like uncompressed BMP are stored upside-down and lines must be an even number of bytes. WAV only supports constant bitrate. AVI worked well enough before B-frames started being used. Ogg is an absolute joke. ISOBMFF (MOV) has tons of derivatives including MP4, 3GP and HEIF. It suffers from requiring a complete header to decode. Fragmented MP4 fixes that, but of course that’s only MP4. MXF is widely used in the broadcast world, is a huge mess both design wise and for being split over oodles of SMPTE specs. It also happens to be the format I maintain in libavformat.
-
is any container format NOT a mess
This is a very good observation.
Container formats that implement a ‘database-in-a-file’ with bunch of tables, ‘foreign-key-conventions’, and so on are really really difficult to use (and I cannot even imagine, what it is to implementers, or folks who write conversion utilities).
I do not know what a proper solution/architecture approach for these are, though. It seems that this model is needed.
PDF
HDF5
come to mind.
-
-
From what I’ve heard a significant portion of its value is that you don’t have to deal with any open formats/libraries, all of which are garbage.
-
-
-
HEIF, and thus AVIF, is an unfortunate pile of ISO specs. Each spec in itself isn’t unreasonable, but the sum of them adds up to ridiculous bloat. You need 300 bytes of MPEG metadata to say 1 bit of information that the AVIF has an alpha channel.
However, it’s most likely that nobody will implement the full feature set, and we’ll end up with a de-facto AVIF minimal profile that’s just for still images.
AVIF-sequence is another bizarre development. It’s a video format turned into image format turned back into worse, less efficient, more complex video format. And Chrome insists on requiring AVIF-sequence over a real AV1 video in
<img>.-
However, it’s most likely that nobody will implement the full feature set, and we’ll end up with a de-facto AVIF minimal profile that’s just for still images.
This is the issue though. Because we can’t claim to have implemented AVIF because someone is going to come along with a composite AVIF some day and go “guise ffmpeg is broken it can’t decode this”.
I looked at AVIF-sequence just now, it just sounds like AV1 in MP4 with “avis” in the ftyp atom. Nothing too strange about that.
-
-
There’s no need to come up with anything new are there other patent-free high-compression formats that support, as an example, PPTX-> conversion (to an individual file) ?
For my needs, being able to stick a slide show into one file (and then being able to reference ‘a page’ within the file, on a client), solves some technical complexities.
I might write a blog post on its many failings if there’s interest
Oh, and I also join folks who would love to see you write a blog post on this. Implementer’s analysis of AVIF, its pain points, short comings, etc, would be very interesting in shaping community understanding of this.
-
-
-
-
Looking through the Android 11 features and they seem like a decent improvement. The thing that stuck out to me was how at the end they have a link to “pixel exclusive features” after reading the list it didn’t seem like a single thing on the list was linked to specific hardware requirements. Is google really moving features out of android AOSP to make their phones look better?
-
-
I think the URL changed from a more consumer/PR-focused blog post to the current developer-focused URL.
-
would you mind sharing that URL?
This is the list of “Pixel first” features. https://www.blog.google/products/pixel/android11-exclusive-pixel-features and they specifically say “And this time, with new Pixel-first features on Android 11, your Pixel has even more smarts to make it better and more helpful…” The Pixel support thread (https://support.google.com/pixelphone/thread/69861931?hl=en) similarly sells these new features from an (as I would term it) advertising perspective.
Is google really moving features out of android AOSP to make their phones look better?
Not to sound jaded, but why would this be a surprise? Or to rephrase that, if Google has teams dedicated to Pixel support, why would they force those teams to put everything developed into AOSP? As a company, they have to find some way/reason to market their products and I wouldn’t expect them to leave the Pixel stock.
-
-
-
I wish they’d included an avif at a similar size as the jpeg used in the first F1 comparisons.
The ‘26’ in front of the car is barely visible in anything else than the jpeg, but the jpeg is ~70kb, so would avif at ~70kb match jpeg on that? do better? worse? I can’t tell.
-
-
AVIF has a novel technique of predicting color from brightness. This makes encoding of color cheaper overall, and helps it have super sharp edges of colored areas without any fringing.
However, the red-blue “26” text is only a difference in hue, but not brightness, so the luma channel doesn’t help it get predicted and sharpened. The encoder should have been smarter about this and compensated for it.
-
-
-
-
-
For a lot of things, there optimisation you want is best quality meeting this size / bandwidth goal, rather than lowest size meeting this quality goal. If a 70KiB JPEG meets your size / bandwidth requirements then it would be interesting to see how your quality increases going to a 70 KiB AVIF.
-
-
-
user545
2 years ago
|
link
| on:
That UPS you bought for your home server may not be as useful as you think
I had a UPS on my desktop for a while because 5 second power outages were pretty common. I noticed the thing used to run really hot. It must be wasting a huge amount of power while not actually providing any value most of the time.
-
Got given a google home for free and ended up giving it away. Just don’t feel comfortable with google handling this information. Switched to an iphone recently and I feel better about siri just because Apple actually seems to give a shit about user data and privacy.
-
Calling someone’s code ’clever should always be understood as an insult.
-
-
In an idiocracy, this would be true.
It’s like telling a joke to an emperor, he doesn’t get it and so off-with-your-head.
Maybe the comedian was too clever for his own good, or too dumb to know when to be clever.
But we don’t live in an idiocracy.
-
-
Did you end up using a state management library for the frontend? If so, how did you get it populated by the backend? I’m just wondering if there are some well known patterns for syncing frontend state to the backend, perhaps especially with a REST API.
-
The JSON:API standard for REST API design has a lot of implementations for both the server (e.g. Rails) and the client (e.g. Redux or framework-less JS). From the documentation, it looks like those libraries handle some of the work of transmitting states through the API. I’ve never used JSON:API myself, though.
-
-
-
FiloSottile
edited
4 years ago
|
link
| on:
Why You Should Never Save Passwords on Chrome or Firefox
This is terrible general security advice, as well as a failure in threat modeling.
The point of the (very usable!) built-in password manager is to fight phishing and password reuse, which are each orders of magnitude bigger problems than endpoint compromise, which is the attacker position this article relies on. That alone makes this dangerous advice.
But even if you are somehow focusing on endpoint compromise, on desktop systems the malware can just wait for you to type the password manager master passphrase, and exfiltrate the entire vault. Not 12 lines of code, but maybe 120. In fact, there’s a better argument for calling the latter approach “security by obscurity”; I wouldn’t call using SQLite an attempt at obscurity at all.
In practice, the passwords that matter are the system FDE one for encryption at rest (which protects the browser passwords as well as the rest), and the sync password to protect the contents from the cloud provider, which the browsers correctly implement.
The only thing requiring a master password to be typed to unlock the vault locally would do for most users is degrade UX, reducing adoption, and provide a false sense of security (because again if the endpoint is compromised, it will fall to keyloggers or memory inspection).
-
Its annoying how so much of this “security advice” is about stuff where you have already been compromised and there are already 100 other ways to get the data or its about such insane things like “Out of office emails are a security risk” because someone might send you and email and then know they can launch an attack while you are on holiday..
-
In practice, the passwords that matter are the system FDE one for encryption at rest (which protects the browser passwords as well as the rest), and the sync password to protect the contents from the cloud provider, which the browsers correctly implement.
Firefox doesn’t implement the second properly: passwords are encrypted using a key which is a simple function of the password (which means that Mozilla can attempt to crack them, and will be successful for simple password like ‘open sesame.’
Worse, they don’t even have to do that: they sometimes prompt for Firefox passwords on web pages, which means that they can just steal your plaintext password there.
Sadly, Firefox used to have a password storage system which really was secure against Mozilla being malicious.
I think that Chrome is very slightly better here, because the password-encryption password is never shared with Google.
I completely agree with everything else you write, though.
-
-
There is no reason you have to use server side rendering with rails. My website uses rails to serve a json api to the frontend and I still get all the upsides listed on this post like devise and factorybot. I investigated using rust for the backend for speed reasons but after a few weeks trying it I went with rails because of how insanely fast it is to develop stuff with rails.
At the end of the day I would rather have a finished project over a faster one that doesn’t exist.
-
I never was a rails guy so this may be off target, but I thought the author was suggesting you still have to do more work to write a JS based UI that takes advantage of all the things that Rails can do on the backend. He wants something that has the same ease of use that server rendered Rails apparently had.
-
Rails even has “api-only mode” and has webpack integration. It does not save you from burdens of GraphQL and complex state management in React, however. UJS is mostly failed thing. But backend things are still there and it’s still better than most node.js libs, at least if you don’t need cooperative multitasking for handling millions of idle connections.
-
-
It’s going to be interesting to see how much this is going to affect the future of how the WWW functions. GDPR sure didn’t manage to be as severe of a measure as we’d hoped it be. Heck, I’m having troubles getting the relevant authorities to understand clear violations that I’ve forwarded to them, where they then end up just being dismissed.
But this law here is of course not for the people, no… This is here for the copyright holders, and they carry much more power. So will this actually result in the mess we expect it to be?
-
-
-
-
You had this choice before though, it’s normal to make a cookies whitelist for example in firefox with no addons. The GDPR lets you trust the site that wants to track you to not give you the cookies instead of you having personal autonomy and choosing not to save the cookies with your own client.
-
I think this attitude is a bit selfish since not every non-technical person wants to be tracked, and it’s also counter-productive, since even the way you block cookies is gonna be used to track you. The race between tracker and trackee can never be won by any of them if governments don’t make it illegal. I for one am very happy about the GDPR, and I’m glad we’re finally tackling privacy in scale.
-
-
I admire your spirit, but I think it’s a bit naive to think that everyone has time for all kinds of empowerment. My friends and family want privacy without friction, without me around, and without becoming computers hackers themselves.
-
-
-
-
-
-
-
Goes on to show how much information about us is being implicitly collected in my honest opinion, whether for advertisement or administration.
-
-
-
-
-
That old canard is increasingly untrue as governments and supercorps like Google, Amazon, and Facebook seek to control as much of the Internet as they can by building walled gardens and exerting their influence on how the protocols that make up the internet are standardized.
-
I believe John Gilmore was referring to old-fashioned direct government censorship, but I think his argument applies just as well to the soft corporate variety. Life goes on outside those garden walls. We have quite a Cambrian explosion of distributed protocols going on at the moment, and strong crypto. Supercorps rise and fall. I think we’ll be OK.
Anyway, I’m disappointed by the ruling as well; I just doubt that the sky is really falling.
-
I agree that it is not the sky falling. It is a burden for startups and innovation in Europe though. We need new business ideas for the news business. Unfortunately, we now committed to life support for the big old publishers like Springer.
At least, we will probably have some startups applying fancy AI techniques to implement upload filters. If they become profitable enough then Google will start its own service which is for free (in exchange for sniffing all the data of course). Maybe some lucky ones get bought before they are bankrupt. I believe this decision is neutral or positive for Google.
The hope is that creatives earn more, but Germany already tried it with the ancillary copyright for press publishers (German: Leistungsschutzrecht für Presseverleger) in 2013. It did not work.
-
Another idea for a nice AI startup I had: Summarizing of news with natural language processing. I do not see that writing news with an AI is illegal, only copying the words/sentences would be illegal.
Maybe however, you cannot make public from where you aggregated your original news that you feed into your AI :)
-
-
-
Governments, corporations, and individual political activists are certainly trying to censor the internet, at least the most popularly-accessible portions of it. I think the slogan is better conceptualized as an aspiration for technologists interested in information freedom - we should interpret censorship as damage (rather than counting on the internet as it currently works to just automatically do it for us) and we should build technologies that make it possible for ordinary people to bypass it.
-
-
-
I can see a really attitude shift coming when the EU finally gets around to imposing significant fines. I worked with quite a few organisations that’ve a taken ‘bare minimum and wait and see’ attitude who’d make big changes if the law was shown to have teeth. Obviously pure speculation though.
-
-
Did we really call the accessibility tag a11y?
-
FWIW, a11y is a fairly industry-standard term for accessibility, since it both serves as a short moniker (a la i18n for internationalization), and evokes being an “ally” for issues relating to accessibility.
-
Accessibility is often abbreviated as the numeronym a11y, where the number 11 refers to the number of letters omitted. This parallels the abbreviations of internationalization and localization as i18n and l10n respectively.
-
-
-
Alternatively, it is nice to think of it as being an “ally” to people who use the web differently than we do. It’s cute, easy to type, and overall I don’t think it’s that hard to understand. I do see the concern that to people outside the industry it may not make sense, I just feel like on a highly technical site like lobsters it’s not as big of a concern. The tag description does say “accessibility” for what it’s worth.
-
-
-
-
-
-
-
Yeah, I mean, I realize that this term is fairly well-known. It’s a field that’s about people’s lives, so it does have a higher standard to meet than, say, type theory. I suspect that in practice, this abbreviation isn’t a problem. I was just a bit surprised at myself that I never questioned it before. I still don’t even know how it sounds in a screen reader, since I don’t have one set up to test with.
-
I still don’t even know how it sounds in a screen reader, since I don’t have one set up to test with.
Just tested with Windows Narrator, it pronounces it “ay-eleven-why”.
-
-
-
-
-
-
-
When you’re doing a pull request, some random guru-senior-architect might occasionally check your code and suggest few changes. Sounds unlikely but any additional eyes might uncover bugs or architecture mistakes.
Is this true? I would love to have someone review my code but I cant see it ever happening. Do I just open a PR and hope someone comes along to review it? How would they even know I am waiting for public review. It feels quite rude to jump in to someone elses project and start reviewing their changes.
-
The way this PR was written made it almost seem like a joke
and
To me this read a lot like satire poking fun at the Rust community. Took me some digging to realize this was actually serious! I personally don’t care what language fish happens to be written in. As a happy user of fish I just really hope this doesn’t disrupt the project too much. Rewrites are hard!
This is what it looks like when someone is self-aware :-)
They looked at the tradeoffs, made a technical decision, and then didn’t take themselves too seriously.
Poe’s Law is strong with this one. Not knowing the author of Fish, I genuinely can’t tell whether the commentary is 100% in earnest, or an absolutely brilliant satire.
Given the almost 6,000 lines of seemingly high quality Rust code, I’m going to say it’s not a joke.
Gotta commit to the bit.
Oh, sure! I meant the explanation in the PR, not the code itself.
Same. After doing some research into the PR though, I’m pretty sure it’s in earnest. XD
For sure! After I looked deeper and found that this person is a main contributor to fish things made more sense. I totally respect their position and hope things go well. I just thought the way it was phrased made it hard to take seriously at first!
The author understands some important but often underappreciated details. Since they aren’t paying anyone to work on the project, it has to be pleasant and attractive for new contributors to want to join in.
It only “has to be” if the project wants to continue development at an undiminished pace. For something like a shell that seems like a problematic mindset, albeit an extremely common one.
Must it?
Fish seldom plays the role of “foundational scripting language”. More often it’s the interactive frontend to the rest of your system. This port enables further pursuit of UX and will allow for features I’ve been waiting for for ages
For something like an interactive shell, I generally feel that consistency beats innovation when it comes to real usability. But if there are features that still need to be developed to satisfy the fish user base, I suppose more development is needed. What features have you been waiting for?
https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102
There have been multiple maintainer comments over the years in various issues alluding to the difficultly of adding concurrency features to the codebase. e.g. https://github.com/fish-shell/fish-shell/issues/238#issuecomment-150705108
I think that the “Nobody” and “pain” there may have been referring to the dev team, not so much everyone in the world. In that context it’s a little less outlandish a statement.
It’s also not really outlandish in general. Nobody likes CMake. How terrible CMake is, is a common topic of conversation in the C++ world, and C++ itself doesn’t exactly have a reputation for being the language everyone loves to use.
I say as someone who does a whole lot of C++ development and would pick it above Rust for certain projects.
Recent observation from Walter Bright on how C++ is perceived:
From https://forum.dlang.org/post/uhcopuxrlabibmgrbqpe@forum.dlang.org
That’s totally fine with me.
My retirement gig: maintaining and rescuing old C++ codebases that most devs are too scared/above working on. I expect it to be gross, highly profitable, and not require a ton of time.
C programmers gonna have their COBOL programmer in 1999 moment by the time 2037 rolls around.
And yet, it was the ‘language of the year’ from TIOBE’s end-of-year roundup for 2022, because it showed the largest growth of all of the languages in their list, sitting comfortably at position 3 below Python and C. D shows up down at number 46, so might be subject to some wishful-thinking echo-chamber effects. Rust was in the top 20 again, after slipping a bit.
TIOBE’s rankings need to be taken with a bit of a grain of salt, because they’re tracking a lot of secondary factors, OpenHub tracks more objective things and they’re also showing a steady increase in the number of lines of code of C++ changed each month over the last few years.
TIOBE has +/- 50% error margin and even if the data wasn’t unusable, it’s misrepresented (measuring mentions picked by search engine algorithms over a historical corpus, not just current year, not actual usage). It’s so bad that I think it’s wrong to even mention it with “a grain of salt”. It’s a developer’s horoscope.
TIOBE thinks C popularity has halved one year and tripled next year. It thinks a niche db query language from a commercial product discontinued in 2007 is more popular in 2023 than TypeScript. I can’t emphasize enough how garbage this data is, even the top 10. It requires overlooking so many grave errors that it exists only to reinforce preexisting beliefs.
Out of all flawed methods, I think RedMonk is the least flawed one: https://redmonk.com/rstephens/2022/10/20/top20-jun2022/ although both RedMonk and OpenHub are biased towards open-source, so e.g. we may never learn how much Ada DoD actually uses.
My favourite part about the RedMonk chart is that it shows Haskell going out through the bottom of the chart, and Rust emerging shortly afterwards, but in a slightly darker shade of red which, erm, explains a lot of things.
The rationale provided tracks for me as someone who is about to replace an unpopular C++ project at work with Rust. Picking up maintenance of someone else’s C++ project who is no longer at the company vs. picking up someone else’s Rust project have looked very different in terms of expected pain / risk IME.
“Getting better at C++” isn’t on my team’s dance card but “getting better at Rust” is which helps here. Few working programmers know anything about or understand native build tooling these days. I’m the resident expert because I know basics like why you provide a path argument to
cmake. I’m not actually an expert but compared to most others in my engineering-heavy department I’m as good as it gets. Folks who do a lot of C++ at work or at home might not know how uncommon any thoroughgoing familiarity with C and C++ is getting these days. You might get someone who took one semester of C to say “yeah I know C!” but if you use C or C++ in anger you know how far that doesn’t go.I’m 34 years old and got my start compiling C packages for Slackware and the like. I don’t know anyone under 30 that’s had much if any exposure unless they chose to work in embedded software. I barely know what I’m doing with C/C++ despite drips and drabs over the years. I know enough to resolve issues with native libraries, FFI, dylibs, etc. That’s about it beyond modest modifications though.
tl;dr it’s difficult getting paid employees to work on a C++ project. I can’t imagine what it’s like getting unpaid volunteers to do so.
It does seem weird. We find it easier to hire C programmers than Rust programmers and easier to hire C++ programmers than either. On the other hand, there do seem to be a lot of people that want a project to hack on to help them learn Rust, which might be a good opportunity for an open source project (assuming that you are happy with the code quality of learning-project Rust contributions).
The difficulty is that you need to hire good C++ programmers. Every time some vulnerability or footgun in C++ is discussed, people say it’s not C++’s fault, is just a crappy programmer.
OTOH my experience from hiring at Cloudflare is that it’s surprisingly easy to onboard new Rust programmers and have them productively contribute to complex projects. You tell them not to use
unsafe, and they literally won’t be able to cause UB in the codebase.You might not, but a lot of people do.
I wrote an tool for myself on my own time that I used often at work. Folks really liked what it could do, there’s not a tool like it, and it handled “real” workloads being thrown at it. Not a single person wanted anything to do with it, since it was written in an esoteric language. I’m rewriting it in a “friendlier” language.
It seems like the Fish team thought it through, weighed risks and benefits, have a plan, and have made good progress, so I wish them the best.
Oo which language?
I’d rather not say, I don’t want anyone to feel bad. It’s sufficient to say, “As of today, not in the TIOBE Index top 20.”
The bigger point is that it was a tool I had been using for over a year, which significantly improved my efficiency and quality of life, and it got rejected for being an esoteric tech, even though I provided executable binaries.
That sucks. Yeah, I don’t mean to ask to hurt anyone’s feelings, I’m just always curious to know what people think are “esoteric”, cuz esoteric on lobste.rs (Factor, J, one of the advent of code langs) is going to be very different than esoteric at my job (haskell, rust).
Same here. As a user, it doesn’t bother me in which language it is written in. They should absolutely pick the language that allows them to be more productive and deliver more. I have been an happy fish user for 13 years, it is a software that proved useful from.day one. And every realease there are clear important improvements, often times new UX additions. I wish them a smoot migration.
If you’re curious about the size of the rewriting project: I ran tokei on the repo and it counted 49k lines of C++ 8k lines of headers 1k lines of CMake (and 57k lines of Fish, so there’s also a lot that won’t need to be rewritten)
They posted this little bit later:
The follow up contains:
Which means I still can’t tell the degree to which he’s joking. The idea that a codebase from 2005 is old is mind boggling to me. It’s not even 20 years old. I’ve worked on a lot of projects with code more than twice that age.
To put things into perspective, 2005 to 2023 is 18 years — that is the entire lifespan of the classic MacOS.
Or, to put things into perspective, the Mac has switches processor architectures twice since the Fish project was started.
Most software projects just rot away in 18 years because needs or the surrounding ecosystems change.
Modern macOS is a direct descendent of NeXTSTEP though, which originally shipped in 1989 and was, itself, descended from 4BSD and CMU Mach, which are older. Most of the GNU tools are a similar age. Bash dates back to 1989.
That’s probably true, but it’s a pretty depressing reflection on the state of the industry. There are a lot of counter examples and a lot of widely deployed software is significantly older. For example, all of the following have been in development for longer than fish:
This is the actual world we live in. This is what people really think.
Why does everyone hate CMake so much?
I find it far easier to understand than Makefiles and automake.
Plus it runs on ancient versions of Windows (like XP) and Linux, which is not something most build systems support. And it mostly “just works” with whatever compiler you have on your system.
Makefiles and automake are a very low bar.
Cargo can’t do 90% of the things that CMake can, but it’s so loved, because most projects don’t need to write any build script at all. You put your files in
src/and they build, on every Rust-supported platform. You put#[test]on unit tests, andcargo testruns them, in parallel. You can’t write your own doxygen workflow, butcargo docgives you generated reference out of the box for every project. The biggest criticism Cargo gets about dependency management is that it’s too easy to use dependencies.This convention-over-configuration makes any approach requiring maintaining a DIY snowflake build script a chore. It feels archaic like writing header files by hand.
Why does everyone hate being punched in the face? I find it far more pleasant than being ritually disemboweled.
CMake is three things:
If the things that you want to do are well supported by the core functionality then CMake is fairly nice. If it’s supported by existing packages, then it’s fine. If it isn’t, then extending it is horrible. For example, when using
clang-cl, I was bitten by the fact that there’s hard-coded logic in CMake that adds the /TC or /TP flags to override the language detection based on the filename and tell it to use C or C++. This made it impossible to compile Objective-C. A few releases later, CMake got support for Objective-C, but I can’t use that support to build the Objective-C runtime because it has logic in the core packages that checks that it can compile and link an Objective-C program, and it can’t do that without the runtime already existing.I’ve tried to use CMake for our RTOS project, but adding a new kind of target is incredibly hard because CMake’s language is really just a macro language and so you can’t add a new kind of object with properties of it, you are just using a macro language to set strings in a global namespace.
I’ve been using xmake recently and, while there’s a lot I’ve struggled with, at least targets are objects and you can set and get custom properties on them trivially.
Only versions no one wants to run anymore (i.e. 3.5 and older).
its an entire set of new things to learn and it generates a makefile so I worry that I’ll still have to deal with the problems of makefiles as well as the new problems cmake brings