Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Porting 58k lines of D and C++ to Jai

yet-another-blog.com

Post reply on HN
Print view View original

241–250 of 264 posts

Re: Porting 58k lines of D and C++ to Jai

#241

Post by Tozen »

hardwaregeek wrote: post #196
aeturnum wrote: post #6

I'm really interested to see Jai in the wild, but I have to say I find the Jai v.s. Rust comparison here...unconvincing to say to least. It's particularly funny to be excited about "being able to do anything during compilation" using Jai and then complain to that the #1 problem in programming is "culturally tolerated and even encouraged complexity."

I'm also frustrated at a language in closed beta being perpetually compared to a language that is open source and in production. It's a complete apples to oranges comparison. By being in closed beta, there is no way of verifying anything said about Jai. Instead you have to take the word of people in the Jai community, which is a very biased source to say the least.

Very good point, which partially alludes to the hype. It is amazing how much publicity that Jai is getting, despite being in a closed beta. It brings up the argument that if it were open to the public, with more eyes and critics on it, would the "hype train" crash? Odin (https://odin-lang.org/), a near category language, that is influenced by Jai and is open to the public, does not appear to be getting anywhere near the recognition.

To what extent does Jonathan Blow's status as a celebrity programmer, plays into all of this? As in, people want Jai to be the "next big thing", versus the actual merits of the language.

Re: Porting 58k lines of D and C++ to Jai

#242

Post by tialaramex »

throw827474737 wrote: post #224
ibiza wrote: post #108

> a big chunk of these vulnerabilities would not exist if C and C++ [...] simply didn’t have zero-terminated string, initialized values by default, had a proper pointer+length type thus replacing 90% of pointer arithmetic with easily bounds-checkable code, and had established a culture that discouraged the prevalent ad-hoc style of memory management. This is Rust's calling-card, so I find this plea for a better lang…

Yes and no. No because Rusts bigger calling card is the borrow checker, which adds a lot of complexity besides other things in Rust, and even leads to justifying unsafe (because some optimized correct data structures are just not possible with it). Second no, because if Rust calling card is that, you can have this alone even in the most hated unsafe C++ if you limit yourself and admit to doing it right. If you quote…

> not even being able to get fully rid of unsafe..

It makes no sense to "get fully rid of unsafe" and this suggests you've gravely misunderstood the problem. Which puts you in good company, Herb Sutter doesn't seem to understand this on his "CppFront" wiki and Bjarne doesn't seem to grasp it in his recent paper about safety either.

Rust's unsafe keyword marks code which programmers intend to be safe but the machine can't see that. For example the Rust compiler can't see why the Linux implementation of Mutex is correct, why would we give out mutable references to anybody who calls this function named "lock" ? The programmers (in this case mostly Mara) know how the Linux futex system call works and their reviewers have concluded the resulting unsafe stanzas, with their commentary, are correct. There will in fact only ever be one mutable reference at a time even though the machine can't see why.

The reason to care so much about memory safety is that you can't have type safety without memory safety, and when you lose type safety most of your other guarantees are destroyed. Languages which claim to care less about memory safety often have a caveat (even if unstated) that all bets are off once you abuse their lack of memory safety to destroy type safety because all their other promises assumed type safety and now they don't have that.

Re: Porting 58k lines of D and C++ to Jai

#243

Post by menaerus »

School-Cotton wrote: post #187
johnisgood wrote: post #167

Earlier quoted context omitted.

I highly doubt so. Rust is extremely complex and restrictive. For actually critical software, there is Ada/SPARK.

Rust is much easier and less complex than C++, which is very widely used.

Very doubtful. My impression is that devs coming from non-C++ background are having a hard time to grasp the concepts of Rust.

Re: Porting 58k lines of D and C++ to Jai

#244

Post by int_19h »

flohofwoe wrote: post #218
int_19h wrote: post #176

Earlier quoted context omitted.

Spans/slices are getting incredibly common in as a fundamental building block in modern (or modernized PLs). C# also has Span , Go and Rust both have slices etc. We are at the point where they should be standardized on ABI level, IMO, before things get too messy compatibility-wise.

For a C API, a slice would be a simple { void*, size_t } or { void*, void* } struct, but I guess for memory managed languages this isn't enough information to pin the underlying data into memory (for instance a reference to the underlying 'object' - don't know how such language-specific details could ever be expressed in a 'standard ABI').

Oh, it's simple enough, even with managed languages in the picture - it just needs to be decided once, and then everybody uses it.

The problem is that many existing ABIs don't optimize for small structs as function arguments particularly well, so just bolting it on like that can mean poor performance compared to old-school separate arguments for pointer and length. You want a hard guarantee that something like foo(slice1, slice2) will be passed entirely in the registers, not as two pointers-to-stack.

Re: Porting 58k lines of D and C++ to Jai

#245

Post by naikrovek »

klodolph wrote: post #236
naikrovek wrote: post #207

Earlier quoted context omitted.

it isn't anti-intellectualism at all, it's that he gets asked questions by people in college as well as college grads continuously and the questions they ask are indicating that the things being taught in higher education are absolutely not the kinds of things that he sees in his day to day work. to be fair to Jon, he works in a subset of software development that most do not: video games. the kinds of problems that…

I think I’ve never heard someone romanticize a profession as hard as what you’ve done here. This comment paints a truly distorted and unrealistic picture of game developers. Game developers are not radically different from other developers. You see game developers leave the game industry and become programmers somewhere else, or you see programmers in another industry become programmers in the game industry. It is no…

never in my 30-year career have I witnessed a single non-game developer give a damn about the latency or responsiveness of any application they've written.

never in my 30-year career have I witnessed a single game or emulator developer STOP caring about these things.

> I think I’ve never heard someone romanticize a profession as hard as what you’ve done here.

Go fuck yourself. it isn't me romanticizing, it's you thinking you know more than others by default, and outright dismissing the viewpoint of others. go away from me and stay away.

Re: Porting 58k lines of D and C++ to Jai

#246

Post by andrekandre »

tragomaskhalos wrote: post #215
klodolph wrote: post #85

Earlier quoted context omitted.

I think Ruby and RoR just didn’t quite survive the transition to much heavier client-side JavaScript apps. Ruby peaked sometime around 2009 and back then, the browser landscape was much more diverse, and it was common to support IE6. It’s easy to forget how much of a burden IE6 was on web developers. Ruby also suffered from a proliferation of ill-advised programming practices (monkey patching) and there was also some…

I transitioned from Ruby to Python for scripting tasks, with a heavy heart, for the simple reason that linuxes typically have Python installed by default, but not Ruby, which made working with and sharing Ruby code in diverse and often locked-down environments too painful.

> linuxes typically have Python installed by default, but not Ruby

interesting, i wonder why?

Re: Porting 58k lines of D and C++ to Jai

#247

Post by BenFrantzDale »

tialaramex wrote: post #184
BenFrantzDale wrote: post #163

Earlier quoted context omitted.

This is also C++20’s calling card. It has `std::span`.

But remember all C++ defaults are wrong, and so of course std::span isn't bounds checked While your Rust slice will yell at you (at runtime if it can't figure it out at compile time) when you try to index into the fifteenth item in a ten item slice, C++ has Undefined Behaviour in this case.

True. I love C++ but think “don’t pay for what you don’t use” should err on the side of safety over speed when it comes to what “pay” means. I’d rather `operator[]` be bounds-checked and occasionally have to call `v.data()[i]` or `v.unchecked_at(i)` when profiling justifies it.

Re: Porting 58k lines of D and C++ to Jai

#248

Post by BenFrantzDale »

bartwe wrote: post #233
flohofwoe wrote: post #220

Earlier quoted context omitted.

That's just by convention though, right? C++ doesn't prevent me from storing the std::span somewhere so that it outlives the scope of the called function? IMHO it's disappointing that C++ adds new memory management footguns without first fixing the basics (like at least some rudimentary lifetime tracking to help with such situations).

c# got this right, enforcing the lifetime of Span

I keep considering writing a `unique_span` and `shared_span`. Really `span` or (a type it’s based on) should have been templated on the pointer type, so a `span>` for example.

Re: Porting 58k lines of D and C++ to Jai

#249

Post by tialaramex »

int_19h wrote: post #176
BenFrantzDale wrote: post #163

Earlier quoted context omitted.

This is also C++20’s calling card. It has `std::span`.

Spans/slices are getting incredibly common in as a fundamental building block in modern (or modernized PLs). C# also has Span , Go and Rust both have slices etc. We are at the point where they should be standardized on ABI level, IMO, before things get too messy compatibility-wise.

There are interesting differences in these types worth thinking about if you're imagining try to standardize them somehow.

C++ std::span pulls double duty, one flavour of std::span, the one you might see more often, is like Rust's slice type [T] in that it consists of zero or more values of some type T. The other though is more like Rust's array type [T; N] where the size N of the span is actually part of the type itself.

Rust's slice is specifically that [T] type, the type system doesn't see any more difference between a [u32] with 1000 entries and a [u32] with 0 entries than it would between a string with "DOG" in it and a string with "CAT" in it, their types are identical.

C# Span deliberately can't live on the heap. The CLR doesn't want to cope with this type, and by ensuring it's part of your program's stack any questions about the lifetime of the Span are obviated and tricky-to-reason about garbage collection problems don't arise.

Go's slices are very strange because Go's arrays are like those in Rust, their size is part of their type - and yet Go's slices can append. This is achieved by actually creating a new array and copying all the data for the slice into the new array whenever Go sees fit.

Re: Porting 58k lines of D and C++ to Jai

#250

Post by tialaramex »

Tozen wrote: post #241
hardwaregeek wrote: post #196

Earlier quoted context omitted.

I'm also frustrated at a language in closed beta being perpetually compared to a language that is open source and in production. It's a complete apples to oranges comparison. By being in closed beta, there is no way of verifying anything said about Jai. Instead you have to take the word of people in the Jai community, which is a very biased source to say the least.

Very good point, which partially alludes to the hype. It is amazing how much publicity that Jai is getting, despite being in a closed beta. It brings up the argument that if it were open to the public, with more eyes and critics on it, would the "hype train" crash? Odin ( https://odin-lang.org/ ), a near category language, that is influenced by Jai and is open to the public, does not appear to be getting anywhere nea…

One of the things people get excited about is meta-programming, which Jai has much more of than Odin.

Jai has a lot more weird stuff than Odin. Idiosyncratic features like if we're iterating through a sequence we can delete items as we go with a dedicated keyword, via a swap and shrink mechanism. Perhaps some of that weird stuff will be smoothed off during beta, or perhaps Jon will double down on it. But it does make Jai more interesting to talk about meanwhile than Odin which is a more "normal" language design.

I suspect I will never have reason to use either language "in anger" so to speak, but Jai is more interesting to me for the reasons I stated.

Post reply on HN