Rust 1.0 Enters Beta 211
An anonymous reader writes: Rust is a systems programming language focused on safety and speed and aims, among other things, to offer memory safety without garbage collection and threads without data races. Over on the Rust blog, the Rust Core Team has announced the release of Rust 1.0 beta. They write, 'The beta release marks a very significant "state transition" in the move towards 1.0. In particular, with the beta release, all libraries and language features that are planned to be stable for 1.0 have been marked as stable. As such, the beta release represents an accurate preview of what Rust 1.0 will include.' The final Rust 1.0 release is scheduled for May 15th, 2015. A warning from the developers: "Rust is a work-in-progress and may do anything it likes up to and including eating your laundry." The FAQ is worth reading.
Likely interesting (Score:3, Funny)
Re: (Score:1)
It's been in development for years. 1.0.0 means it is polished now, at least on the level of the language.
Have you actually tried using Rust? (Score:2, Informative)
Have you actually tried using Rust? I have, and I can tell you that it isn't "polished".
Maybe it won't change as goddamn much as it typically has each day, but it's not a clean language like say Python or C# are.
Its library API is something awful. You have to write stuff like:
The memory management approach is also, to put it nicely, a royal pain in the ass to use. Maybe it can guarantee a higher level o
Re: (Score:2)
Rust is a very tedious and anal language to use, to the point of any safety gains being eliminated by much slower development time.
Well, with that, it is likely far more efficient to have somebody that does understand both C and secure coding to do things in C. The thing is that Rust cannot eliminate all security problems anyways, and the remaining ones will be much more obscure. It also will introduce problems of its own, just as any language with tight control does, and for some of them, only a fix on the language side will help.
All in all, I am not sure this is the right approach. It seems to be geared at letting less competent code
Re: (Score:2)
You are essentially blaming all security bugs ever on "incompetence". That's lazy management in the business world and it's stupid everywhere else. C has numerous and many traps. Building tools which make it impossible to make the "easy" mistakes is how we get to spend more time thinking about the actual hard ones.
Re: (Score:3)
No, I do not. What I am pointing out is that this language will have "management" assign even less competent people to do "secure code" than they do now, for a likely net loss in security.
And besides, Rust does not prevent you from making all "easy" mistakes either, just some of them.
There is this class of "tool fetishists" that think all problems with coding can be solved by just using the "right tools". You even hear that opinion form people that really should know better. Well, guess what, if that were p
Re: (Score:2)
Well, guess what, if that were possible, we would have the right tools by now. The fact of the matter is that performance, security, maintainability, etc. cannot be enforced by tools.
I take it you do all of your programming in assembly language, because there's nothing to be gained by using anything higher-level than that, because you totally know what you're doing at all times?
(Or if not, you've tacitly admitted that there is a benefit to using a tool that enforces some level of safety; you're only quibbling about what that tool should be)
Re: (Score:2)
You can stick your innuendo up you backside, where it properly belongs.
Tool selection is a matter of convenience. Hence I have currently standardized on Python glue-code with C-modules wherever performance is critical. (I would have standardized on Eiffel, but it is too far in a niche...) This has nothing to do with security. In order to make my code secure, I have to understand any and all of its external interfaces, how to protect them and then make sure in addition that all my assumptions on the internal
Re: (Score:2)
"No silver bullet" was written almost 30 years ago, and you people are still searching for it?
That's because it was a through-and-through. I can write programs far grander in both scope and complexity than almost any programmer of 30 years ago. The reason is not because I am a super-awesome-uber-l33t programmer it's because modern tools are really very good.
I would argue that's the case for most programmers now.
If that's not a silver bullet, then I don't know what is.
Re: (Score:2)
scope and complexity say absolutely nothing about the quality of code
why did you choose those two words instead of "[...] programs far better than almost [...]" ?
Re: (Score:2)
Your average desktop computer, compared to a system from 30 years ago, is over 7,000 times faster, has 3-6,000 times as much RAM and 1.5 million times as much persistent storage available, and can communicate over 4,000 times faster, and that's not even getting into graphics capabilities.
There's more code in the boot ROM than there was in the boot ROM plus OS plus several applications.
It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write pr
Re: (Score:2)
scope and complexity say absolutely nothing about the quality of code
So? I can write programs that do more useful stuff than most programmers from 30 years ago. Doing useful stuff is the ultimate goal. And like I said, it's not because of me it's because there are excellent tools and techniques for managing the complexity of large problems.
Re: (Score:2)
It's not that programming tools are so much better, or that programming techniques have advanced, it's that you can write programs with many fewer restraints.
It's a mix of both. It's 2015, so that makes 1985 30 years ago. The '85 era computer I have most experience with is the BBC Model B. For the day it had an excellent implementation of BASIC: proper named procedures and functions and even an integrated assembler.
It didn't however even have proper block-structuring like the later QBasic for things like IF
Re: (Score:2)
In the meantime, plenty of people were writing things in Pascal for the Mac. You had a resource compiler with resource files. You could write things in C, on a Unix system. You could build things with "make". Most of the software tools used to compile Linux and most of the current standard software was already in existence. There were source code control systems. There was X Windows. There was TeX. There was PostScript. There were a LOT of things that make up the majority of the software tools stil
Re: (Score:2)
I think you have your timelines a bit wrong and/or a rosy view of the past. Firstly there's the question of what was widely available. The Mac 128 and unix systems were out of the reach of people like me back then, costing many thousands when thousands were worth a lot more. Unix was expensive and the compilers were outrageously expensive.
Price aside, things were very different. On unix, you had the frankly awful builtin tools which would do nice things like crash if you used a line over 100 chars long. Lot
Re: (Score:2)
I was programming in Pascal on a Lisa (dual boot to the Lisa command-line OS (Lisa Workshop) for development and MacOS for testing, occassionally booting to the Office environment). I bought it shortly before it came out as the MacXL, so had non-square pixels. I wasn't rich, and it wasn't any more expensive than a PC would have been with the same capacity.
The entire thing (Office 7/7, Workshop, MacWorks) plus system partitions for each was 10MB. System RAM was 1MB. I can compress and copy that whole syst
Re: (Score:2)
I think you're both right and wrong. Clearly, a safe tool, especially a tool made safe to the point of being unusable, is not a panacea. Yet kids with motorbikes have a lot more fatal accidents than kids with cars.
The sad truth is you need both: tools with no bugs and safe-by default, and programmers who know how to use them. I agree that if I have to choose, the safe programmer is more important... but show me a project where you can guarantee all devs will be of the "safe" kind (let alone, be that one lon
Re: (Score:2)
You are assuming Rust will give you that. It will not.
Re: (Score:2)
Go away NSA shill.
Re: (Score:2)
That argument is bogus and that has been known for a long, long time.
Re: (Score:2)
> the remaining ones will be much more obscure
That is by itself not an argument. The same obscure errors can be present in code written in another language. Rust does not seem to induce code with subtle bugs.
Re: (Score:2)
Sure. I only wanted to point out that Rust doesn't seem any worse than other languages in that particular respect.
BTW, I looked at Ruby and thought: what an awful mess. It's the kind of language that allows you to do things too cleverly. Redefining what a declaration means by overriding functions, was that really necessary?
I'm not too positive about Rust, but I admire the attempt.
Re:Have you actually tried using Rust? (Score:4, Insightful)
Indeed. I think these people are so in love with their own genius that they have overlooked that their tool is probably going to do a lot more harm than good. After several decades of research into software reliability and security it is clear that it is not a question of the tools used, although that flawed idea is strong in some academic and industrial quarters. What these people are basically saying is that if you have just the right kind of hammer, then you cannot hurt yourself with it anymore. Of course, that would be a Styrofoam hammer (or similar) that is also completely unfit for its primary purpose. The same is true for programming languages.
Re: (Score:2)
Indeed. I think these people are so in love with their own genius that they have overlooked that their tool is probably going to do a lot more harm than good. After several decades of research into software reliability and security it is clear that it is not a question of the tools used, although that flawed idea is strong in some academic and industrial quarters. What these people are basically saying is that if you have just the right kind of hammer, then you cannot hurt yourself with it anymore. Of course, that would be a Styrofoam hammer (or similar) that is also completely unfit for its primary purpose. The same is true for programming languages.
Well, having done (some very small part of) that research I think you're over egging your argument. While its true that tool users make the difference, and it's a poor carpenter etc. etc. the fact of the matter is that some tools are more likely to be used correctly in certain situations than others. If you look at the human factors work in e.g. aviation, esp. military aviation, then that becomes apparent. Much thought, research and experience goes into designing the cockpit interface for a fighter pilot, f
Re: (Score:2)
You must have some really, really inflated ego to claim "disingenuous argument" as an AC. Your posting also shows that you obviously have zero understanding of the history of computing.
Re: Have you actually tried using Rust? (Score:1)
pascal, algol and ada provided much better security properties than c. strong typing and runtime checks are badly needed, if you are concerned about cyber security.
for honest definitions of security. that is.
Re: (Score:1)
You confuse security properties of a language and security of software written it it. A typical beginners/amateur mistake. For example, pascal programs often have severe security problems because the coder needed to work around the limitations of the language and messed that up. After all, "Pascal is secure" and hence a Pascal programmer does not need to understand security. In practice, that mind-set results in utter failure. I am merely pointing out that Rust seems to be inflicted strongly by the same fau
Re: (Score:2)
Re: (Score:2)
C is not insecure. Security is not a language property. What you probably means is that it is easy for the incompetent to write insecure code in C. That is however true of any real language, including Rust. The nature of the insecurities will change, but that is it.
Re: (Score:2)
That is a pure conjecture. Changing the language does not suddenly make people that do not understand security write secure code. What is true, on the other hand, is that most CVEs could be avoided if the people that wrote software would understand security.
Re: (Score:2)
I agree on that. Rust may be a small step in the right direction, but it may also be counter-productive. Any fanatical heralding of a tool as THE silver bullet that will solve all problems is completely bogus.
I do have to say that the reaction here to criticism against Rust will make me stay away from it. And one of the things I do for a living is writing secure software.
Re: (Score:2)
Security cannot be enforced by tools. That approach has been tried time and again and has universally failed. First it was static typing, then it was garbage collection, then it was 5G languages, then it was patterns, etc. All failures. All heralded with the same bombastic claims that Rust comes with and none delivered. The only thing known to improve software security significantly is coders that do understand security.
Re: (Score:2)
Openssh. Attacked constantly, extremely secure, implemented in C. Postfix. Attacked constantly, extremely secure. Written in C. Qmail. Linux network stack and firewall code. xBSD kernels. The list goes on.
C is a good basis for secure coding, but only if you have people that know what they are doing. Incompetents will, on the other hand, still mess things up with Rust.
Re: (Score:2)
Go look for one yourself. And If you do not understand what I am talking about, you have no place in this discussion.
Re: (Score:2)
Re: (Score:2)
Seriously? Are you mentally challenged? It is dead simple: "Rust is secure" => "managers think their coders do not understand security anymore" => "vulnerabilities abound".
Re: (Score:2)
Exclamation points are used to denote macros. Why do you think println in Rust is implemented as a macro? It should be rather obvious.
Why should the coder care whether println is implemented as a macro or a procedure?
Re: (Score:1)
Re: (Score:2)
How is it you know his complaints are invalid then?
Re: (Score:1)
The Rust path library actually forces you to think about possible errors. I prefer that over libraries that simply pretend errors don't exist and end up crashing at runtime (or far worse) because of it. In this case, not all paths will have a filename and they definitely won't all be valid UTF-8 so those function calls return a Result (essentially Either for those familiar with Haskell or ML).
Cross-platform path handling is hard and most libraries simply pretend errors don't exist.
Re: (Score:2)
Re: (Score:1)
It's kind of sad how many people completely missed the joke here.
Give the ecosystem a few days to catch up (Score:5, Interesting)
Ada (Score:5, Interesting)
You'd think that Ada is already covering most if not everything what Rust is trying to cover here, especially the memory safety and concurrency aspects.
Re: (Score:1)
Well, its always good to have exploration so for me Rust is a good thing. Yea, it may not take the World by storm but may bring some new ideals to the table.
Re: (Score:2, Funny)
C++ and Ada are geezer languages for unemployable old dinosaurs. Rust is hipster hotness, bitch. You know it or you don't get paid. Ever again.
Re: Ada (Score:1)
nsa and jcs hate memory safe languages. too few exploitable bugs. c++ will enjoy a long life because of this
Re: (Score:2)
C++ and Ada are geezer languages for unemployable old dinosaurs. Rust is hipster hotness, bitch. You know it or you don't get paid. Ever again.
Are there actually Rust jobs already?
Re:Ada (Score:5, Funny)
Yes, but you'll need 5 to 10 years of Rust experience. In a lead role.
Re: (Score:2)
Simpler syntax, less code to write (less verbose)?
Re:Ada (Score:5, Insightful)
No. Ada already has a very basic syntax, which if you look at the Ada example [wikipedia.org] is so much like Rust that really I fail to see any significant difference. Ada is also completely buzz-word compliant. It has also been used to make real projects, and even has a ANSI Standard since 1983. Rust can't even guarantee a feature set, nor even a stable keyword set.
Wish them luck, but frankly it's a bit like reinventing the wheel. I guess it's what hipsters do when they skip CS 102 in order to 'find themselves' - try to 'reinvent' what they should have learned in college.
Re:Ada (Score:5, Insightful)
Complaining about other people's open source projects seems to be what Slashdot posters do in order to make themselves feel important.
Re: (Score:2)
I think the most significant difference is that Rust is much closer to a functional language than to something like C.
They just don't want to market it as a functional language because their targets are mostly C programmers, and most of those would never accept one.
Look at the main features: (almost) everything is an expression, pattern matching, type inference, actor-based concurrency, higher-order functions and closures, that's the kind of things you mostly find in functional languages.
Is Rust going to fi
Re: (Score:2)
It would be unusual if Rust was marketed as a functional language, because AFAIK no functional language exists without garbage collection today.
Re: (Score:3, Informative)
Re: (Score:2)
Sorry, there is no real relation between Adas and Rusts syntax, no idea which idiots modded you to +5.
Re: (Score:2)
Well, unicode handling is a *bit* easier in Rust. Unfortunately the general character class seems to be available only as an experimental feature, and the library B+Tree doesn't persist to a file. So it's clearly got some drawbacks. (OTOH, C++'s handling of unicode is pathetic. Vala is better, but it seems dependent on the Gnome libraries, which means it's probably untrustworthy.)
That said, handling variable length strings and heap allocation in Ada is really painful. (Yes, I know about unbounded-etc.
Re: (Score:2)
Rust offers manual memory management with automatic safety checking --- the language guarantees you don't leak memory, and you can't access an object after it's freed (assuming you don't opt into unsafe code). No other mainstream language, including Ada, offers that.
Re: (Score:1)
Your anecdote certainly doesn't point out any flaw of Ada, the whole story sounds like a management or software architecture problem.
Re: (Score:3, Funny)
What's a "compiler" ? (Score:3, Funny)
Is this Rust thing another web framework? Should I assert 5 years experience with Rust on my CV?
Re: (Score:3)
Not quite, but close enough methinks.
(Yes, I do detect the irony, but it is reality that is ironic here...)
"without garbage collection" (Score:1)
This is a good feature now? Fragmented memory is desirable?
Re:"without garbage collection" (Score:5, Interesting)
You must be a Java programmer. Garbage collection is generally a very bad idea for a systems language, because of the periodic stalls whilst it does the cleanup. Especially if it's shunting blocks around memory to defragment. It's one of the big reasons why Android underperforms iOS, why it's never been so smooth in operation. And the only thing a developer can do about it is switch to a different language or develop for a more powerful machine.
Memory fragmentation can be a problem - but the success of C and C++ in most domains over the decades has shown it's just one more aspect a programmer has to deal with, it's not a showstopper. It's fixable, on the same machine, with the same language.
Re: (Score:3)
"It's one of the big reasons why Android underperforms iOS, why it's never been so smooth in operation."
no, there is only one reason: shitty coding.
Re: (Score:2)
Re: (Score:2)
I think they will open source Swift. But I doubt it'll get much use outside of iOS and OSX programming. So many of the implementation decisions are about being compatible with Objective-C and the Apple frameworks. It *could* be used for other things, but I think the bias there will be enough to keep others away.
Re: (Score:2)
You can write good code and bad code in any mainstream (just so that exercises like brainfuck, malbolge or dis are excluded) language.
Android is just horribly written. They make monumentally bad engineering decisions. Remember one of the major flaws of os/2 4? Yeah. Same thing. Horribly designed UI? Yup. hidden meat interface, interactive elements moving around on their own, windows popping up and disappearing, no deadzone between buttons... But ok that's not coding, that's UX design.
Android is a clusterfuc
Re:"without garbage collection" (Score:5, Insightful)
Ah yes, the "systems language" debate. Oh how I love those.
Here are a few things to ponder.
The first is that your claim about Android underperforming iOS doesn't seem to have any merit. I have a Lollipop device here and it's as smooth as any iPhone I've ever used. Indeed I suspect by "smooth" you mean whether animations consistently hit 60fps and that has relatively little to do with garbage collection because most animations only last for a second or two, and you can easily delay GC until after it's finished. If you actually read about Project Butter and the work the Android team did to make things fast and smooth, it mostly involved deep changes to the graphics stack. The new GC in ART helps when doing things like scrolling down infinite lists, but otherwise, it's not a big deal. Bear in mind GC pauses on a modern Android device are in the realm of milliseconds - not fast enough to cause a frame skip unless you're really pushing up against the deadlines.
Another thing to consider is that people love to try and define "systems language" to mean whatever language they happen to prefer at the time. For instance the Linux guys have claimed for years that C++ isn't a "systems language" because you can't use it to write a kernel. However, quite a few successful kernels have done just that: for instance parts of the MacOS kernel are written in C++, the osV kernel is mostly C++ and so on. Microsoft even wrote an entire OS with kernel and everything in garbage collected C#. I've come to believe that the term "systems language" is so vague as to be useless for describing programming languages.
Final point. Rust claims to be superior for systems programming because it doesn't need a garbage collector. However, Mozilla is not in the business of writing kernels. They are in the business of writing web browsers. Web browsers absolutely can be garbage collected and due to the need to support Javascript, often are. At a time when Mozilla is dumping resources into designing an entirely new programming language and experimental layout engine that uses it (Servo), the Chrome guys are quietly getting on with migrating Blink (aka WebKit) to garbage collected C++. The project is called Oilpan, look it up. Apparently Google disagrees with Mozilla about the need for a non-GCd "systems language" for the kind of work they're doing.
Re: (Score:2)
The first is that your claim about Android underperforming iOS doesn't seem to have any merit. I have a Lollipop device here and it's as smooth as any iPhone I've ever used.
I nearly went into this with my post, but decided it was better to make a simple clear point without dealing with the obvious avenues for counter-argument in advance.
Android got smooth by throwing hardware at it. The reason for a while Androiders were bragging that their phones had more cores or higher clock speeds was that Android needed it.
Then there was the NDK, whose justification was explicitly things for which Java and Garbage Collection were unsuitable.
I don't know anyone who thinks C++ isn't a syste
Re: (Score:2)
Android got smooth by throwing hardware at it. The reason for a while Androiders were bragging that their phones had more cores or higher clock speeds was that Android needed it.
I'm sorry, but this is the same argument that people made against Java in the 90's, when Java was a few orders of magnitude slower. But as time went on, the total percentage that the computational overhead took up dropped to less than 1% because the hardware got faster. Java's success shows that developer convenience is a very powerful thing.
Re: (Score:2)
But as time went on, the total percentage that the computational overhead took up dropped to less than 1% because the hardware got faster.
Which is exactly the same thing as I said. Java's shortfalls were mitigated by hardware upgrades, not by actually fixing it. It can't be fixed. Whilst the GC stalls can be comped with for higher level software, it's a showstopper for lots of systems level programming.
Re: (Score:2)
Re: (Score:2)
No, WebKit already traces through C++ for the DOM GC. Oilpan is a project to make it use GC for *all* Blink objects including objects not exposed to the DOM at all. Read the design doc to learn more.
Re: (Score:2)
Um, I did work at Google for quite some years, and given the vast size of their C++ codebase the chances of it all being ported to Go any time this decade is zero. And for what it's worth I keep hearing from people who still work there that they're desperately trying to avoid being forced to use Go. It's hardly a slam dunk language decision.
Re: (Score:2)
The proper way to handle that is to allow garbage collection to:
1) run in a separate thread, and
2) be disabled in sections of the program where timing is critical.
If your application needs to, you can disable garbage collection right after the beginning, and never re-enable it. Then the compiler/linker can be smart enough to just remove it as unused code.
Garbage collection allows many techniques to be handled with non-deterministic freeing of memory. This can be especially important when programs are runn
Re: (Score:2)
Everyone who is responded to me has done so as if I said that Garbage Collection is always bad. Of course it's not. Languages such as Python are great places for GC, as is Javascript, and Java, when it's used at the application level.
It's just a very bad idea for systems programming.
Re: (Score:2)
But being bad for systems programming is not the same as being bad in a systems programming language. I will readily grant that there are applications in which it is desireable to avoid garbage collection. This just means that the language must be able to run well without it. And really, is easily casting integers to pointers and back important? That's the main they the language needs to avoid to make garbage collection reasonable. And switches, either program or compiler, to disable it are also fairly
no one writes large enterprise systems in Java? (Score:2)
Respectfully, you really need to research this if you believe that is the cause. Java is the enterprise systems language to beat today. And its Garbage collector does a fine job if you understand how it operates, just as with most other mature garbage collected runtimes.
Re: (Score:2)
You don't know what you are talking about. Enterprise systems are the very opposite of systems software. Systems languages are for writing kernels, drivers etc.
Re: (Score:2)
Please read up on Utility Software [wikipedia.org], which has a very sizable list of examples written in Java. Personally, we have a list of utility software on the market written in Java.
Re: (Score:2)
I don't ned to read up on what I've been working with and occasionally on for 30 years.
Utilities are part UI and part drivers for the various hardware or OD level tasks they do. The UI might be OK to be written in Java. The drivers (which are the systems software part) will rarely, if ever be Java.
Re: (Score:2)
Why not garbage collection methods in the kernel with different strategies?
Re: (Score:2)
For some applications, it does not matter much. If you need high-performance, you need to do your own memory management anyways. In the space in-between, Rust will have a problem.
Automatic Reference Counting better... (Score:2)
Re: (Score:2)
I was counting automatic reference counting as a form of garbage collection. And it does have some tradeoffs, but, IIUC, the loops of links problem is subject ot automatic handling. What you *can't* allow is casting between pointers and non-pointers. To me this seems like a minor limitation, and one that should probably be implemented anyway. (With, of course, some escape hole around the prohibition for those that really need to and really, really, know what they're doing.)
OTOH, be aware that Python use
Re: (Score:2)
With a compiled language on the LLVM (high level transportable assembly language which in turn is turned into machine code) it is not actually a thread running garbage collection in the background it is the Clang/LLVM compiler inserting "free" memory calls used as it goes out of sc
Re: (Score:2)
Your description of the particular technique used by the LLVM doesn't mean that this is the only approach. And in my opinion the garbage collector, of whatever nature, including reference counting, should run in a separate thread. Whether it's reasonable for a battery powered device I don't know. Clearly it means extra processing, but it also can mean less disk activity. I suspect that Apple has put much more thought into this than I ever would, but I also suspect that they were considering making thing
Re: (Score:2)
I would reall
Re: (Score:2)
Why do we need new langs? (Score:5, Funny)
Everything is written in JavaScript or soon will be. New language development is a waste of time that should be better spent making mobile apps for 3D printers.
Re: (Score:3)
Re: (Score:2)
Eventually the METAL Linux kernel module [destroyallsoftware.com] (C -> JS + asm.js) will boost overall processing speeds by ~4%.
I needed to call the sleep function (Score:1)
I couldn't find it in the online doc, then someone on stackoverflow informed me that "Rust Never Sleeps".
i was going to celebrate... (Score:3)
Rust looks like an exciting addition... (Score:2)
Re: (Score:2)
Did you get lost on your way to 4chan, little boy?
Pipe down, the adults are talking.
Re: (Score:1)
Despite the colourful rhetoric, the point is well taken. How many spoken languages does the average person know? Yet when it comes to programming, we are all supposed to learn a new languages every week. This is one of the rationales behind JSI, a JavaScript Interpreter (http://jsish.org). ie. when it comes to web development, you should only ever need to know two languages C and javascript.
Re: (Score:2)
Re: (Score:2)
Snobol, Rascal, Mortran, Lisp, Fortran, Cobol, ... there's lots more. Some will succeed. Some will find niche applications. Some will disappear. (But Cobol is still around...though fading.)
You're just noticing the tip of the iceberg of current languages. There are more now than ever before because communication has gotten a lot easier, and because there are more programmers. But your current favorite language will someday be forgotten.
MIX, Icon, Icebol....