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

211–220 of 264 posts

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

#211

Post by teleforce »

klodolph wrote: post #85
Keyframe wrote: post #55

Earlier quoted context omitted.

Javascript absolutely took its position. Speaking of those waves, where did Ruby and RoR go? Seems completely dead on HN whereas 'back in the day' it was top most talked thing. LISP would be a guest of honor - always there, never here.

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…

Ruby and Python is not interchangeable, and Ruby is way more powerful than Python, that's a real reason why there is no equivalent of RoR in Python eco-system [1].

Python becomes very popular not by virtue of its tools, but by virtue of its intuitive and beginner friendly syntax. Because of this essential trait the useful tools and libraries are flourishing in the Python eco-system.

You are right that RoR is like a Ghetto and RoR is not considered as Ruby language. On this aspect, I think D has done a good job to ensure that any D based library and framework will still resemble D language. Like they said with great power comes great responsibility, and I'm afraid that Jai will follow Ruby and Lisp becoming untouchable by the mere mortals except only for a selected few domain expert programmers maintaining very niche applications.

[1]Stop Designing Languages. Write Libraries Instead:

http://lbstanza.org/purpose_of_programming_languages.html

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

#212

Post by WalterBright »

ibgeek wrote: post #206
WalterBright wrote: post #202

Earlier quoted context omitted.

D isn't a GC based language. The GC can be used, or not used, as the user chooses. D supports many different programming paradigms.

Ah! Okay, that’s what I was missing. I found the blog posts on using malloc and free from D. I knew the GC could be disabled, but I wasn’t aware of how practical it was to manually manage memory. Thanks!

It's not necessary to disable it, just don't use it.

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

#213

Post by dmitriid »

nomel wrote: post #62
naikrovek wrote: post #57

Earlier quoted context omitted.

> Why not just use the best ecosystem like Unreal/Unity laughable. absolutely laughable. I'm not even talking about politics of using an engine versus writing one; unity and unreal are complex tools with their own problems. if you value what you are producing, and if you value quality and you want your game to be just the way you want it, Unity and Unreal will fight you just as hard as D or C++ have been for the blog…

Could you give an examples of a game that used a custom game engines that couldn’t achieve what they wanted in Unreal or Unity? Edit: The only style I would think would be infinite/strange geometry, like Manifold garden (great game!). But, it’s Unity.

> Could you give an examples of a game that used a custom game engines that couldn’t achieve what they wanted in Unreal or Unity?

A game that doesn't require a multi-gigabyte download and a top-tier GPU and CPU to render stuff in 2D? ;)

There are many reasons people might want to opt out of existing game engines: full control over rendering pipelines, assets and dev. experience might be some of them.

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

#214

Post by mort96 »

Ar-Curunir wrote: post #183
ablob wrote: post #147

Earlier quoted context omitted.

Template metaprogramming in the absence of constexpr/concepts would be my guess.

Traits are more restricted in what they can do than Templates, so the original quote does not apply here

Template metaprogramming is the idea of executing arbitrary logic at compile time using the template system as your programming language. The replacement for template metaprogramming is a solid compile-time execution model, not a traits system.

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

#215

Post by tragomaskhalos »

klodolph wrote: post #85
Keyframe wrote: post #55

Earlier quoted context omitted.

Javascript absolutely took its position. Speaking of those waves, where did Ruby and RoR go? Seems completely dead on HN whereas 'back in the day' it was top most talked thing. LISP would be a guest of honor - always there, never here.

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.

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

#216

Post by raverbashing »

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.

> But remember all C++ defaults are wrong

Honest truth right here.

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

#217

Post by flohofwoe »

BenFrantzDale wrote: post #163
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…

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

Is a C++ std::span object like std::string_view in that it can outlive the data it points to? If yes, that's hardly an improvement over a raw C pointer/size pair.

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

#218

Post by flohofwoe »

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.

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').

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

#219

Post by frozenport »

flohofwoe wrote: post #217
BenFrantzDale wrote: post #163

Earlier quoted context omitted.

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

Is a C++ std::span object like std::string_view in that it can outlive the data it points to? If yes, that's hardly an improvement over a raw C pointer/size pair.

Its an "input only" type, aka don't return it, but use it as an argument

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

#220

Post by flohofwoe »

frozenport wrote: post #219
flohofwoe wrote: post #217

Earlier quoted context omitted.

Is a C++ std::span object like std::string_view in that it can outlive the data it points to? If yes, that's hardly an improvement over a raw C pointer/size pair.

Its an "input only" type, aka don't return it, but use it as an argument

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).
Post reply on HN