This is very much the case! I started tinkering with compilers around 4 years ago when I was 16. If it was possible for me to do then, I'm sure it's possible for anyone else to learn too.
When I write articles like these, I think of what I would have liked to have read when I was first getting into the topic at hand.
I have the best of both worlds here where all of my amex credit bills come out from my Monzo account and my salary is paid into my Monzo.
The other features of the bank are what appeal to me personally, the fact that the UI is so much nicer to use than most other banks, as well as they are pretty progressive in terms of features.
I can see when my credit card bills will come out (it warns you a few days prior with an estimated amount of the bill), and I can see rundowns of my spending, etc.
To be honest, the project is kind of mimicking Slick2D which is a simple Java framework that introduced me into graphics programming in the first place.
My kind of dream project here is to maybe make a little tutorial series on how to use the library making a small game with it. Maybe inspire a few young people to get into graphics/game programming to show how simple it is - in the go domain specifically.
The library is kind of a no thrills graphics library, maybe I should market it that way.
The project doesn't really market itself too much right now, and I don't think I will focus on that till I've written a reasonably polished game in it either. But thank you for that link I will bookmark it.
Kind of just throwing the project up on here for people to look at & critique.
And that is a point... the feature project is a text editor. Though I think it looks a bit more impressive than the alternative which is a little game I'm working on in my spare time.
The library itself is worked on from time to time. The last commit was a few days ago (a small patch however).
Honestly, I’d love to see a project like GoRails but for game programming, maybe with quarterly topics on eg making a FPS, RTS, etc. I would definitely pay a subscription for that.
> Go is also flexible in that it does not enforce a particular style of programming
That’s actually kind of a main theme of Go, that it’s very opinionated about what the right way to program is, and doesn’t do you any favors if you try to use it to do things in a way it doesn’t think aligns with that.
Maybe you would like the BetterC mode in the D programming language... if you mean you like C for it's syntax too. A lot of modern systems prog. languages seem to adopt a more modern syntax, i.e. types after the names rather than before, no semi-colons, etc.
D stays true to C in this regard and offers a lot of fancy features. And the BetterC mode sounds suited to your requirements in that the language features doesn't over complicate things.
It's mostly a disclaimer for the time being. I'm making no guarantees that the editor will meet those claims at it's current state - but that's the end goal.
I would say compiles is a more general form of transpiles. Transpiling meaning it compiles into a higher level form i.e. c, C++, JavaScript, and compile meaning it compiles into a more lower level form i.e assembly, bytecode, etc?
The link to optimizing an ANSI C interpreter is broken, it's missing a colon after the protocol. I dunno if there's anyone here that can fix that, just thought I'd say it anyway.
Actually it's not the colon, there are two protocols:
As a maintainer of an open source project, we often get a lot of proposals from people - my project is a compiler. And while some of them are interesting, there are a few who are suggested by people who don't really have any experience in language design, so usually we have to say no to a lot of features.
When someone knows what they're on about, it's probably the architecture of our project that doesn't allow us to implement a specific feature; or would make it incredibly difficult to do so. And when you're dealing with even larger projects like Nginx or something, you have to work on it to know if something would work in terms of the project, which is tricky unless you've worked on it extensively.
We've even had a guy who said we shouldn't use LLVM because it's slow (it's not), and he didn't like it. What I'm getting at with this point is that some people suggest ideas that a) change the entire course of the project, or b) are kind of silly and subjective.
When I write articles like these, I think of what I would have liked to have read when I was first getting into the topic at hand.