TwentyPosts

>Instead of "everything is a file", "everything implements well-documented object-oriented interfaces" would be much better idea. Why "object-oriented" specifically? Is this in any sense different from non object-oriented interfaces, eg. Rust's traits or Go's interfaces, or just to make it more clear that you're talking about interfaces in the programming languange sense?

Saying that the determinant is useless to determine whether a matrix is incorrect, or misleading at best.

This is purely a matter of numerical stability. Of course [[1e-10, 0], [0, 1e-10]] is nonsingular, and its determinant is 1e-20, which does not equal zero.

Yes, when it comes to floating point issues we might want to use something else, and that's a valid complaint when it comes to NumPy code, but from a theoretical perspective the determinant is an excellent tool to determine singularity.

Rust does it pretty well. No error handling via exceptions, it's all Result<Ok, Err> or Option<Value> types.

This is great since it's enforced on a type-level that every result or option has to be unwrapped before it can be used. Unwrapping is explicit, the code panics if something goes wrong, and the function signature makes it easy to see what sort of errors to expect (especially when using custom error enums for the Err value).

There is one major caveat here, which is that Rust's type system only forces you to check for errors if you plan to use the return value of a function.

An example: You have a function write(), which writes to a file, and which returns Result<(), Err>. (Here `()` is the zero-sized type, ie. an empty tuple).

If you call this function in your code, it might return an error, but you can just silently drop this error. Your linter is going to complain, though. This issue could be fixed with proper linear types (ie. types which must be used once), but adding them to the language would afaik be really difficult at this point.

But other than that Rust is doing pretty well, honestly, and (imo) Go would be a significantly better language if it had a proper Result type, and just used it for all of its error-handling. Sadly, we can't change history.

I'm going to be pedantic here, but this merely means that Go can't fill Zig's niche.

Zig can (in a lot of situations) presumably easily fill Go's role. Both languages have a focus on simplicity and explicit syntax.

In other words, Zig is in fact a decent alternative to Go. Go just isn't a good alternative to Zig.

Personally, I found "Writing an Interpreter in Go" better than "Crafting Interpreters". It has a follow-up book titled "Writing a Compiler in Go", which (similar to Crafting Interpreter's second half) implements a virtual machine. The books take a lot of inspiration from Crafting Interpreters.

If this sounds at all appealing to you, I would check it out. I found Monkey so far somewhat more compelling than Lox (might be personal preference, though), and I thought the exposition (and code quality) was overall better. Go is also very easy to pick up.

Can't say much about async, since I really lack the experience to say whether async in Rust could feasibly and realistically be much better than it currently is. Some people say that it'd be great if it worked as effortlessly as in Go, but I assume that you don't get to have that without performance tradeoffs.

As for lifetimes, what's the issue? Do you have any reason to believe lifetimes are frustrating because they were badly designed, rather than the fact that they're making complexity explicit which was previously hidden?

Will Rust keep growing? Yes, I think so.

Will it turn into a C++-like monster? I don't know. Maybe, but when it comes to C++ it always feels like its "monster" status is largely a result of previous mistakes or early design decisions piling up, and causing trouble (eg. C-style arrays, exceptions, implicit conversions, fiddly sum types rather than first class support, no pattern matching etc.).

Rust will grow large, and probably complicated, but the real issue with C++ are all these past mistakes and a shaky foundation, and Rust is doing much, much better in that regard. Time will tell if we'll eventually look back some of Rust's design decisions as bad or unwieldy (probably).

Afaik Zig has the issue that basically everything happens on the Discord server, where it can't be indexed via search engines, or found by anyone who wants to have a quick question answered. This would be "fine" if the standard library and language were much better documented, but it isn't, and it's still ripe with bugs.

In other words, you're forced to use the Zig Discord server if you want to find answers to any simple questions, and this is (sadly) not obvious at all to newcomers to the language.

I am not much of a Zig-head, but the best compromise I can think of is having a few operators which purely and solely exist for this purpose. In other words, there is no operator overloading, but you can define, say, "#+" for any two structs, or something like that.

So if you want to encode matrix multiplication, then you'll always have to write `mat1 #* mat2`. This feels like a hack, and isn't all that elegant, but it'd be clear that every usage of such an operator is a disguised function call. (And according to what Andrew Kelley said, it's all about not hiding function calls or complex operations in seemingly innocent 'overloaded' symbols.)

If you want to take this one step further you'd probably have to allow users to define infix functions, which would be its own can of worms.

Honestly, I am not particularly happy with any of these ideas, but I can't think of anything better either!

I think they were making a joke, namely that it looks like an arrow, even though it's presumably supposed to look like an envelope.

The fact that we're talking about it shows that this is in fact a minor(?) design flaw. Ideally it should be obvious that it is an envelope, not an arrow, so that a user who's never seen the logo before immediately knows what it represents.

It's okay? I think what bothers me the most about it is that the envelope is smaller, and not front and center anymore. I get that the idea was to make it look more like the Firefox logo, and it succeeds in that regard, but I liked that the envelope was the big, rectangular thing which dominated the logo. That's what my eyes are looking for and expect if I'm searching for 'the mail program' on my desktop or phone or anywhere.

Mojo bothers offers Just-In-Time and Ahead-Of-Time models. Proper AOT compilation is going to offer a significant speedup, but probably not enough to get to their stated goals. And good luck carrying all of Python's dynamic features across the gap.

Somehow I'm still skeptical! Feels like "strict superset of Python, all Python code works" and "several orders of magnitude faster" just sounds like you're trying to have your cake and eat it, too.

I doubt that the Mojo developers have some sort of 'secret sauce' or 'special trick' that will get them there. And even if they have something, I don't see why the Python devs wouldn't just implement the same approach, considering they're currently trying to make Python faster.

I assume that (as long as Mojo wants to stick to its goal of being a strict superset of Python), there will be a lot of things that just cannot be 'fixed'. For example, I'd be surprised if Python's Global Interpreter Lock isn't entangled with the language in a few nasty ways that'd make it really difficult to replace or improve upon (while retaining compatibility).

Then again, the developer of Swift is working on it, right? I guess he's got the experience, at least.

There is some work in the area: https://www.sciencedirect.com/science/article/pii/S258900422...

Disclaimer: I have not read the paper, so I can't judge about its contents.

> Another story is that some people pointed out a missing feature - moving lines or blocks of text up and down, as more advanced IDEs do. I volunteered to implement this feature, however I'm getting impression that the community is a bit puristic when it comes to features like that, based on feedback I get.

Wait, what does this add? I feel like in Helix I would just select a bunch of lines (say, via treesitter or the x command), and then I'd delete them, and paste them somewhere else. Could you elaborate what the difference is between this and 'moving lines or blocks of text up and down'?

A cynical view is that 80% of Go's success is a result of the excellent tooling, and the fact that it's associated for and pushed by Google, while the underlying language is "mediocre" at best.

In theory I agree with Go's minimalist perspective, it just also feels inconsistent, and like they made a whole lot of bad decisions along the way. Favoring C-style enums over proper sum-types is one of the biggest one, and ties into Go's error handling, which continues to be a major talking point.

What are some of these pitfalls in C++'s const design? I assume the issue is that it's difficult to guarantee const correctness as long as you have the ability to fiddle with pointers?

Function signatures showing when a parameter gets modified and when not (such as in Rust, or even in properly const-speckled C++) would benefit Go, but I'm not sure how difficult it'd be to implement that. I could see it being difficult considering that one of Go's core features (slices) results in opaque and overlapping memory ownership.

Any idea of how much faster we're talking here?

I'm not. I'm a new user, and I notice that Duolingo kind of sucks, but I am getting some amount of value out of it. I'm very open to suggestions for better language learning apps, though.

As someone who didn't like the idea of learning a language at all but has to, I'm glad that Duolingo gave me a very, very easy way to get started with literally anything at all. It's simple and streamlined, meaning that it's easy to start and stick with it instead of getting hung up on how to find a good textbook, or figuring out how to use Anki "properly".

This also applies to practicing every single day: I find it easy to do a few Duolingo "lessons" as warm-up before delving into more in-depth practice.

Nowadays I would not use it for real "practice" at all. I use it to check my understanding for 5-15 minutes a day. If I make mistakes in Duolingo (eg. forming the plural, remembering the dative for a given grammatical gender) then I look these things up and study them.

I might drop Duolingo completely at some point, but for now I'm getting a non-zero amount of value out of it—I am increasingly looking into better options, though. I'm already looking Anki, and I'm sure there are some other language learning apps out there.

This is also what I'd call the classic issue with Duolingo. Or rather, one of them, considering that the app has all sorts of issues.

If you use nothing but Duolingo you'll plateau very quickly. It's probably "okay" as a casual side spaced-repetition learning tool—when you're learning languages you generally want to pull from several different resources, and learn with different tools anyway. But don't make the mistake of thinking that Duolingo alone will get you anywhere.

I think this universally applies to repetition-learning, at least when it comes to languages. You need to "cross-train".

Go has no way to ensure "const correctness". If you pass around a slice (which you'll be doing a lot, since it's essentially Go's equivalent of a vector), everyone can modify the slice however they please. It's just a fat pointer.

So yes, something which should be treated as immutable.

The way Go works here easily leads to bugs, especially when concurrency is involved and slices get captured or used by goroutines.

If you send a slice to a function, they essentially receive a pointer pointing at the same block of memory as in your calling function. They can modify it. If they append to the slice, however, and surpass the capacity of the slice they received, then their slice gets reallocated and doesn't point at the same block of memory anymore.

In other words, if you receive a slice, append to it, and then change the first value of the slice, then this might modify a slice (or array) somewhere completely different, depending on whether your append surpasses the allocated capacity of the slice or not.

Welcome to Golang.

Wow, this entire thinkpiece is frankly incredibly annoying to me. Vast amounts of staggering, amazing music are being made. The issues which he is describing are rather just a loss of a "universal" major label music culture.

We've got artists revolutionizing their own respective niches, this all just happens in complete disconnect from major label music, and from the general mainstream.

The fact that he goes through the entire article without even bringing up examples of modern artists which impressed or didn't impress him is weak. No mention of the windmill scene (eg. black midi and black country, new roads)? No mention of King Gizzard and the Lizard Wizard, who gained some amount of fame for releasing five (5!) really solid albums in a single year? No mention of Death Grips, who revolutionized modern hip hop music? These are all names which should be familiar if you're paying attention.

Instead he brings up Drake (and Kendrick, to be fair) as an example of "artists setting the bar incredibly high" and "setting new trends for new generations".

Either way, I'd hate to have this guy on my party.

> A special “I would never write Rust like that” variant that returns the value in a Box on the heap. This is because a friend of mine, after seeing my results, told me I was cheating, because all Rust versions so far used registers/stack to return the value, and Java was at a disadvantage due to returning on the heap (by default). Uhh, okay? This sounds a bit silly to me. It's good to add the additional comparison, sure, but "cheating" is just not the right word. The point of this article is ostensibly to compare the built-in Option types, not heap allocation. The fact that Java allocates any Options on the heap is part of that comparison (and reflects badly on Java, fwiw).

Either way, glad to see that Rust is doing a good job eliminating the overhead. I'm not sure if arithmetic is the right kind of benchmark here, but it'd probably be difficult to measure the performance overhead across "real" codebases, so focusing on a tight loop microbenchmark is probably fine.

I think it's great. I picked it up on a whim, and it then managed to turn into my default (code) editor. The good: -Closeness to Vim and the floating option menu (if you eg. press g, it shows you what options you have in the lower right of the screen) make it really easy to learn and be productive with -Some amazing defaults. m (for select inner word, delimiter, function, class, etc.) is great, the multi-cursor mode is absolutely amazing and wipes the floor with Vim's "search and replace" functionality for all sorts of reasons. -Multi-cursor mode and the s-key (take a selection, filter by regex) is absolutely amazing in general. Makes it incredibly easy to perform repetitive edits. -All sorts of stuff just works -Built in treesitter for movements and highlighting, and built-in LSP support which works great -Helix makes NeoVim look old and crufty. When loading NeoVim it was common to run into annoyances with plugins, where it felt like various plugins or functionalities are "fighting" each other over control. Helix feels very slick and modern in comparison, -you don't need 90% of the classic vim plugins most people use, since they're already built into the program

The bad: -Still lacks certain features, apparently softwrapping lines at screen-width is currently being worked on, and that's a feature I've been waiting for -Can't do some of the fancy stuff you can do with vim plugins, eg. LaTeX support with PDF-viewer connection, or Jupyter notebooks, or whatever sort of highly specific thing you might want to do -Not as good at editing plaintext as Vim. Vim has eg. das ~ "delete as sentence", Helix doesn't. Couple that with lack of softwrapping (for now), and it's a pain

It's pretty great, and I see no reason not to use it. I run into situations where Helix isn't suitable (eg. LaTeX or plaintext), and then I just switch to regular NeoVim. The keybinds are close enough that it's easy to switch back and forth

So... has anyone used this thing to build projects that go beyond small toy examples?

Speaking of, what are some good 'example projects' to test the overall sturdiness of a new language? I have currently no interest in writing one in Austral, but I'm always curious to hear how well modern language projects work out when used in production.

As far as I heard the V programming language is largely considered to be Vaporware (see eg. https://xeiaso.net/blog/vlang-update-2020-06-17, and other articles by Xe).

I agree that I (in theory) quite like some of the design decisions, but as far as I know nothing of this actually works in practice. Like, it's not even close to being production ready, and people are seriously doubting whether the language will ever even come close to being a viable option.

I'm not up to date on all of the issues (in the code or in the community), but the last thing I heard is that the developers of V are still working on the "auto-free" memory management model (which is supposed to infer when 'free' needs to be called), but it's not working (and afaik proven to be undecidable in general).

Edit: Another reason why I'd be rather skeptical of this language is the claims it makes on the 'Compare' page: https://vlang.io/compare

It starts off stating that "V was created because none of the existing languages had all of the following features:" and then goes and lists an incredibly ambitious list of features, which essentially amount to "As safe as Rust, but Go's simplicity and fast-compilation time, and a small compiler with zero dependencies", and more. These are hard problems, especially if you're also working on developing an experimental memory management technique.

Having used Cold Turkey before, I can confirm that it's really good at doing what it set out to do (though I have a few annoyances with it, since there are a few things it doesn't allow me to do). What's impressive about it is that it is quite difficult to bypass it, and all of the naive approaches just won't work (eg. uninstalling it or switching to a different account).

I wish there were a Linux equivalent of it, but nowadays I don't need it as much as before anyway—I'm not sure if that's complacency, or if I just got better at focusing.

I would not be surprised if people downvote this sort of comment since—no matter the predictions—it seems like an attempt to piggyback off the parent post to make more people see your own post when just posting a top-level comment would have been more appropriate. Not trying to imply intent, though.

Here's a kind of dumb question:

Are the primary usecases of this for SSH, or for non-tiling desktop environments? People say a lot of good stuff about it, but I struggle to figure out what it can do for me when I'm just doing stuff on a local computer, where I can just create new terminal windows.