171–180 of 255 posts
Wow. Anyone remembers Rust pre-0.1? When it had typestate, ML syntax, garbage collection, etc.? So nice to see how the language slowly evolved and was molded to fit as best as possible the problem they were trying to solve.
Earlier quoted context omitted.
Ugh. I hate gofmt. It's a good idea in principle, but even with "go" there are times when you want things spaced out to align columns, or hide a distracting error handling case on one line (instead of making it take 3 lines of precious vertical screen real estate). I find gofmt to be too opinionated about certain things and I will never use it for my go programs.
Why is it a good idea in principle then? Automatic reformatting of the source code always seemed like a bad idea to me for precisely the sort of reason you describe.
The point of an automatic formatter isn't to make the code look pretty. It's to make the code non-ugly, with as little effort as possible. Obviously, there will be cases where the formatter screws up and writes out something pretty ugly. The point is to train yourself to ignore these, because honestly time spent looking at, angsting over, and fixing bad formatting is about the worst possible use of your development time. Instead you could be thinking about solving a problem that hasn't been solved before, or making the product easier for a user to use, or refactoring semantic issues in the code that trip up developers.
Earlier quoted context omitted.
1) A lot more code isn't read in vim or emacs nowadays. We don't have the equivalent of indent on the github web ui 2) Everyone and their mother is doing code reviews now, and a lot of code reviews get (very visibly) bogged down by style disputes. 3) indent and his modern friends (eg clang-format) generally only answer trivial whitespace questions, and not even things like method capitalization. gofmt is the obvious…
Whether it's called indent, gofmt or Visual Source Formatter 2051 doesn't really change its availability. Nor does it really matter a lot how much of the source is munged -- every forced change is probably annoying to someone. The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call shou…
It's rarely a good idea to reproduce the same patterns in two different languages (except for things that are common anyway, like indentation etc.).
And the main argument for a language-global code style is that you don't need to teach new commers (to your company/project) which code style you follow, you don't need to have long discussions about whether the article #36 is being respected in that last commit, if the code style version you had is up to date, etc.
One great example: Python and PEP8. It's the standard, everybody accepted it. That means that all libs use it AND (almost) all companies use it internally, which makes friction between different modules from different sources minimal.
Earlier quoted context omitted.
Whether it's called indent, gofmt or Visual Source Formatter 2051 doesn't really change its availability. Nor does it really matter a lot how much of the source is munged -- every forced change is probably annoying to someone. The main issue for me is that your code reviwer isn't looking at the code from my company. So why should I give a damn what they think about how spaces around the parens of a function call shou…
I think you're kind of missing the point. The point isn't to have a "house" style, it's to have an "everything" style. Making it optional or configurable defeats the purpose.
If you want to solve the problem that people are writing in different styles and there should be one true style for a language, why? You're bound to get something wrong in your style initially, and it will be annoying from then on, and hard to change. It actually seems the antithesis to how Rust was developed, which was to keep trying things to see what worked.
Earlier quoted context omitted.
I'm a game developer and I don't use inheritance a lot, and when I do use it it's almost never for virtual dispatch. (I wouldn't mind it being added to Rust, but I don't expect I would use it). Anyway, if you're already doing a component based system, why do you need inheritance? Just do a normal ECS. You don't subclass GameObjects in most implementations of ECS (and this is a good thing).
I guess I should do some more research regarding that. Although, I just liked the idea of inheriting from a base "empty" game object. It makes it easy to have lists of GameObjects. Also, all of my components inherit from a Component class which makes it possible to AddComponent() and GetComponent(). That way, a user of the game engine could create a new type of component and easily add that to any game object. Howeve…
Never do this. Just don't. What you should do instead, is write a game, and while writing that game, write its engine. At the same time (Or even, write a game, and then refactor the engine out as you go).
Then, after you're done, that engine can then be extracted and made to be more generic. This is basically how every engine used in the game industry was made (although in many cases the game the engine was written with never shipped).
Trying to make a generic engine from the start will be worse in basically every measurable way. It will take longer to write, take more code, use more memory, and be slower...
Again, sorry if I misjudged your comments. Anyway. On to what you said specifically:
Having an empty base object so you can have lists of GameObject (presumably lists of `GameObject*` in reality) is basically going to destroy performance and the cache. A reasonable rule of thumb is that a read from memory will take about 100 times longer than, say, a float multiplication, unless you know it will be in the cache. Then, to operate on these game objects, you'll probably use virtual methods. Another rule of thumb is that vtables are basically never in the cache (and they're also unpredictable branches).
Really what you want to have is several flat arrays of the data each part of the engine needs to operate on. This is also good from an encapsulation standpoint, because then each part of the engine only can see what it needs, and not necessarily the whole game object. Then, the way you'd implement a component system in this style is that you'd make that array the canonical place the data lives.
This can work well for some games but isn't worthwhile for every game. (Generally I actually think the biggest benefit is that it makes gameplay and tools for non-developers easier to write.)
Earlier quoted context omitted.
The upside to a batteries-included stdlib is, of course, that you don't have to go fishing around for the best lib to do $WHATEVER_PARTICULAR_TASK, and you also don't have to wonder whether whatever lib you eventually choose will be abandoned by its developer next month. At such a young stage of language development, I agree that it makes more sense to let the community develop libraries in order to foster competitio…
I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? But would agree that the only thing Rust might need are officially supported crates, while keeping the language itself fully separate. The language is then completely free of the hastles of maintaining a stdlib that probably isn't used by most people anyway. But at the same time offici…
Python, Go, C++'s STL, Java SDK, to name a few.
They might not be 100% perfect, but they are good and reliable, and always there for you. Hunting the latest "best" library that gets abandoned after a year (like in Javascript and Ruby often happens, and also Go too) gets old quickly.
Of course there could be a compromise approach, as you say.
A mininal standard lib for Rust PLUS a "blessed" set of Cargo packages that represent the batteries (Haskell "Platform" is like that, IIRC).
Earlier quoted context omitted.
I'm a game developer and I don't use inheritance a lot, and when I do use it it's almost never for virtual dispatch. (I wouldn't mind it being added to Rust, but I don't expect I would use it). Anyway, if you're already doing a component based system, why do you need inheritance? Just do a normal ECS. You don't subclass GameObjects in most implementations of ECS (and this is a good thing).
I guess I should do some more research regarding that. Although, I just liked the idea of inheriting from a base "empty" game object. It makes it easy to have lists of GameObjects. Also, all of my components inherit from a Component class which makes it possible to AddComponent() and GetComponent(). That way, a user of the game engine could create a new type of component and easily add that to any game object. Howeve…
http://bitsquid.blogspot.com/2014/08/building-data-oriented-...
A couple of commercial games have been built on that engine and it was recently sold to Autodesk, so it's not just handwaving.
Earlier quoted context omitted.
is it really "so nice"? I wish they had been able to go forward with typestate :(
This is a very old post, but you can encode many uses of typestate pretty easily: http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/ It'd be great for someone to write a more up-to-date version of this post!
Can Rust still do phantom types, and I just can't see them anywhere in the language reference?
Earlier quoted context omitted.
This is a very old post, but you can encode many uses of typestate pretty easily: http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/ It'd be great for someone to write a more up-to-date version of this post!
Haven't used Rust, but I wonder what you could use in place of the phantom types? Are Traits capable of filling this role? Am I completely misreading what Traits are? Can Rust still do phantom types, and I just can't see them anywhere in the language reference?
struct Foo; // `T` is a phantom type parameter.Earlier quoted context omitted.
I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? But would agree that the only thing Rust might need are officially supported crates, while keeping the language itself fully separate. The language is then completely free of the hastles of maintaining a stdlib that probably isn't used by most people anyway. But at the same time offici…
> I think the stdlib is not the way to go. Give me an example of any ecosystem where the standard library is the defacto best solution? Python, Go, C++'s STL, Java SDK, to name a few. They might not be 100% perfect, but they are good and reliable, and always there for you. Hunting the latest "best" library that gets abandoned after a year (like in Javascript and Ruby often happens, and also Go too) gets old quickly.…
Hardly. See Joda Time (it only took 10 years for java.time to catch up) and Apache Commons (the situation is much better now, but who hasn't turned to Apache Commons due to shortcomings in Java's standard library?).
In any case, I definitely agree with the frustrations of trying to find libraries for Ruby.