[HN Gopher] Four Years of Jai (2024)
___________________________________________________________________
Four Years of Jai (2024)
Author : xixixao
Score : 116 points
Date : 2025-04-15 23:17 UTC (2 days ago)
(HTM) web link (smarimccarthy.is)
(TXT) w3m dump (smarimccarthy.is)
| IshKebab wrote:
| Hard to see how this will compete with Zig.
| ramon156 wrote:
| Hard to see this compare at all without examples, but I'll stay
| patient
| troupo wrote:
| Well, they promise to release a full commercial game engine
| alongside it, so that might help :)
| rc00 wrote:
| I can see the appeal if there is a need for stronger
| metaprogramming. Not that Zig is terrible in this area, it is
| just that Jon's language is much more powerful in that area at
| this stage.
|
| That being said, I do see an issue with globally scoped
| imports. It would be nice to know if imports can be locally
| scoped into a namespace or struct.
|
| In all, whether it's compete or coexist (I don't believe the
| compiler for Jon's language can handle other languages so you
| might use Zig to compile any C or C++ or Zig), it will be nice
| to see another programming language garner some attention and
| hopefully quell the hype of others.
| sph wrote:
| Surprising deep and level headed analysis. Jai intrigues me a
| lot, but my cantankerous opinion is that I will not waste my
| energy learning a closed source language; this ain't the 90s any
| more.
|
| I am perfectly fine for it to remain a closed alpha while
| Jonathan irons out the design and enacts his vision, but I hope
| its source gets released or forked as free software eventually.
|
| What I am curious about, which is how I evaluate any systems
| programming language, is how easy it is to write a kernel with
| Jai. Do I have access to an asm keyword, or can I easily link
| assembly files? Do I have access to the linker phase to customize
| the layout of the ELF file? Does it need a runtime to work? Can I
| disable the standard library?
| mjburgess wrote:
| Iirc, pretty sure jblow has said he's open sourcing it. I think
| the rough timeline is: release game within the year, then the
| language (closed-source), then open source it.
|
| Tbh, I think a lot of open source projects should consider
| following a similar strategy --- as soon as something's open
| sourced, you're now dealing with a lot of community management
| work which is onerous.
| xigoi wrote:
| > as soon as something's open sourced, you're now dealing
| with a lot of community management work which is onerous.
|
| This is a common misconception. You can release the source
| code of your software without accepting contributions.
| mjburgess wrote:
| I don't think the issue is just contributions. It's the
| visibility.
|
| When you're a somewhat famous programmer releasing a long
| anticipated project, there's going to be a lot of eyes on
| that project. That's just going to come with hassle.
| diggan wrote:
| > That's just going to come with hassle.
|
| Well, it is the public internet, people are free to
| discuss whatever they come across. Just like you're free
| to ignore all of them, and release your software Bellard-
| style (just dump the release at your website, see
| https://bellard.org/) without any bug tracker or place
| for people to send patches to.
| sesm wrote:
| One is also free to not provide the food for discussion,
| that's the choice jblow made.
| codr7 wrote:
| Timing IS important, releasing too early can kill public
| opinion on a project.
| ModernMech wrote:
| So can announcing too early. See: Duke Nukem Forever. Or
| in the language domain, V-lang.
| tialaramex wrote:
| Having a lot of eyes on it is only a problem if you
| either have a self-esteem problem and so the inevitable
| criticism will blow you up or, you've got an ego problem
| and so the inevitable criticism will hurt your poor
| fragile ego. I think we can be sure which of these will
| be a problem for Jonathan "Why didn't people pay $$$ for
| a remaster of my old game which no longer stands out as
| interesting?" Blow.
| stinkbutt wrote:
| yep and JBlow is a massive gatekeeper who discourages
| people from learning programming if he doesn't believe
| they can program the way he thinks a programmer should.
| He is absolutely running from any criticism that will
| hurt his enormous yet incredibly fragile ego.
| mkzetta wrote:
| The hate he is receiving is bizarre. It takes guts to be
| opinionated - you are effectively spilling your mind (and
| heart) to people. And yet some people will assume the
| worst about you even if it's an exact inversion of the
| truth.
| ModernMech wrote:
| Opinionated people are polarizing, it makes perfect
| sense.
| mkzetta wrote:
| He routinely livestreams himself working on the language.
| He doesn't seem afraid of attention.
| 0x1ceb00da wrote:
| There is a lot of experimentation going on as well. Few
| months ago 2 new casting syntaxes were added for users to
| evaluate. The plan is to keep only one and remove the
| others before release.
| perching_aix wrote:
| It's not a "misconception". Open source implying open
| contributions is a very common stance, if not even the
| mainstream stance. Source availability is for better or for
| worse just one aspect of open source.
| echoangle wrote:
| It is a misconception. Open source doesn't mean the
| maintainer needs to interact with you. It just means you
| can access the code and do your own fork with whatever
| features you like.
| xigoi wrote:
| Would you say that SQLite is not open source?
| perching_aix wrote:
| Yes. I'd call it source available instead. Although it
| does have some hallmarks of open source, such as its
| funding.
| steveklabnik wrote:
| Source available is already a well understood term that
| does not mean this.
|
| https://en.wikipedia.org/wiki/Source-available_software
| perching_aix wrote:
| Reading the preamble there, and the parapgraph after
| that, I find what I said to be consistent what the page
| is saying there.
| steveklabnik wrote:
| > Any software is source-available in the broad sense as
| long as its source code is distributed along with it,
| even if the user has no legal rights to use, share,
| modify or even compile it.
|
| You have the legal right to use, share, modify, and
| compile, SQlite's source. If it were Source Available,
| you'd have the right to look at it, but do none of those
| things.
| perching_aix wrote:
| But _not necessarily_ any of the other things! Big
| difference. Please read it again.
| steveklabnik wrote:
| That's your assertion, I am saying that it is not correct
| in the general way that people understand the terms "open
| source" and "source available."
|
| I doubt we're going to come to an agreement here, though,
| so I'll leave it at that.
| johnisgood wrote:
| > even if the user has no legal rights to use, share,
| modify or even compile it.
|
| Emphasis on _even_. It can have such rights, or not, the
| term may still apply regardless.
| worthless-trash wrote:
| Open Source definition ( https://opensource.org/osd )
| says nothing about community involvement or accepting
| contributions. It may be common, but it is not necessary,
| required or even hinted at in the license.
|
| Open source is not a philosophy, it is a license.
| perching_aix wrote:
| For many it is very much a philosophy, a principle, and
| politics. The OSI is not the sole arbiter of what open
| source is, and while their definition is somewhat
| commonly referred to, it is not the be all end all.
| chii wrote:
| > without accepting contributions.
|
| it's not even contributions, but that other people might
| start asking for features, discuss direction independently
| (which is fine, but jblow has been on the record saying
| that he doesn't want even the distraction of such).
|
| The current idea of doing jai closed sourced is to control
| the type of people who would be able to alpha test it -
| people who would be capable of overlooking the jank, but
| would have feedback for fundamental issues that aren't
| related to polish. They would also be capable of accepting
| alpha level completeness of the librries, and be capable of
| dissecting a compiler bug from their own bug or misuse of a
| feature etc.
|
| You can't get any of these level of control if the source
| is opened.
| lifthrasiir wrote:
| You can simply ignore them. This worked for many smaller
| programming languages so far, and there exist enough open
| source softwares that are still governed entirely by a
| small group of developers. The closedness of Jai simply
| means that Blow doesn't understand this aspect of open
| source.
| worthless-trash wrote:
| I believe sqlite does this.
| yjftsjthsd-h wrote:
| Famously, yes: https://sqlite.org/copyright.html (see
| "Open-Source, not Open-Contribution")
| BalinKing wrote:
| By my reading, the restriction seems to simply impose
| some (reasonable?) legal restrictions on contributions
| rather than ban them out of principle.
| yjftsjthsd-h wrote:
| Interesting, they've softened their stance. Today, it
| reads
|
| > In order to keep SQLite in the public domain and ensure
| that the code does not become contaminated with
| proprietary or licensed content, the project does not
| accept patches from people who have not submitted an
| affidavit dedicating their contribution into the public
| domain.
|
| But it used to read
|
| > In order to keep SQLite in the public domain and ensure
| that the code does not become contaminated with
| proprietary or licensed content, the project does not
| accept patches from unknown persons.
|
| (I randomly picked a date and found https://web.archive.o
| rg/web/20200111071813/https://sqlite.or... )
| dragonwriter wrote:
| Seems to be hardened not softened: a person who has
| submitted an affidavit dedicating code fo the public
| domain is at least minimally known, but a person may be
| known without submitting an affidavit, so the new form is
| strictly a stronger restriction than the old one.
| Capricorn2481 wrote:
| That kind of means jack squat though. Jai is an
| unfinished *programming language*, Sqlite is an extremely
| mature *database*.
|
| What chii is suggesting is open sourcing Jai now may
| cause nothing but distractions for the creator with 0
| upside. People will write articles about its current
| state, ask why it's not like their favorite language or
| doesn't have such-and-such library. They will even
| suggest the creator is trying to "monopolize" some domain
| space because that's what programmers do to small open
| source projects.
|
| That's a completely different situation from Sqlite and
| Linux, two massively-funded projects so mature and
| battle-tested that low-effort suggestions for the
| projects are not taken seriously. If I write an article
| asking Sqlite to be completely event-source focused in 5
| years, I would be rightfully dunked on. Yet look at all
| the articles asking Zig to be "Rust but better."
|
| I think you can look at any budding language over the
| past 20 years and see that people are not kind to a
| single maintainer with an open inbox.
| ksec wrote:
| >You can simply ignore them.
|
| You say this now but between 2013 - around 2023, The
| definition of Open source is that if you dont engage with
| the community and dont accept PRs it is not open source.
| And people will start bad mouth the project around the
| internet.
|
| Working on a project is hard enough as it is.
| lifthrasiir wrote:
| Open source softwares with closed development model have
| existed for a very long time so that should have been
| considered no matter it was considered as open source or
| not. (And I think it was around 2000s, not 2010s, when
| such misconception was more widespread.)
| ksec wrote:
| I dont deny what you said. I am merely pointing out this
| isn't a popular modem or opinion between that time line.
| yjftsjthsd-h wrote:
| Linux doesn't take PRs on github, and sqlite doesn't take
| patches. Open Source isn't a community model, only a
| license model.
| ksec wrote:
| >Open Source isn't a community model, only a license
| model.
|
| Again, not between 2015 - ~2023. And after what happened
| I dont blame people who dont want to do it.
| yjftsjthsd-h wrote:
| So your position is that Linux no longer counts as open
| source?
| MyOutfitIsVague wrote:
| > if you dont engage with the community and dont accept
| PRs it is not open source
|
| You'd be really hard pressed to find somebody who doesn't
| consider SQLite to be open source.
| bigstrat2003 wrote:
| That was never the definition of open source. That may
| have been how people were using it, but they were in
| error if so.
| furyofantares wrote:
| Maybe there's aspirations to not be a "smaller
| programming language" and he'd rather not cause confusion
| and burn interested parties by having it available.
|
| Releasing it when you're not ready to collect any upside
| from that decision ("simply ignore them") but will incur
| all the downside from a confused and muddled
| understanding of what the project is at any given time
| sounds like a really bad idea.
| Zambyte wrote:
| Yep. A closed set of core language designers who have
| exclusive right to propose new paths for the language to
| take while developing fully Free and in the open is how
| Zig is developing.
| mort96 wrote:
| IMO the main thing they're risking by open sourcing it is
| adoption. Keeping it closed source is a pretty clear sign
| to the rest of the world that the language is not ready for
| widespread adoption. As soon as you open source it, even if
| you mark it as alpha, you'll end up with people using the
| language, and breaking changes will at that point break
| people's code.
| diggan wrote:
| > language is not ready for widespread adoption.
|
| Keeping things closed source is one way of indicating
| that. Another is to use a license that contains "THE
| SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
| KIND, EXPRESS OR IMPLIED [...]" and then let people make
| their own choices. Just because something is open source
| doesn't mean it's ready for widespread adoption.
| mort96 wrote:
| If you have users, then breaking changes will break those
| users. This is true regardless of how many warranty
| disclaimers you have.
| sph wrote:
| That's what I meant by forked. If Jonathan wants to keep his
| branch closed source, that's fine, as long as he cuts a
| release, gives it a GNU license and calls it OpenJai or
| something. He doesn't have to deal with the community,
| somebody will do that for him.
| pjmlp wrote:
| Apparently not only do the 90's approach still work pretty well
| when the language comes with a piece of green coloured
| hardware, all the ongoing returns to 90's licensing models
| prove that the free beer approach isn't working when the goal
| is to build a sustainable business of out the technology.
| az09mugen wrote:
| There is this streamer that does a lot of interesting language
| exploring on his own. I don't say you will find all the answers
| to your questions, but I think you will get a good sense of
| what you can or cannot do in jai :
| https://www.youtube.com/results?search_query=Tsoding+jai
| sph wrote:
| Tsoding is great. Don't be put off by the memelord persona,
| he's a genuinely smart guy always exploring some interesting
| language or library, or reimplementing something from scratch
| to truly understand it.
| estebank wrote:
| > Don't be put off by the memelord persona
|
| One can be put off by whatever one is put off by. I've
| gotten to the point where I realized that I don't need to
| listen to everyone's opinion. Everyone's got some. If one
| opinion is important, it will like the shared by more than
| one person. From that it follows that there's no need to
| subject oneself to specific people one is put off by. Or
| put another way: if there's an actionable critique, and two
| people are stating it, and one is a dick and the other
| isn't, I'll pay attention to the one who isn't a dick.
| Life's to short to waste it with abrasive people,
| regardless of whether that is "what is in their heart" or a
| constructed persona. The worst effect of the "asshole
| genius" trope is that it makes a lot of assholes think they
| are geniuses.
| troupo wrote:
| You can also watch Jonathan Blow himself writing a commercial
| game and developing jai on stream:
| https://www.twitch.tv/j_blow
| krapp wrote:
| Is he _actually_ doing that or is he doing what Casey
| Muratori 's doing with Handmade Hero and taking almost a
| decade to implement a debug room for a generic top-down
| Zelda clone?
| troupo wrote:
| You can watch the streams and decide for yourself.
|
| In a recent interview he mentioned they are aiming for a
| release later this year:
| https://youtu.be/jamU6SQBtxk?si=nMTKbJjZ20YFwmaC
| WalterBright wrote:
| Some comparison with D:
|
| > Do I have access to an asm keyword,
|
| Yes, D has a builtin assembler
|
| > or can I easily link assembly files?
|
| Yes
|
| > Do I have access to the linker phase to customize the layout
| of the ELF file?
|
| D uses standard linkers.
|
| > Does it need a runtime to work?
|
| With the -betterC switch, it only relies on the C runtime
|
| > Can I disable the standard library?
|
| You don't need the C runtime if you don't call any of the
| functions in it.
| pcwalton wrote:
| > I'd be much more excited about that promise [memory safety in
| Rust] if the compiler provided that safety, rather than asking
| the programmer to do an extraordinary amount of extra work to
| conform to syntactically enforced safety rules. Put the
| complexity in the compiler, dudes.
|
| That exists; it's called garbage collection.
|
| If you don't want the performance characteristics of garbage
| collection, something has to give. Either you sacrifice memory
| safety or you accept a more restrictive paradigm than GC'd
| languages give you. For some reason, programming language
| enthusiasts think that if you think really hard, every issue has
| some solution out there without any drawbacks at all just waiting
| to be found. But in fact, creating a system that has zero runtime
| overhead and unlimited aliasing with a mutable heap is as
| impossible as finding two even numbers whose sum is odd.
| sph wrote:
| The faster computers get, the more the GC problem is way
| overblown apart from super-low-latency niches. Even AAA games
| these days happily run on GC languages.
|
| There is a prominent contributor to HN whose profile says they
| dream of a world where all languages offer automatic memory
| management and I think about that a lot, as a low-level backend
| engineer. Unless I find myself writing an HFT bot or a kernel,
| I have zero need to care about memory allocation, cycles, and
| who owns what.
|
| Productivity >> worrying about memory.
| lifthrasiir wrote:
| GC doesn't exactly solve your memory problem; it typically
| means that your memory problem gets deferred quite far until
| you can't ignore that. Of course it is also quite likely that
| your program will never grow to that point, which is why GC
| works in general, but also why there exists a desire to avoid
| it when makes sense.
| sph wrote:
| That's fair, no resource is unlimited. My point is that
| memory is usually the least of one's problem, even on
| average machines. Productivity and CPU usage tend to be the
| bottleneck as a developer and a user. GC is mostly a
| performance problem rather than a memory one, and well-
| designed language can minimize the impact of it. (I am
| working on a message-passing language, and only allowing GC
| after a reply greatly simplifies the design and performance
| characteristics)
| mjburgess wrote:
| Not sure why you're down-voted, this is correct.
|
| In games you have 16ms to draw billion+ triangles (etc.).
|
| In web, you have 100ms to round-trip a request under
| abitarily high load (etc.)
|
| Cases where you cannot "stop the world" at random and just
| "clean up garbage" are quite common in programming. And
| when they happen in GC'd languages, you're much worse off.
| immibis wrote:
| Java's ZGC claims O(1) pause time of 0.05ms.
|
| (As with any low-pause collector, the rest of your code
| is uniformly slower by some percentage because it has to
| make sure not to step on the toes of the concurrently-
| running collector.)
| Ygg2 wrote:
| > Java's ZGC claims O(1) pause time of 0.05ms
|
| In practice it's actually closer to 10ms for large heaps.
| Large being around 220 GB.
| riku_iki wrote:
| With Java, the issue is that each allocated object
| carries significant memory footprint, as result total
| memory consumption is much higher compared to C++:
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| Tomte wrote:
| That's why it's good that GC algorithms that do not "stop
| the world" have been in production for decades now.
| pebal wrote:
| There are none, at least not production grade.
| kelseyfrog wrote:
| There are none, or you're not aware of their existence?
| throwawaymaths wrote:
| eh, there are GC languages famous for high uptimes and
| deployed in places where it "basically runs forever with no
| intervention", so in practice with the right GC and
| application scope, "deferring the concern till the heat
| death of the universe" (or until a CVE forces a soft
| update) is possible.
| withoutboats3 wrote:
| This is exactly the attitude this blog post spends its first
| section pretty passionately railing against.
| jplusequalt wrote:
| >Even AAA games these days happily run on GC languages.
|
| Which games are these? Are you referring to games written in
| Unity where the game logic is scripted in C#? Or are you
| referring to Minecraft Java Edition?
|
| I seriously doubt you would get close to the same performance
| in a modern AAA title running in a Java/C# based engine.
| Jasper_ wrote:
| Unreal Engine has a C++-based GC.
|
| https://dev.epicgames.com/documentation/en-us/unreal-
| engine/...
| steveklabnik wrote:
| Unreal Engine has a GC.
|
| You're right that there is a difference between "engine
| written largely in C++ and some parts are GC'd" vs "game
| written in Java/C#", but it's certainly not unheard of to
| use a GC in games, pervasively in simpler ones (Heck,
| Balatro is written in Lua!) and sparingly in even more
| advanced titles.
| tuveson wrote:
| I think Balatro uses the Love2d engine which is in C/C++.
| steveklabnik wrote:
| Sure, but you write games in it in Lua. That Love2d is
| implemented in C++ (GitHub says like 80% C++ and 10% C)
| doesn't mean that you're writing the game in it. In my
| understanding, Love2d uses reference counting (which is
| still GC) for its own stuff, and integrates those into
| Lua's tracing GC.
| neonsunset wrote:
| C#? Maybe. Java? Less likely.
| Narishma wrote:
| > Even AAA games these days happily run on GC languages.
|
| You can recognize them by their poor performance.
| mjburgess wrote:
| Well, 1) the temporary allocator strategy; and 2) `defer` kinda
| go against the spirit of this observation.
|
| With (1) you get the benefits of GC with, in many cases, a
| single line of code. This handles a lot of use cases. Of those
| it doesn't, `defer` is that "other single line".
|
| I think the issue being raised is the "convenience payoff for
| the syntax/semantics burden". The payoff for temp-alloc and
| defer is enormous: you make the memory management explicit so
| you can easily see-and-reason-about the code; and it's a
| trivial amount of code.
|
| There feels something deeply wrong with RAII-style langauges..
| you're having the burden to reason about implicit behaviour,
| all the while this behaviour saves you nothing. It's the worst
| of both worlds: hiddenness and burdensomeness.
| hmry wrote:
| Neither of those gives memory safety, which is what the
| parent comment is about. If you release the temporary
| allocator while a pointer to some data is live, you get use
| after free. If you defer freeing a resource, and a pointer to
| the resource lives on after the scope exit, you get use after
| free.
| francasso wrote:
| While technically true, it still simplifies memory
| management a lot. The tradeoff in fact is good enough that
| I would pick that over a borrowchecker.
| junon wrote:
| I don't understand this take at all. The borrow checker
| is automatic and works across all variables. Defer et al
| requires you remember to use it, and use it correctly. It
| takes _more effort_ to use defer correctly whereas Rust
| 's borrow checker works for you without needing to do
| much extra at all! What am I missing?
| vouwfietsman wrote:
| > The borrow checker is automatic and works across all
| variables.
|
| Not that I'm such a Rust hater, but this is also a
| simplification of the reality. The term "fighting the
| borrow checker" is these days a pretty normal saying, and
| it implies that the borrow checker may be automatic, but
| 90% of its work is telling you: no, try again. That is
| hardly "without needing to do much extra at all".
|
| That's what you're missing.
| junon wrote:
| Maybe I'm spoiled because I work with Rust primarily
| these days but "fighting the borrow checker" isn't really
| common once you get it.
| vouwfietsman wrote:
| A lot has been written about this already, but again I
| think you're simplifying here by saying "once you get
| it". There's a bunch of options here for what's
| happening:
|
| 1. The borrow checker is indeed a free lunch 2. Your
| domain lends itself well to Rust, other domains don't 3.
| Your code is more complicated than it would be in other
| languages to please the borrow checker, but you are
| unaware because its just the natural process of writing
| code in Rust.
|
| There's probably more things that could be going on, but
| I think this is clear.
|
| I certainly doubt its #1, given the high volume of very
| intelligent people that have negative experiences with
| the borrow checker.
| steveklabnik wrote:
| "But after an initial learning hump, I don't fight the
| borrow checker anymore" is quite common and widely
| understood.
|
| Just like any programming paradigm, it takes time to get
| used to, and that time varies between people. And just
| like any programming paradigm, some people end up not
| liking it.
|
| That doesn't mean it's a "free lunch."
| tialaramex wrote:
| What's hilarious about "fighting the borrow checker" is
| that it's about the lexical lifetime borrow checking,
| which went away many years ago - fixing that is what
| "Non-lexical lifetimes" is about, which if you picked up
| Rust in the last like 4-5 years you won't even know was a
| thing. In that era you actually did need to "fight" to
| get obviously correct code to compile because the
| checking is only looking at the lexical structure.
|
| Because this phrase existed, it became _the_ thing people
| latch onto as a complaint, often even when there is no
| borrowck problem with what they were writing.
|
| Yes of course when you make lifetime mistakes the
| borrowck means you have to fix them. It's true that in a
| sense in a GC language you don't have to fix them
| (although the consequences can be pretty nasty if you
| don't) because the GC will handle it - and that in a
| language like Jai you can just endure the weird crashes
| (but remember this article, the weird crashes aren't
| "Undefined Behaviour" apparently, even though that's
| exactly what they are)
|
| As a Rust programmer I'm comfortable with the statement
| that it's "without needing to do much extra at all".
| sensen7 wrote:
| >In that era you actually did need to "fight" to get
| obviously correct code to compile because the checking is
| only looking at the lexical structure.
|
| NLL's final implementation (Polonius) hasn't landed yet,
| and many of the original cases that NLL were meant to
| allow still don't compile. This doesn't come up very
| often in practice, but it sure sounds like a hole in your
| argument.
|
| What does come up in practice is partial borrowing
| errors. It's one of the most common complaints among Rust
| programmers, and it definitely qualifies as having to
| fight/refactor to get obviously correct code to compile.
| steveklabnik wrote:
| > What does come up in practice is partial borrowing
| errors.
|
| For some people. For example, I personally have never had
| a partial borrowing error.
|
| > it definitely qualifies as having to fight/refactor to
| get obviously correct code to compile.
|
| This is not for sure. That is, while it's code that
| _could_ work, it 's not obviously clear that it's
| correct. Rust cares a lot about the contract of function
| signatures, and partial borrows violate the signature,
| that's why they're not allowed. Some people want to relax
| that restriction. I personally think it's a bad idea.
| hmry wrote:
| > Rust cares a lot about the contract of function
| signatures, and partial borrows violate the signature
|
| People want to be able to specify partial borrowing in
| the signatures. There have been several proposals for
| this. But so far nothing has made it into the language.
|
| Just to give an example of where I've run into countless
| partial borrowing problems: Writing a Vulkan program. The
| usual pattern in C++ etc is to just have a giant
| "GrahpicsState" struct that contains all the data you
| need. Then you just pass a reference to that to any
| function that needs any state. (of course, this is not
| safe, because you could have accidental mutable
| aliasing).
|
| But in Rust, that just doesn't work. You get countless
| errors like "Can't call self.resize_framebuffer() because
| you've already borrowed self.grass_texture" (even though
| resize_framebuffer would never touch the grass texture),
| "Can't call self.upload_geometry() because you've already
| borrowed self.window.width", and so on.
|
| So instead you end up with 30 functions that each take 20
| parameters and return 5 values, and most of the code is
| shuffling around function arguments
|
| It would be so much nicer if you could instead annotate
| that resize_framebuffer only borrows self.framebuffer,
| and no other part of self.
| steveklabnik wrote:
| > People want to be able to specify partial borrowing in
| the signatures.
|
| That's correct. That's why I said "Some people want to
| relax that restriction. I personally think it's a bad
| idea."
|
| > The usual pattern in C++ etc is to just have a giant
| "GrahpicsState" struct that contains all the data you
| need. Then you just pass a reference to that to any
| function that needs any state.
|
| Yes, I think that this style of programming is not good,
| because it creates giant balls of aliasing state. I
| understand that if the library you use requires you to do
| this, you're sorta SOL, but in the programs I write, I've
| never been required to do this.
|
| > So instead you end up with 30 functions that each take
| 20 parameters and return 5 values, and most of the code
| is shuffling around function arguments
|
| Yes, this is the downstream effects of designing APIs
| this way. Breaking them up into smaller chunks of state
| makes it significantly more pleasant.
|
| I am not sure that it's a good idea to change the
| language to make using poorly designed APIs easier. I
| also understand that reasonable people differ on this
| issue.
| sensen7 wrote:
| >Yes, this is the downstream effects of designing APIs
| this way. Breaking them up into smaller chunks of state
| makes it significantly more pleasant.
|
| What they're describing is the downstream effect of _not_
| designing APIs that way. If you could have a single giant
| GraphicsState and define everything as a method on it,
| you would have to pass around barely any arguments at
| all: everything would be reachable from the &mut self
| reference. And either with some annotations or with just
| a tiny bit of non-local analysis, the compiler would
| still be able to ensure non-aliasing usage.
|
| "functions that each take 20 parameters and return 5
| values" is what you're forced to write in alternative to
| that, to avoid partial borrowing errors: for example,
| instead of a self.resize_framebuffer() method, a free
| function resize_framebuffer(&mut self.framebuffer, &mut
| self.size, &mut self.several_other_pieces_of_self, &mut
| self.borrowed_one_by_one).
|
| I agree that the severity of this issue is highly
| dependent on what you're building, but sometimes you
| really do have a big ball of mutable state and there's
| not much you can do about it.
| leecommamichael wrote:
| I appreciate what you're saying, though isn't undefined
| behavior having to do with the semantics of execution as
| specified by the language? Most languages outright
| decline to specify multiple threads of execution, and
| instead provide it as a library. I think C started that
| trend. I'm not sure if Jai even has a spec, but the
| behavior you're describing could very well be
| "unspecified" not "undefined" and that's a distinction
| some folks care about.
|
| This being said, yes Rust is useful to verify those
| scenarios because it _does_ specify them, and despite his
| brash takes on Rust, Jon admits its utility in this
| regard from time to time.
| tialaramex wrote:
| > the behavior you're describing could very well be
| "unspecified" not "undefined" and that's a distinction
| some folks care about.
|
| Nah, it's going to be Undefined. What's going on here is
| that there's an optimising compiler, and the way compiler
| optimisation works is you Define some but not all
| behaviour in your language and the optimiser is allowed
| to make any transformations which keep the behaviour you
| Defined.
|
| Jai uses LLVM so in many cases the UB is exactly the same
| as you'd see in Clang since that's also using LLVM. For
| example Jai can explicitly choose not to initialize a
| variable (unlike C++ 23 and earlier this isn't the
| default for the primitive types, but it is still
| possible) - in LLVM I believe this means the
| uninitialized variable is poison. Exactly the same awful
| surprises result.
| leecommamichael wrote:
| Your reasoning appears to be:
|
| 1. because it is the kind of optimizing compiler you say
| it is
|
| 2. because it uses LLVM
|
| ... there will be undefined behavior.
|
| Unless you worked on Jai, you can't support point 1. I'm
| not even sure if you're right under that presumption,
| either.
| francasso wrote:
| If your use case can be split into phases you can just
| allocate memory from an arena, copy out whatever needs to
| survive the phase at the end and free all the memory at
| once. That takes care of 90%+ of all allocations I ever
| need to do in my work.
|
| For the rest you need more granular manual memory
| management, and defer is just a convenience in that case
| compared to C.
|
| I can have graphs with pointers all over the place during
| the phase, I don't have to explain anything to a borrow
| checker, and it's safe as long as you are careful at the
| phase boundaries.
|
| Note that I almost never have things that need to survive
| a phase boundary, so in practice the borrow checker is
| just a nuissance in my work.
|
| There other use cases where this doesn't apply, so I'm
| not "anti borrow checker", but it's a tool, and I don't
| need it most of the time.
| Rusky wrote:
| You can explain this sort of pattern to the borrow
| checker quite trivially: slap a single `'arena` lifetime
| on all the references that point to something in that
| arena. This pattern is used all over the place, including
| rustc itself.
|
| (To be clear I agree that this is an easy pattern to
| write correctly without a borrow checker as well. It's
| just not a good example of something that's any harder to
| do in Rust, either.)
| francasso wrote:
| I remember having multiple issues doing this in rust, but
| can't recall the details. Are you sure I would just be
| able to have whatever refs I want and use them without
| the borrow checker complaining about things that are
| actually perfectly safe? I don't remember that being the
| case.
|
| Edit: reading wavemode comment above "Namely, in Rust it
| is undefined behavior for multiple mutable references to
| the same data to exist, ever. And it is also not enough
| for your program to not create multiple mut - the
| compiler also has to be able to prove that it can't."
| that I think was at least one of the problems I had.
| steveklabnik wrote:
| The main issue with using arenas in Rust right now is
| that the standard library collections use the still-
| unstable allocator API, so you cannot use those with
| them. However, this is a systems language, so you can use
| whatever you want for your own data structures.
|
| > reading wavemode comment above
|
| This is true for `&mut T` but that isn't directly related
| to arenas. Furthermore, you _can_ have multiple mutable
| aliased references, but you need to not use ` &mut T`
| while doing so: you can take advantage of some form of
| internal mutability and use `&T`, for example. What is
| needed depends on the circumstances.
| Rusky wrote:
| wavemode's comment only applies to `&mut T`. You do not
| have to use `&mut T` to form the reference graph in your
| arena, which indeed would be unlikely to work out.
| wavemode wrote:
| What you're missing is that Rust's borrowing rules are
| not the definition of memory safety. They are just one
| particular approach that works, but with tradeoffs.
|
| Namely, in Rust it is undefined behavior for multiple
| mutable references to the same data to exist, ever. And
| it is also not enough for your program to not create
| multiple mut - the compiler also has to be able to prove
| that it can't.
|
| That rule prevents memory corruption, but it outlaws many
| programs that break the rule yet actually are otherwise
| memory safe, and it also outlaws programs that follow the
| rule but wherein the compiler isn't smart enough to prove
| that the rule is being followed. That annoyance is the
| main thing people are talking about when they say they
| are "fighting the borrow checker" (when comparing Rust
| with languages like Odin/Zig/Jai).
| junon wrote:
| Rust doesn't outlaw them. It just forces you to document
| where safety workarounds are used.
| Rusky wrote:
| That is true of `&mut T`, but `&mut T` is not the only
| way to do mutation in Rust. The set of possible safe
| patterns gets much wider when you include `&Cell<T>`. For
| example see this language that uses its equivalent of
| `&Cell<T>` as the primary mutable reference type, and
| uses its equivalent of `&mut T` more sparingly:
| https://antelang.org/blog/safe_shared_mutability/
| mjburgess wrote:
| The dialetic beings with OP, and has pcw's reply and then
| mine. It does not begin with pcw's comment. The OP
| complains about rust not because they imagine Jai is memory
| safe, but because they feel the rewards of its approach
| significantly outweight the costs of Rust.
|
| pcw's comment was about tradeoffs programmers are willing
| to make -- and paints the picture more black-and-white than
| the reality; and more black and white than OP.
| MJGrzymek wrote:
| Not sure about the implicit behavior. In C++, you can write a
| lot of code using vector and map that would require manual
| memory management in C. It's as if the heap wasn't there.
|
| Feels like there is a beneficial property in there.
| ksec wrote:
| >as impossible as finding two even numbers whose sum is odd.
|
| That is a great line worth remembering.
| pphysch wrote:
| > Either you sacrifice memory safety or you accept a more
| restrictive paradigm than GC'd languages give you.
|
| This is true but there is a middle ground. You use a reasonably
| fast (i.e. compiled) GC lang, and write your own allocator(s)
| inside of it for performance-critical stuff.
|
| Ironically, this is usually the right pattern even in non-GC
| langs: you typically want to minimize unnecessary allocations
| during runtime, and leverage techniques like object pooling to
| do that.
|
| IOW I don't think raw performance is a good argument for not
| using GC (e.g. gamedev or scientific computing).
|
| Not being able to afford the GC runtime overhead is a good
| argument (e.g. embedded programs, HFT).
| msmshazan wrote:
| Wonder when will Jai open beta happen
| troupo wrote:
| If all goes according to plan, late this year.
| https://youtu.be/jamU6SQBtxk?si=hDbwZQX2MtFiwun8
| sushidev wrote:
| I would have liked to see more code examples in the article.
| lawn wrote:
| Yeah, I see a bunch of praise and references to unfamiliar
| features/syntax and it makes it hard to follow and to form an
| opinion about.
| perching_aix wrote:
| > rather than asking the programmer to do an extraordinary amount
| of extra work to conform to syntactically enforced safety rules.
| Put the complexity in the compiler, dudes.
|
| And how would that compiler work? Magic? Maybe clairvoyance?
| lifthrasiir wrote:
| The biggest "crime" of Jai is that it (soft-)launched like an
| open source programming language and didn't actually become open
| source shortly. There are so many programming languages that did
| go through the "beta" period and still remain open sourced all
| the time. Open source doesn't imply open governance, and most
| such languages are still evolved almost solely with original
| authors' judgements. It is fine for Jai to remain closed of
| course, but there is no practical reason for Jai to remain closed
| to this day. The resulting confusion is large enough to dismiss
| Jai at this stage.
| jimbob45 wrote:
| Yep. Same dilemma as Star Citizen. If both just threw their
| hands up and said, "Done!", today then everyone would agree
| that a great product had been released and everyone would be
| mostly pleased. Instead, development has dragged on so long as
| to cast doubts over the goodwill of the founders. Now, Jai is
| unusable because it's difficult to trust Blow if he's willing
| to lie about that and Star Citizen is unplayable because the
| game was clearly released under false pretenses.
| chriscbr wrote:
| Same story with the Mojo language, unfortunately.
|
| To me this raises the question of whether this is a growing
| trend, or whether it's simply that languages staying closed
| source tends to be a death sentence for them in the long term.
| Pet_Ant wrote:
| Honestly the tone of the article was so smug and condescending
| that I couldn't finish it.
| cynical_german wrote:
| wow... I did not get that _at all_ ; opinionated maybe, do I
| have to share all these opinions to the degree to which they've
| been expressed? No, but condescending? To whom? To duck typed
| languages?
| tialaramex wrote:
| It's condescending to the people who've noticed they make
| mistakes and so value a language which is designed
| accordingly:
|
| "So, put simply, yes, you can shoot yourself in the foot, and
| the caliber is enormous. But you're being treated like an
| adult the whole time"
|
| That is, those of us who've noticed we make mistakes aren't
| adults we're _children_ and this is a proper grown-up
| language -- pretty much the definition of condescending.
| unclad5968 wrote:
| I can't tell if you're joking or not, but if you aren't, no
| one is calling you a child. The article is obviously saying
| that the compiler doesn't stop you from doing dumb things,
| which is a privilege generally only extended to adults.
| Nobody is saying anyone who makes mistakes is a child.
| phtrivier wrote:
| If you feel this article is smug and condescending, don't start
| watching the language designer's stream too soon.
|
| The least you can say is that he is _opinionated_. Even his
| friend Casey Muratori is "friendly" in comparison, at least
| trying to publish courses to elevate us masses of unworthy
| typescript coders to the higher planes of programming.
|
| Jblow just want you to feel dumb for not programming right.
| He's unforgiving, Socrate's style.
|
| The worst thing is : he might be right, most of the time.
|
| We would not know, cause we find him infuriating, and, to be
| honest, we're just too dumb.
| triilman wrote:
| I am not interested. I am just trying to code with C3 and make
| some binding with another language like C and Zig, it is quiet
| easy and fun. I think it's enough for me to learn kinds of
| language than using jai that never released the compiler to the
| public till now.
| TinkersW wrote:
| I have my doubts with Jai, the fact that Blow & co seems to have
| major misunderstandings with regards to RAII doesn't lend much
| confidence.
|
| Also a 19,000 line C++ program(this is tiny) does not take 45
| minutes unless something is seriously broken, it should be a few
| seconds at most for full rebuild even with a decent amount of
| template usage. This makes me suspect this author doesn't have
| much C++ experience, as this should have been obvious to them.
|
| I do like the build script being in the same language, CMake can
| just die.
|
| The metaprogramming looks more confusing than C++, why is
| "sin"/"cos" a string?
|
| Based on this article I'm not sure what Jai's strength is, I
| would have assumed metaprogramming and SIMD prior, but these are
| hardly discussed, and the bit on metaprogramming didn't make much
| sense to me.
| VyseofArcadia wrote:
| > Also a 19,000 line C++ program(this is tiny) does not take 45
| minutes unless something is seriously broken
|
| Agreed, 45 minutes is insane. In my experience, and this does
| depend on a lot of variables, 1 million lines of C++ ends up
| taking about 20 minutes. If we assume this scales linearly (I
| don't think it does, but let's imagine), 19k lines should take
| about 20 seconds. Maybe a little more with overhead, or a
| little less because of less burden on the linker.
|
| There's a lot of assumptions in that back-of-the-envelope math,
| but if they're in the right ballpark it does mean that Jai has
| an order of magnitude faster builds.
|
| I'm sure the big win is having a legit module system instead of
| plaintext header #include
| MyOutfitIsVague wrote:
| It depends heavily on features used, too. C++ without
| templates compiles nearly as quickly as C.
| unclad5968 wrote:
| I seriously doubt that any of them have trouble understanding a
| concept as simple as RAII.
| kbr- wrote:
| Yeah it's weird but the author of this post claiming that
| defer can replace RAII kinda suggests that. RAII isn't just
| about releasing the resource you acquired in the current
| scope in the same scope. You can pass the resource across
| multiple boundaries with move semantics and only at the end
| when it's no longer needed the resources will be released.
| VyseofArcadia wrote:
| > The net effect of this is that the software you're running on
| your computer is effectively wiping out the last 10-20 years of
| hardware evolution; in some extreme cases, more like 30 years.
|
| As an industry we need to worry about this more. I get that in
| business, if you can be less efficient in order to put out more
| features faster, your dps[0] is higher. But as both a programmer
| and an end user, I care _deeply_ about efficiency. Bad enough
| when just one application is sucking up resources unnecessarily,
| but now it 's nearly _every_ application, up to and including the
| OS itself if you are lucky enough to be a Microsoft customer.
|
| The hardware I have sitting on my desk is vastly more powerful
| that what I was rocking 10-20 years ago, but the user experience
| seems about the same. No new features have really revolutionized
| how I use the computer, so from my perspective all we have done
| is make everything slower in lockstep with hardware advances.
|
| [0] dollars per second
| dayvigo wrote:
| > The hardware I have sitting on my desk is vastly more
| powerful that what I was rocking 10-20 years ago, but the user
| experience seems about the same.
|
| Not even.
|
| It used to be that when you clicked a button, things happened
| immediately, instead of a few seconds later as everything
| freezes up. Text could be entered into fields without inputs
| getting dropped or playing catch-up. A mysterious unkillable
| service wouldn't randomly decide to peg your core several times
| a day. This was all the case even as late as Windows 7.
| pixl97 wrote:
| At the same time it was also that you typed 9 characters in
| an 8 characters field and you p0wn3e the application.
|
| >Text could be entered into fields without inputs getting
| dropped or playing catch-up
|
| This has been a complaint since the DOS days that has always
| been around from my experience. I'm pretty sure it's been
| industry standard from its inception that most large software
| providers make the software just fast enough the users don't
| give up and that's it.
|
| Take something like notepad in opening files. Large files
| take forever. Yet I can pop open notepad++ from some random
| small team and it opens the same file quickly.
| spacechild1 wrote:
| > because most Javascript programmers are entirely unaware of the
| memory allocation cost associated with each call to anonymous
| functions
|
| How does _calling_ an anonymous function in JS cause memory
| allocations?
| steveklabnik wrote:
| I also found this comment a bit strange. I'm not aware of a
| situation where this occurs, though he might be conflating
| _creating_ an anonymous function with calling it.
| spacechild1 wrote:
| > he might be conflating creating an anonymous function with
| calling it.
|
| Yeah, that's what I figured. I don't know JS internals all
| too well, so I thought he might be hinting at some unexpected
| JS runtime quirk.
| nmilo wrote:
| Probably misspoke, returning or passing anonymous functions
| cause allocations for the closures, then calling them causes
| probably 4 or 5 levels of pointer chasing to get the data that
| got (invisibly) closed over
| spacechild1 wrote:
| I don't think there is much pointer chasing at runtime. With
| lexically scoped closures it's only the compiler who walks
| the stack frames to find the referenced variable; the
| compiled function can point directly to the object in the
| stack frame. In my understanding, closed over variables have
| (almost) no runtime cost over "normal" local variables.
| Please correct me if I'm wrong.
| malkia wrote:
| I didn't know much about Jai, and started reading it, and it
| really has (according to the article) some exciting features, but
| this caught my eye:
|
| "... Much like how object oriented programs carry around a this
| pointer all over the place when working with objects, in Jai,
| each thread carries around a context stack, which keeps track of
| some cross-functional stuff, like which is the default memory
| allocator to ..."
|
| It reminds me of GoLang's context, and it should've existed in
| any language dealing with multi-threading, as a way of carrying
| info about parent thread/process (and tokens) for trace
| propagation, etc.
| leecommamichael wrote:
| The Odin programming language uses an implicit context pointer
| like Jai, and is freely available and open source.
| sesm wrote:
| > async/await, a pattern increasingly polluting Javascript and
| Python codebases in the name of performance
|
| In JS world async/await was never about performance, it was
| always about having more readable code than Promise chain
| spagetti.
| mustache_kimono wrote:
| > Software has been getting slower at a rate roughly equivalent
| to the rate at which computers are getting faster.
|
| Cite?
|
| This problem statement is also such a weird introduction to
| specifically this new programming language. Yes, compiled
| languages with no GC are faster than the alternatives. But the
| problem is and was not the alternatives. Those alternatives fill
| the vast majority of computing uses and work well enough.
|
| The problem is compiled languages with no GC, before Rust, were
| bug prone, and difficult to use safely.
|
| So -- why are we talking about this? Because jblow won't stop
| catastrophizing. He has led a generation of impressionable
| programmers to believe that we in some dark age of software, when
| that statement couldn't be further from the truth.
| topspin wrote:
| I carefully watched a number of the early jai language YouTube
| videos. Some of his opinions on non-programming topics are just
| goofy: I recall him ranting (and I wish I could find it again,)
| about the supposed pointlessness of logarithmic scales
| (decibels, etc.,) vs scientific notation and experiencing a
| pretty bad cringe spasm.
|
| jblow's words are not the Gospel on high.
| troupo wrote:
| > He has led a generation of impressionable programmers to
| believe that we in some dark age of software, when that
| statement couldn't be further from the truth.
|
| Have you actually used modern software?
|
| There's a great rant about Visual Studio debugger which in
| recent versions cannot even update debugged values as you step
| through the program unlike its predecessors:
| https://youtu.be/GC-0tCy4P1U?si=t6BsHkHhoRF46mYM
|
| And this is professional software. There's state of personal
| software is worse. Most programs cannot show a page of text
| with a few images without consuming gigabytes of RAM and not-
| insignificant percentages of CPU.
| phtrivier wrote:
| I sincerely dread that by the time jblow releases jai, people
| will just have moved on to zig or rust, and that it will just
| become irrelevant.
|
| I'm sure jblow is having the same fears, and I hope to be wrong.
|
| Still, it's fun to be remembering the first few videos about
| "hey, I have those ideas for a language". Great that he could
| afford to work on it.
|
| Sometimes, mandalas are what we need.
| SalmoShalazar wrote:
| Why do you dread this? It's entirely possible that Jai is not
| good enough to compete, no?
| phtrivier wrote:
| That would be the "best case" scenario (an inferior language
| beaten by better ones.)
|
| But, no, the hubris of the language creator, whose arrogance
| is probably close to a few nano-Dijkstras, makes it entirely
| possible that he prefers _not_ releasing a superior language,
| out of spite for the untermenschen that would "desecrate" it
| by writing web servers inside it.
|
| So I'm pretty convinced now that he will just never release
| it except to a couple of happy fews, and then he will die of
| cardio vascular diseases because he spent too much time
| sitting in a chair streaming nonsense, and the world will
| have missed an opportunity.
|
| Then again, I'm just sad.
|
| As John Stewart said: "on the bright side, I'm told that at
| some point the sun will turn supernova, and we'll all die."
| mppm wrote:
| Jai's perpetual closed beta is such a weird thing... On the one
| hand, I sort of get that the developers don't want to waste their
| time and attention on too many random people trying to butt in
| with their ideas and suggestions. On the other hand, they are
| thereby wasting the time and attention of all the people who
| watched the development videos and read the blog posts, and now
| can do basically nothing with that knowledge other than slowly
| forget it. (Except for the few who take the ideas and incorporate
| them into their own languages).
| ModernMech wrote:
| It's a common thing in programming language design and circles
| where some people like to form little cults of personality
| around their project. Curtis Yarvin did that with his Urbit
| project. V-Lang is another good example. I consider Elm an
| example as well.
|
| They get a few "true believer" followers, give them special
| privileges like beta access (this case), special arcane
| knowledge (see Urbit), or even special standing within the
| community (also Urbit, although many other languages where the
| true believers are given authority over community spaces like
| discord/mailing list/irc etc.).
|
| I don't associate in these spaces because I find the people
| especially toxic. Usually they are high drama because the focus
| isn't around technical matters but instead around the cult
| leader and the drama that surrounds him, defending/attacking
| his decisions, rationalizing his whims, and toeing the line.
|
| Like this thread, where a large proportion is discussion about
| Blow as a personality rather than the technical merit of his
| work. He wants it that way, not so say that his work doesn't
| have technical merit, but that he'd rather we be talking about
| him.
| rglover wrote:
| The reality of a project like this is that to get it right
| (which is by the creator's standards, no one else's) takes
| time. Add on top of that Blow and Thekla are building games
| with this to dogfood it which takes time, too.
|
| Sadly, there exists a breed of developer that is manipulative,
| obnoxious, and loves to waste time/denigrate someone building
| something. Relatively few people are genuinely interested (like
| the OP) in helping to develop the thing, test builds, etc. Most
| just want to make contributions for their Github profile
| (assuming OSS) or exercise their internal demons by projecting
| their insecurities onto someone else.
|
| From all of the JB content I've seen/read, this is a rough
| approximation of his position. It's far less stressful to just
| work on the idea in relative isolation until it's ready (by
| whatever standard) than to deal with the random chaos of
| letting anyone and everyone in.
|
| This [1] is worth listening to (suspending cynicism) to get at
| the "why" (my editorialization, not JB).
|
| Personally, I wish more people working on stuff were like this.
| It makes me far more likely to adopt it when it _is_ ready
| because I can trust that the appropriate time was put in to
| building it.
|
| [1] https://www.youtube.com/watch?v=ZY0ZmeYmyjU
| cynical_german wrote:
| One thing I want to add to the other (so far) good responses:
| They also seem to build Jai for a means to an end, which is:
| they are actively developing a game engine with it (to be used
| for more than one project) and a game, which is already in
| advanced stages.
|
| If you consider a small team working on this, developing the
| language seriously, earnestly, but as a means to an end on the
| side, I can totally see why they think it may be the best
| approach to develop the language fully internally. It's an
| iterative develop-as-you-go approach, you're writing a highly
| specific opinionated tool for your niche.
|
| So maybe it's best to simply wait until engine + game are done,
| and they can (depending on the game's success) really devote
| focus and time on polishing language and compiler up,
| stabilizing a version 1.0 if you will, and "package" it in an
| appropriate manner.
|
| Plus: they don't seem to be in the "promote a language for the
| language's sake" game; it doesn't seem to be about finding the
| perfect release date, with shiny mascot + discord server + full
| fledged stdlib + full documentation from day one, to then
| "hire" redditors and youtubers to spread the word and have an
| armada of newbie programmers use it to write games... they seem
| to much rather see it as creating a professional tool aimed at
| professional programmers, particularly in the domain of high
| performance compiled languages, particularly for games. People
| they are targeting will evaluate the language thoroughly when
| it's out, whether that's in 2019, 2025 or 2028. And whether
| they are top 10 in some popularity contest or not, I just don't
| think they're playing by such metrics. The right people will
| check it out once it's out, I'm sure. And whether such a
| language will be used or not, will probably, hopefully even,
| not depend on finding the most hyped point in time to release
| it.
| kbr- wrote:
| > It's a simple keyword, but it singlehandedly eliminates the
| need for any kind of RAII.
|
| What if you want to put a resource object (which needs a cleanup
| on destruction) into a vector then give up ownership of the
| vector to someone?
|
| I write code in go now after moving from C++ and God do I miss
| destructors. Saying that defer eliminates need for RAII triggers
| me so much
___________________________________________________________________
(page generated 2025-04-18 23:01 UTC)