smosher_

You are probably experiencing a syntactic illusion where it looks like C++ but then it looks all wrong. I've used Rust and it didn't take long to get acclimated.

> I'm not sure what your point is here. Talented programmers have been releasing stuff that works great on shitty platforms forever. If the money is there, you work around the nonsense, warts and all.

That is precisely my point. We're still doing it and we will be doing it for the foreseeable.

For example:

> It doesn't mean DirectX 6.1 is a great 3D game platform [...]

If your opinion is DX6.1 didn't work, I think what you really mean is "isn't the best option under ideal circumstances today." I would agree with that assessment for mono, but "cross-platform" is not something anyone puts next to "ideal circumstances" when it comes to the work involved in making it happen.

> It feels like we're debating whether the Mono bullshit was waist deep or merely knee deep.

There is certainly bullshit to contend with in mono, but there's bullshit in Microsoft's too. And every other platform throughout the ages as you helpfully illustrated. A topical example is porting a game in C++ vs. writing working code for mono. C++ is uncontested as a working technology, but I would pick Unity on mono in a heartbeat for that task. So where is the line, really? In development all you can do is keep above it and all the better if you can keep your socks dry.

I get the impression you are very unimpressed with mono's failings and have written it off and want to complain about it. That's fine but it doesn't mean the hyperbole you've chosen to express yourself is accurate.

Unity works though. Unity games have a much better batting average in my experience than C++ ports, and I have more problems with "cross-platform" games and other applications written in Java.

These aren't hobbyists and they're not definitely not apologists. They're making good money on it. If it was as bad as you say, why bother with the Linux/Mac support to begin with? That's just noise compared to the Windows market.

I also have to point out that an ancient version of mono being problematic doesn't mean mono failed or doesn't work. By my measure, even that old version of mono works.

I don't know what your metric is. People ship working code and make money in parts of the market they wouldn't otherwise have. But I guess that doesn't count in the face of what? your decision not to use it?

> This indicates the formal death of the ecosystem to anyone but apologist hobbyists and thankfully we've gotten to a better place now.

A couple of things. First: "This", so far, is anecdotal and doesn't indicate much of anything, really. For something concrete, look at Unity. Maybe you haven't used anything built with it, but everything I've seen come out of it works just fine.

Second: Apologist hobbyists? That's not true and needlessly insulting. If your aim is to just marginalize anyone with a differing opinion please don't expect me to take you seriously.

> But yeah, I think it's okay to say "it never really worked."

I don't. I mean yes mono <4.0 has a lot of problems, but it works well enough for me to shell out money for applications running on mono and be happy about it.

Okular

Thanks, my pdf reader can trim margins and make two columns out of one, but it can't make one column out of two.

Exactly what depends on what exactly the problem turns out to be once diagnosed. Issuing an ANY query is often the first step in the diagnostic process.

> assuming you are hosting DNS on cloudflare of course

That doesn't have much to do with it. Most of the DNS problems I run into involve 3rd parties. So the question becomes "how likely is it they're using Cloudflare?", the answer being "increasingly so."

I don't follow, what exactly is not the case?

Edit: by the way, are you the one downvoting the posts critical of Cloudflare? I noticed you contribute to their repos on GitHub, and I didn't spot any downvotes on comments that are replies to yours.

> ANY queries are not widely used by any real world software. We aware of only two programs that issue ANY queries

Does no one at Cloudflare use dig?

I agree that applications shouldn't be issuing ANY queries¹ under normal circumstances but without being able to perform these queries in tools like dig, a lot of sysadmin/support staff time would be wasted. (AXFR isn't a suitable replacement in this situation because it's disabled or restricted practically everywhere these days.)

¹especially qmaild, even when fetching only MX records, the bug linked from the article will appear when there are enough MX records.

> But can you guarantee that no information is lost by exporting?

You practically never can when exporting in any format, from any program, since few formats are subsets of any others. The important thing is to be able to export the information you need. Most formats cover the same things, so chances are you can export what you need.

FWIW, I've seen a few projects that import blend files. Serialized memory dumps are not a bad thing and are easy to write loaders for (as long as they're documented sufficiently and/or have libraries available.)

I don't see why you would need to have a separate format. As long as .blend is fully documented up to the point of being able to recover all the application-agnostic data I don't see a benefit to splitting off another format. It might make sense to omit the Blender-specific UI data and so on, but I don't think that really needs a separate format to accomplish.

> and I had bad experience with the Blender exporters in the past on this point

Bad experiences with Blender exporters will probably never cease. Many of them are written by a single person to scratch an itch and do the minimum they need from it. That isn't to say you won't find quality ones, but unless and until all formats have exporters in-tree and are dutifully maintained, there will be occasional breakage. The good news is the quality tends upward, so exporters for common formats are probably a lot less disappointing today than when you last tried them.

Please try to read all the words before making implications about the author's character.

> If you write a standard, and no one uses it, what use is it exactly?

Only non-people don't use Apple, got it.

> When the vast majority of mobile revenue is generated by iPhone users, that means if it doesn't work on iOS, it doesn't work at all - 80% marketshare be damned.

How does this matter to Google or the W3C exactly? I don't buy this reasoning.

The CPU analogy doesn't work either, since everyone depends on a number of different processors, with Intel approaching 100% representation among individuals—this doesn't hold for iOS in the mobile market, where people typically depend on one phone.

That said, iOS might have stronger representation among the people who depend on mobile browsing than the market share numbers suggest (but that needs measuring.) My guess is that even as low as 20% of mobile is sufficiently significant to Google (whose employees all seem to have MBPs) and two major vendors is likewise to the standards committee.

> I'd imagine the best thing to do is commented on the article. Create a Polyfill, and if PointerEvents are better than the rest, developers will naturally use them. Eventually given the huge amount of developers on the polyfill Apple may be inclined to make it native.

Very yes. I'm not completely sold on pointer events but the tactic encourages real-world exploration.

Considering .exp results in a Num, not a Rat, there's no problem here. I seem to recall this working sensibly years ago, where numerical types would coerce in sensible manner. Same happens with large denominators, so even if you roll your own successive approximation it will coerce away from Rat before things get out of hand.

Yeah, although Google and others were always willing to monetize your work without your knowledge or consent. To some degree that's how the internet works and it's not _entirely_ a bad thing, and a lot of it is not intentional (photograph a painting, share it on forum with banner ads.) But with Google, their change is now they're unwilling to give back without a contract.

Your parent was modded down for bringing nothing to the conversation. It might as well have read "lol google."

Unfortunately other similar media aren't as lucrative. Even if they pay as well, not being on YouTube creates an exposure problem. I hope there's some way to work this out, but to be honest, Google still seems to me like the least sleazy company to help you monetize your music, and that's not a compliment to Google.

The information isn't necessary for the compiler to reason about the program. The information is, in my opinion, useful for humans to reason about the program. The fact is I would reason about programs quicker if this was explicit.

There isn't any more information to consume. The information is exactly the same. It's just different, which is why I think it should look different.

> but I assure you that if you actually used it, you would have found what you suggested even uglier.

It's not fair to make that judgment for someone, particularly because people using Rust at the time weren't complaining much about how ugly it was. At the time it was questioned whether the change was desirable and that very blog post braces for opposition under Wait, doesn’t this make it hard to know what your program does?

Fwiw, that's one instance where unnecessary information/features were removed I would rather had been preserved.

> Lyla Blue, all dolled up with markers. The hand-scrawled note on this photo print said "Slash's Wife, I swear." Anybody recognize her from the back?

Slash the guitarist? She does look like a fit for Renée Suran: http://www.bing.com/images/search?q=Ren%c3%a9e+Suran&id=526D...

Sorry this is so long, I deleted many paragraphs.

Something about this doesn't sound right to me. I think the third-party factors are overwhelming. After all, the basic I/O and other low-level stuff is going to be there on any supported OS. But availability of compilers/VMs/interpreters, and good libraries for GL, Qt, audio, etc. are all at the top of my reasons for not going with a particular language that would otherwise be suited to the task.

I think Rust is in a better position than one would normally expect. People are looking at it for web dev, and web devs tolerate more diversity in their language of choice. The existence of Go, and the frequent (if misguided) comparisons to Go helps, since writing a web-facing app in Go is a sensible thing. I'm not sure if that will work out, but if it does I think it's a trump card. No web language ever died, except things like Cold Fusion and languages that were superseded by offerings from their own vendors.

On the other hand, I think Rust is better suited to game development. I don't know of Carmack being sweet on Rust in particular, but a few years ago he did start talking about how it would be nice if id could use safer languages (though his biggest complaint was about script writing.) More to the point, Rust is growing a collection of gamedev libraries. Piston is ambitiously trying to curate an entire ecosystem. This is a rare phenomenon among the pretenders. Piston is in no shape to take over the world today, but if it continues to grow and polish it could turn a number of heads.

I'm not sure how having an official OS SDK helps all that much if they also ship a C or C++ SDK. Anyone could write and maintain one for Rust, so what's the difference?

Nice. I had seen some list-indexing uses of squareBrackets before. This looks interesting, also reminds me I should write tests.

To play the advocate, given that by default compilation produces a binary that includes over 2KB of Lovecraft quotes¹, this article at least serves to reassure people that you can produce a compact binary with Rust.

¹ https://github.com/rust-lang/rust/issues/13871

> Io also suffers from Scheme's problem, where a minimalist language is more likely to calve a multitude of private and mutually incompatible frameworks.

I think that could be addressed in exactly the way Ruby addresses it, by having a popular leading framework. Although in Io's case there are some gaps in the standard library that I think need filling. For example, there's no reason it has to be painful to do Unix scripting.

Another consideration is that frameworks in Io don't need to be brought into conflict. It's still a trap, but it can be navigated and I really don't think the situation is any worse than Ruby's.

I'm fond of the post Lazy Bricks, Lazy Mortar¹ where he basically pulls a rabbit out of a hat. It's a shame he didn't write more posts about Io.

¹ http://web.archive.org/web/20080430135919/http://hackety.org...

As someone who loves Io, it gets my attention because:

— the language is very mutable, almost all behaviours can be modified

— it's simple, all you can do is send messages to objects

— you can write DSLs and macro-like things without special macro support

— it's so dynamic you'll end up live-coding without realizing it

It has less syntax than Smalltalk, it's homoiconic like Lisp, but doesn't need support for macros because of the way messages are handled.

A not intolerable way of thinking of Io is it is to object calculus what Lisp is to lambda calculus. There are parts where that analogy breaks down but it's not a bad first approximation.

edit: formatting

Convenient timing, I just started working on a project to pull my Io DSLs and convenience protos into something more cohesive. So, plug: https://github.com/smosher/IoSetting

Included are DSLs for List and Map construction, homoiconic pretty-printers for List and Map and a few other things. I plan to do a lot of work to make List nicer to use, plus some experimental constructs for... experimental things.

I was going to wait until this got a little more mature before mentioning it anywhere, but I figure I should mention it in this thread.

Did he? I was under the impression he wasn't approved to write C at Google when Go was initially being developed.

http://www.theregister.co.uk/2010/04/21/ken_thompson_take_ou...

At some point you'll end up with breakage unless doing this _causes_ the subclasses to implement the initializer with super (if not already present), not just require it. I don't really like that, but it might actually work.

You shouldn't really get to mess with someone else's implementation... that's partly what subclassing is for and that's where it should get fixed. I'm not really familiar with the barrier here since Swift isn't available on my platform, but I can't think of a reason for it to be such a problem, unlike the the other road.