4 ms·

The const improvements are indeed awesome. I wonder if there were any big improvements to compile times? Is that in the road map for this year?

steveklabnik 8y ago
We have not published a roadmap yet (I'm getting there), but compile times are always of a lot of concern to the compiler team and they're going to be working on it for sure. It's the #1 requested feature.
- bmer 8y ago
  I personally don't understand why compile times are such a concern, as the larger libraries I have worked with take less than a minute to compile. Are there programs that take hours to compile?
  - beatgammit 8y ago
    The edit + reload cycle is the biggest concern, though it's mostly moot these days with incremental compilation. However, I still dislike updating dependencies because it'll take several minutes to rebuild everything. Also, building third-party tools is a pain as well (compile diesel or ripgrep sometime), which is the most annoying part for me. Also, it's a bit annoying for CI since I like to make sure everything can build from scratch, and it can be quite the wait to see if your build succeeded.
    - burntsushi 8y ago
      Could you say more about the annoyances you experienced while compiling ripgrep? Is it just the time it takes to build it or is there something else?
  - blaisio 8y ago
    I think one of the main problems is programs compiled in debug mode are surprisingly slow and unrepresentative of things compiled in release mode. So, some projects have to always compile in release mode while testing things, and it takes a long time.
BigBoomBadaBEAM 8y ago
First of all, you have obviously no clue about any qualitative nor quantitative measure of improvement in terms of performance improvements. "Indeed awesome" is something that doesn't even relate to computer science as everything is context-dependent. But that's not the point I want to make. What I would like people to see is what kind of profoundly uneducated, uninformed and blatantly misleading, perpetuating obvious fallacies, comments you post on this website on a daily basis. So I took about 5 minutes (but I could have literally kept on forever) to gather a sample of the kind of putrid garbage you comment daily on this website. I think that it is crucial that individuals of your kind are permanently prevented from spreading their beliefs-I insist, beliefs, not facts, when answering to people's questions. There is no ordering, all of the quotes below are equally pathetic : 1) Yep. Exactly this. If you get a laptop that a GNOME developer uses, chances are you’ll run into maybe two issues a year. But try to get GNOME to run on two 4K displays and an RTX. But here’s the thing. Linux has won. Desktop is a dying market. Linux is literally the most used operating system on phone and in the data center, which is where it counts. >> I run three 4K displays using nVidia GeForce >> You do not cite a single number about proportions of desktops to laptops, hence you are simply assuming being right based on the fact that you think so. Corporate offices are full of desktops and I can vouch for it first hand. >> I wonder how much Microsoft/IBM DCs run Linux instead of licensed products they've been used to for years. >> Android and Linux are not the same. I would have expected from such a knowledgable computer science professor as you are to be able to discern the two. 2) Apple has transformed into a company that lags in innovation and only makes safe moves. >> Yeah definitely haven't heard of any new chips/designs/connectors/models in the last 10 years 3) I'm very worried about the bees. My theory is that the bees are going to go extinct, and that will be the butterfly that wipes us out. At the very least it seems highly probably we'll be in a state of total anarchy in a new dark age within the next fifty years thanks in part to unethical uses of technology. >> As much as bee extinction is an actual concern that should be addressed with particular emphasis on preserving the species, your formulation and the scenario you are extrapolating are plain and simple displays of the delusional person that you are and a medical treatment should be followed through immediately. 4) The reality of a language as large as C++ is that each project will only use a small subset of the language and libraries, and the nature of object oriented programming leads to vastly different architectures for similar problems. If you can, I would learn Rust instead. Rust is a much smaller language that purposely limits the way you use the language to encourage particularly safe practices, and tends to favor designs that are hierarchical instead of allowing hairball object graphs. Rust also guides you at the compiler level in ways that C++ programmers must learn to do by heart, or simply leak memory and create nasty patterns in their code. >> Adequate OO implementations rely on architectural and design patterns to solve similar problems efficiently when applicable >> I am not a Rust programmer and will not comment on anything related to it's features, nevertheless I can guarantee that only a mentally deficient individual would suggest a "purposely self-limiting language" for safety reasons and stating that C++ programmers "MUST LEARN BY HEART" how to write their code as there was not any sort of documentation available on earth. 5) So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000. [...] To me, Go is a better Python. It's easier to learn, faster, more scalable, and safer, and just as easy and quick to write. It's just not a language for big projects. >> I am not even going to comment on this, it is sufficiently debilitating on its own. 6) I use Python as a prototyping tool only, and I mean prototyping in the sense that the code will always be thrown away and rewritten in a more suitable language. >> If I was the unfortunate person who employs you, or one of your team members and discovered that your development consisted in conceiving prototypes that you "throw away" so that you can rewrite them in a more "suitable" way, Not only would I fire you for intentionally destroying company property, but I would make sure that every single potential employer in a 1000 miles radius was warned of your dishonesty and/or incompetence. 7) I also think the reliability of BEAM is happening at the level of orchestration with containers and serverless. The BEAM itself doesn’t fit well into the cattle model of reliability and it has scalability issues when you reach a certain cluster size. >> "Reliability of BEAM" is possibly the least relevant and most generic metric that you could have come up with. First of all, Erlang is one implementation of the BEAM, an Abstract Machine and if your requirements are not satisfied by it, you are the only responsible for choosing a suboptimal technology for implementing your program. If it does not fit your "reliability" expectations, you are free to extend it accordingly or orient yourself towards another stack. >> If you were actually trying to refer to Erlang's fault tolerance capabilities, then are plain wrong and "orchestration-level reliability of BEAM" is probably something that your troubled mind has made up. >> Please name one technology that does not face scalability issues when it reaches a certain cluster size. Let me guess : Rust ! I am sure that Rust does not require any sort of adaptation at large scale, wether it be 100.000 or 1.5B user nodes. 8) I don't think any BEAM language will ever be a good goto language. The BEAM isn't good at general purpose computing. It's not particularly efficient at performing calculations or using memory. >> General purpose computing in Erlang can be done by the means of Higher Order Functions that are without any limit on the level of nesting, hence providing an additional layer of genericity for each order increase. >> "Performing calculations and using memory" adequately is YOUR responsibility.

steveklabnik 8y ago

We have not published a roadmap yet (I'm getting there), but compile times are always of a lot of concern to the compiler team and they're going to be working on it for sure. It's the #1 requested feature.

bmer 8y ago
I personally don't understand why compile times are such a concern, as the larger libraries I have worked with take less than a minute to compile. Are there programs that take hours to compile?
- beatgammit 8y ago
  The edit + reload cycle is the biggest concern, though it's mostly moot these days with incremental compilation. However, I still dislike updating dependencies because it'll take several minutes to rebuild everything. Also, building third-party tools is a pain as well (compile diesel or ripgrep sometime), which is the most annoying part for me. Also, it's a bit annoying for CI since I like to make sure everything can build from scratch, and it can be quite the wait to see if your build succeeded.
  - burntsushi 8y ago
    Could you say more about the annoyances you experienced while compiling ripgrep? Is it just the time it takes to build it or is there something else?
- blaisio 8y ago
  I think one of the main problems is programs compiled in debug mode are surprisingly slow and unrepresentative of things compiled in release mode. So, some projects have to always compile in release mode while testing things, and it takes a long time.

BigBoomBadaBEAM 8y ago

First of all, you have obviously no clue about any qualitative nor quantitative measure of improvement in terms of performance improvements. "Indeed awesome" is something that doesn't even relate to computer science as everything is context-dependent. But that's not the point I want to make. What I would like people to see is what kind of profoundly uneducated, uninformed and blatantly misleading, perpetuating obvious fallacies, comments you post on this website on a daily basis. So I took about 5 minutes (but I could have literally kept on forever) to gather a sample of the kind of putrid garbage you comment daily on this website. I think that it is crucial that individuals of your kind are permanently prevented from spreading their beliefs-I insist, beliefs, not facts, when answering to people's questions. There is no ordering, all of the quotes below are equally pathetic : 1) Yep. Exactly this. If you get a laptop that a GNOME developer uses, chances are you’ll run into maybe two issues a year. But try to get GNOME to run on two 4K displays and an RTX. But here’s the thing. Linux has won. Desktop is a dying market. Linux is literally the most used operating system on phone and in the data center, which is where it counts. >> I run three 4K displays using nVidia GeForce >> You do not cite a single number about proportions of desktops to laptops, hence you are simply assuming being right based on the fact that you think so. Corporate offices are full of desktops and I can vouch for it first hand. >> I wonder how much Microsoft/IBM DCs run Linux instead of licensed products they've been used to for years. >> Android and Linux are not the same. I would have expected from such a knowledgable computer science professor as you are to be able to discern the two. 2) Apple has transformed into a company that lags in innovation and only makes safe moves. >> Yeah definitely haven't heard of any new chips/designs/connectors/models in the last 10 years 3) I'm very worried about the bees. My theory is that the bees are going to go extinct, and that will be the butterfly that wipes us out. At the very least it seems highly probably we'll be in a state of total anarchy in a new dark age within the next fifty years thanks in part to unethical uses of technology. >> As much as bee extinction is an actual concern that should be addressed with particular emphasis on preserving the species, your formulation and the scenario you are extrapolating are plain and simple displays of the delusional person that you are and a medical treatment should be followed through immediately. 4) The reality of a language as large as C++ is that each project will only use a small subset of the language and libraries, and the nature of object oriented programming leads to vastly different architectures for similar problems. If you can, I would learn Rust instead. Rust is a much smaller language that purposely limits the way you use the language to encourage particularly safe practices, and tends to favor designs that are hierarchical instead of allowing hairball object graphs. Rust also guides you at the compiler level in ways that C++ programmers must learn to do by heart, or simply leak memory and create nasty patterns in their code. >> Adequate OO implementations rely on architectural and design patterns to solve similar problems efficiently when applicable >> I am not a Rust programmer and will not comment on anything related to it's features, nevertheless I can guarantee that only a mentally deficient individual would suggest a "purposely self-limiting language" for safety reasons and stating that C++ programmers "MUST LEARN BY HEART" how to write their code as there was not any sort of documentation available on earth. 5) So I don't know how to fly a commercial airliner, but I could probably figure my way around a small single prop airplane. That's basically the difference between Go and a language like Rust or C++ or any language that requires a lot of up front investment, but then let's you work at power level 9000. [...] To me, Go is a better Python. It's easier to learn, faster, more scalable, and safer, and just as easy and quick to write. It's just not a language for big projects. >> I am not even going to comment on this, it is sufficiently debilitating on its own. 6) I use Python as a prototyping tool only, and I mean prototyping in the sense that the code will always be thrown away and rewritten in a more suitable language. >> If I was the unfortunate person who employs you, or one of your team members and discovered that your development consisted in conceiving prototypes that you "throw away" so that you can rewrite them in a more "suitable" way, Not only would I fire you for intentionally destroying company property, but I would make sure that every single potential employer in a 1000 miles radius was warned of your dishonesty and/or incompetence. 7) I also think the reliability of BEAM is happening at the level of orchestration with containers and serverless. The BEAM itself doesn’t fit well into the cattle model of reliability and it has scalability issues when you reach a certain cluster size. >> "Reliability of BEAM" is possibly the least relevant and most generic metric that you could have come up with. First of all, Erlang is one implementation of the BEAM, an Abstract Machine and if your requirements are not satisfied by it, you are the only responsible for choosing a suboptimal technology for implementing your program. If it does not fit your "reliability" expectations, you are free to extend it accordingly or orient yourself towards another stack. >> If you were actually trying to refer to Erlang's fault tolerance capabilities, then are plain wrong and "orchestration-level reliability of BEAM" is probably something that your troubled mind has made up. >> Please name one technology that does not face scalability issues when it reaches a certain cluster size. Let me guess : Rust ! I am sure that Rust does not require any sort of adaptation at large scale, wether it be 100.000 or 1.5B user nodes. 8) I don't think any BEAM language will ever be a good goto language. The BEAM isn't good at general purpose computing. It's not particularly efficient at performing calculations or using memory. >> General purpose computing in Erlang can be done by the means of Higher Order Functions that are without any limit on the level of nesting, hence providing an additional layer of genericity for each order increase. >> "Performing calculations and using memory" adequately is YOUR responsibility.