Hacker Newsnew | past | comments | ask | show | jobs | submit | jopamer's commentslogin

The standard library is open source, you can find it here: https://github.com/modularml/mojo/tree/nightly/stdlib

We'll be opening up more over time - stay tuned!


Just in case you're in the know:

I was really really close to trying to spin up something at work using the Max Engine. However, I see that it collects telemetry [1], and we can't really allow that. Do you know if there are plans to be able to turn this entirely off at some point?

It's nice to know if I should keep it on my radar, or if I can't consider it without changing jobs :)

[1]: https://docs.modular.com/engine/faq#does-the-max-sdk-collect...


Please reach out to us to talk through it, I'm sure there's a way to work it out.


There’s nothing bad about telemetry per se. In fact it should be considered bad to not be paying attention to how anything you build works in the real world.

(Then comes Meta c.s. and everyone rightly distrusts anything reported back from their computer)

This just to say, that yes, the majority of companies cannot be trusted, but there’s still good guys out there collecting useful metrics completely devoid of secondary malicious purposes.


Intentions be damned. Some industries take IP/security very seriously (eg regulated medical). Tools which phone home “for my user experience” are a complete deal breaker.


QED


I just wanted to say that I enjoyed this comment so much. As a Jag owner at the time I remember being taken by the production shots of that game that popped up in magazines, and couldn't wait to see it in motion. The craftiness necessary to pull off a compelling rendering pipeline on the hardware of that time period, combined with the aesthetic directions the constraints pushed designs in, still inspires me. (And somewhat indirectly led me down my own career path.) Thanks!


Hey, thanks for the uplifting comment!

If we had published on the Jaguar, maybe that would have led to a whole different career for me too :-)

It's lovely to think someone outside the company enjoyed it. Because it was never published, it felt like multiple years put into something that just disappeared, and I didn't get much feedback from outside the company. That happened with the next game I worked on too, Mr Tank, which was more technically advanced and a lot of fun to play in the demos.


Thanks, Steve! I'm well aware of the type checker's problems with 'lazy', and it's something I hope to address soon.


While you're here, I should say: first, thanks for your work, and second, it would be nice if the compiler could log the timing data in a consolidated form so my script wouldn't be necessary. :-) Regex-parsing and aggregating a bunch of log lines seems dicey.


Unfortunately, debug-time-function-bodies isn't an "officially" supported flag, so improving it isn't a high priority right now.

...That said, we'd be more than happy to take improvement PRs in this area, if you're feeling up for it!


(FWIW, I just pushed a fix for this bug.)

EDIT: To be clear, addressing these kinds of issues is something we've been aggressively pursuing for Swift 3, and will continue to do so.



Is this construct commonly used in swift or is it an edge case? I've seen people referring to it as an edge case, but at the same time this is code which I find my self writing pretty often in other languages, for example when initializing data for unit tests.


A few years back, Dr. Dobb’s posted a pretty great series of articles on some of the techniques RBK Dewar employed when building the original SPITBOL compiler: http://www.drdobbs.com/cpp/some-programs-are-poorly-designed...

(I was lucky enough to study compilers under Prof. Dewar when I was a grad student at NYU - I still have my notes on SPITBOL’s architecture, somewhere…)


Excellent article, very clever optimizations given the tradeoffs. From the article:

> We were talking about students' tendency to let the compiler substitute for thinking

This is actually why I use OCaml. Not going to comment on whether useful error messages are a detriment to pedagogy, but offloading thinking to the compiler is a lifesaver.


Definitely. It doesn't prevent, say, off-by-one errors (and in general, errors when you manipulate several items of the same type), but if you structure your program correctly, you can be very confident about your code.

Though OCaml's errors are not always the most explicit or nicely written.


Our language service APIs are all open source, so feel free to hack together support for your favorite IDE and let us know! (Check out the code under src\services, and let us know if you have questions.)


[Disclaimer: I'm a compiler dev working on F# at MSFT.]

Performance and user experience on Mono are something we're definitely trying to improve - we spent a fair amount of time trying to make our Mono story better for our 2.0 release, and plan on investing more in this area as we move forward.

We can't be everywhere at once, so your feedback is really important here - If you're having problems with our tools on Mono, please let us know via Microsoft Connect or fsbugs@microsoft.com. Also, don't be bashful about filing Mono bugs. So far, they've been really great about responding to any issues that have cropped up.

Thanks!


Thats awesome! Thanks for sharing. I'll give Mono/F# another spin in the next week and will report problems as suggested by you. Again thanks.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: