Rust 1.0.0 (diskuse)

[xkucf03]

Vypadá to dobře.

BTW: Kdy se tak asi dá očekávat, že bude v distribucích jako standardní balíček a nebude se muset instalovat přes curl … | sh?

[Václav "Darm" Novák]

Tak to spíš záleží na distribuci, ne? :) Třeba Arch to má v community.

community/rust 1:1.0.0-1 [installed]

[xkucf03]

Jenže dokud je to jen v komunitních repozitářích, tak je to spíš taková hračka, nic pro produkční nasazení nebo seriózní vývoj. S takovou Javou 8 jsem taky čekal, až bude aspoň v Ubuntu – nebudu nutit uživatele, aby si do systému tahali něco, co není v oficiální distribuci – takže do té doby jsem si s 8 hrál jen u sebe a učil se ji používat.

[p4l4cl][n]

Myslim ze doslo k nepochopeni, community je v Archu povazovano za oficialni repozitar: https://wiki.archlinux.org/index.php/Official_repositories#community

[xkucf03]

Aha, tak to je dobrá zpráva. Teď ještě Debian, Ubuntu, Fedora a OpenSUSE

(a Guix a další distribuce, aby se to někoho nedotklo, že jsem ho nejmenoval)

[smazáno]

Tak muzes rust stdlib nabundlovat. Napriklad docker je ve vsech distrech, zavislosti z go ma staticky slinkovane a nikdo to neresi :)

[Dadam]

Až si toho všimne Lennart

[Bedňa]

Neviem prečo sa všetky modernejšie jazyky uchyľujú k BASIC like, ale zrejme ich k tomu niečo vedie.

[okbob]

Basic like syntax? Tak to ani náhodou - připomíná mi to něco mezi Pythonem a Cčkem.

[Bedňa]

OK, to bol len prvý examples na ktorý som klikol :)

[Hans1024]

A cim to mam sakra zkompilovat

[petr_p]

Proto to není v distribucích.

[BvJ]

Kefalín, čo je to taký data rac?

[fe]

…by mě taky zajímalo, česky to nebude, anglicky taky ne… asi nějaká programátorská svahilština LOL

[dementni.lojzik]

IMHO "data race"

[little.owl]

Me by spise zajimal cesky preklad. Tusim, ze ve skole to nazyvali "soubeh", ale to mi zni hodne divne.

[xm]

Samozřejmě, že souběh. A nezní mi na tom nic divně (byť sám používám taky anglický termín race condition, překlady odborných termínů fakt nemusím, ale zrovna v tomhle případě je použitelný).

[little.owl]

Pojmy "race condition" a "data race" nejsou to same.

[Richard]

"If you can't do it in C, it's not worth doing it."

[koudy]

Tak to určitě někdy použiju, dík :)

[little.owl]

S ohledem na soucasnou architekturu CPU asi ano ...

[chrono]

Ešte by sa hodila dokumentácia, v ktorej sa budú nachádzať len veci, ktoré sú stabilné.

[kralyk z abclinuxu]

V pátek se slavilo Škoda, že zprávička vyšla až včera... Ale nevadí.

Jedná se o systémový jazyk, jehož specialitou je konkurentní programování bez data raců.

Jde hlavně o bezpečný memory management bez GC* založený na vlastnictví, ta bezpečnost vícevláknového programování je toho důsledek.

Jinak po vydání 1.0 schytal Rust poměrně dost kritiky/skepse, zejména ze strany těch, co Rust do té doby ignorovali. V některých případech i oprávněně, například pomalá kompilace nebo nižší výkon než C (Rust je aktuálně 1-3× pomalejší, podle případu).

_{*) GC v budoucnu zřejmě přibude jako volitelná komponenta zkrze další typ pointeru.}

[Radek Miček]

GC v budoucnu zřejmě přibude jako volitelná komponenta zkrze další typ pointeru.

Jako knihovna nebo to bude plně integrováno do jazyka? Dříve to bylo součástí jazyka, ale v roce 2013 to bylo odstraněno. Smutné je, že Rust dnes nebrání memory leakům – GC by pomohl.

Škoda, že zprávička vyšla až včera

Njn, já jsem zprávičku napsal v pátek.

[kralyk z abclinuxu]

Jako knihovna nebo to bude plně integrováno do jazyka?

Pokud vim, tak zatím neexistuje konkrétní plán. Ale pochybuju, že by se vrátil ten dřívější stav.

Smutné je, že Rust dnes nebrání memory leakům – GC by pomohl.

Tím asi narážíš na ten problém s Rc/ReffCell objevený u JoinGuradu. Memory leak je nepříjemný efekt, ale problém je hlavně v tom, že se nezavolají destruktory ve správnou chvíli. S tím GC imho nepomůže - to JoinGuard API nenapíšeš pomocí GC. Viděl jsem nějakej návrh, kde to bylo vyřešeno pomocí lambdy, ale v stdlib je pořád to starý API s varováním.

Njn, já jsem zprávičku napsal v pátek.

Jj, koukal jsem, že je ve frontě. Asi neměl čas ten, kdo to schvaluje...

[Radek Miček]

Tím asi narážíš na ten problém s Rc/ReffCell objevený u JoinGuradu.

Mám na mysli kód, který vytvoří referenční cyklus, s tím GC pomůže. Například:

use std::cell::RefCell;
use std::rc::Rc;

struct Pokus {
    jiny: RefCell<Option<Rc<Pokus>>>,
}

impl Drop for Pokus {
    fn drop(&mut self) {
        println!("Zaviram");
    }
}

fn main() {
    let p: Rc<Pokus> = Rc::new(Pokus { jiny: RefCell::new(None) });
    let mut jiny = p.jiny.borrow_mut();
    *jiny = Some(p.clone());
}

[kralyk z abclinuxu]

Mám na mysli kód, který vytvoří referenční cyklus, s tím GC pomůže.

Někdy ano, někdy ne, to záleží na tom, jaký prostředky spravuješ tím objektem / jaký máš požadavky na destruktor. S GC typicky nevíš, kdy se uvolní jaký objekt a v jakém pořadí, což nemusí být přijatelné.

Pokud bys v tom příkladě spravoval Pokus garbage collectorem, nevíš, kdy se zavolá ten println!(). Bude v té době ještě vůbec možné zapisovat na výstup?

[ava]

GC by nemělo sloužit ke správě resourců. I v jazycích s GC se dá snadno implementovat RAII, pokud mají lambdy (pokud mozno uzivatelsky privetive), pseudokod (nedokonaly, ale princip je snad jasny...

func withOpenFileDo[T](filename: String, action: File -> T): T {
  val file = fopen(filename)
  try {
     action(file)
  } finally {
     close(file)
  }
}

val contentsOfFile = withOpenFileDo("foo.txt", file -> file.readAll)

RAII je tedy poměrně slabý koncept, který se dá triviálně nahradit funkcemi. GC je podstatně silnější koncept, který není možno RAII plně nahradit.

[kralyk z abclinuxu]

GC by nemělo sloužit ke správě resourců.

Souhlas. Pointu zbytku příspěvku nechápu se přiznám Mluvíš o "nahrazení RAII funkcemi" jako by RAII byl nějaký konkrétní kus SW nebo konkrétní konstrukt v jazyce, což není... V tom příkladu vidím hlavně try+finally jako cestu jak realizovat RAII, což určitě jde, ale nemá to úplně tu pohodlnost a flexibilitu jako v jazycích se scope/lifetime-based RAII...

[kozzi]

Tak prvne nemam rad vyjimky :D a za druhe co kdyz fopen vyhodi vyjimku. Podle me idealne to resi jazyk D.

auto withOpenFileDo(alias action)(strinf filename)
{
    auto file = File(filename);
    scope(exit) file.close();
    // tady si delej co chces
    return action(file);
}
...

[pavlix]

Tady jsem se trochu nechal zhýčkat Pythonem (hlavně jazykem, knihovnou už ne tak úplně). Snad jediné, co mě na tom trochu mrzí je, že člověk musí ten stream nějak pojmenovat, ale já jsem si zvykl právě na název stream, případně istream nebo ostream, takže už mi to ani nepřijde.

with open(filename) as stream:
    do_something_with_stream(stream)

with open(filename) as stream:
    for line in stream:
        do_something_with_line(line)

[kozzi]

Opet vede D. :D.

File(filename).doSomethingWithLine();
File(filename).byLine.doSomethingWithLine();

[xkucf03]

Co třeba tohle?

Files.lines(Paths.get("/etc/passwd"))
	.filter(s -> s.endsWith("/bin/bash"))
	.map(s -> s.split(":", 2)[0])
	.forEach(System.out::println);

(Java)

[pavlix]

Python bohužel nemá implicitní RAII, jen explicitní pomocí with, zbytek si myslím, že je v něm elegantnější než v javě.

[kralyk z abclinuxu]

V tom, co napsal Franta, taky žádný RAII nevidim...

[pavlix]

Pravda, ono to dost korektně nenahrazuje ten pythoní kód.

[xkucf03]

Alternativou k RAII v Javě je try-with-resources:

try (Stream<String> řádky = Files.lines(Paths.get("/etc/passwd"))) {
	řádky
		.filter(s -> s.endsWith("/bin/bash"))
		.map(s -> s.split(":", 2)[0])
		.map(Java8::throwsException) // nějaká metoda, která vyhodí výjimku
		.onClose(() -> {
			// můžeme si přidat vlastní kód, který se provede při zavírání zdroje
			// (vedle standardního zavření souboru v tomto případě)
			System.out.println("onClose...");
		})
		.forEach(System.out::println);
}
// nakonec se automaticky zavře soubor /etc/passwd

[pavlix]

Krása.

[xkucf03]

Tak schválně napiš kód se stejným výstupem třeba v tom Pythonu.

[kralyk z abclinuxu]

Technická: zavolá se skutečně .onClose() v kódu výše než bude vyhozena výjimka? (V Rustu by to tak bylo (resp. tam by se místo vyjímky zpanikařilo), ale jak fungujou ty iterace u Javy, nevim...).

Jinak pokud vim, tak standardní knihovny C++ a Rust ekvivalent .onClose() nemají, nicméně bylo by triviální tu metodu dodělat nebo udělat totéž jinak, tohle už není až tak o fíčurách jazyka...

[xkucf03]

Když ta Java8::throwsException¹ vyhodí výjimku, tak se zavolá jednak standardní close() toho proudu (v tomto případě to zavře soubor) a jednak tebou definovaná onClose funkce. Výjimka (a na ni navázané případné potlačené výjimky) se pak vyhodí výš, protože tam nemáš blok catch.

_{[1] to je moje statická metoda v mojí třídě Java8, nic ze standardní knihovny… asi jsem to měl radši pojmenovat česky, aby to bylo vidět na první pohled}

[kralyk z abclinuxu]

Když ta Java8::throwsException¹ vyhodí výjimku, tak se zavolá jednak standardní close() toho proudu (v tomto případě to zavře soubor) a jednak tebou definovaná onClose funkce.

To by znamenalo, že to Stream API je podobně lazy jako iterátory v Rustu a vyhodnocuje až když se v tom řetězci filtrů objeví nějaký `consumer`. Pokud to tak není, tzn. pokud se map() et al. vyhodnocují hned, pak bude ta výjimka vyhozena ještě před zavoláním .onClose(), tudíž tan onClose() lambda by se nezavolala.

[xkucf03]

Představ si to prostě jako anonymní vnitřní třídy (jen zapsané jinou syntaxí). Mají prázdný konstruktor a při vytváření jejich instancí nemůže dojít k chybě. Máš tedy vytvořené instance těch filtrů, mapovačů i onClose operace. A až potom se to celé uvede do pohybu, proud se začne postupně zpracovávat a až tady se může případně objevit nějaká výjimka.

[kralyk z abclinuxu]

Teď koukám do dokumentace, že ty Streamy jsou lazy, takže ok...

[xkucf03]

BTW: tohle je právě princip proudů, že je zpracováváš proudově – průběžně – a ne jako kolekce/pole, které bys celé prošel v jednom cyklu (třeba mapování) a až pak jako celek předal do dalšího cyklu (třeba filtrování) a nakonec jako celek předal všechny prvky do cyklu, ve kterém se zpracuje výstup.

[kralyk z abclinuxu]

V Rustu se ten rozdíl do značné míry stírá, protože for cykly pracují výlučně s iterátory. V které fázi přestaneš iterátor filtrovat a pošleš ho do cyklu (nebo ne), je jen na tobě. Imho všechny příklady doposud v diskusi se dají triviálně přepsat jako jeden cyklus.

Např. v Rustu:

for line in BufReader::new(File::open("/etc/passwd").unwrap()).lines()
{
	let str = line.as_ref().unwrap();
	if str.ends_with("/bin/bash") { println!("{}", str.split(':').next().unwrap()); }
}

Sans error-handling, který by se v praxi doplnil, čímž by kód vzrostl, ale byl by korektnější.

[kozzi]

JJ v D je to az na drobne syntax rozdily uplne stejne:

File("/etc/passwd").byLine
    .filter!((s)=> s.endsWith("/bin/bash"))
    .map!((s)=>s.splitter(":").front)
    .each!writeln;

[kozzi]

A samozrejme je to rychlejsi jak Java :) asi 1.7x

[kralyk z abclinuxu]

Počítám, že v C++ by to mohlo vypadat dost stejně... Celkově mi D přijde dost jako syntactic sugar pro C++ , vyjma GC teda...

[kozzi]

Tak to by se dalo rict potom i o Jave :D.

Btw, jak se neco podobneho napise v rust. Ja se o to pokusil bohuzel jsme nenasel ani zpusob (funkcni) jak precist soubor radek po radku natozpak neco slozitejsiho.

[kralyk z abclinuxu]

Tak to by se dalo rict potom i o Jave :D

Java má svoje VM.

Btw, jak se neco podobneho napise v rust.

use std::fs::File;
use std::io::{BufReader, BufRead};

fn main()
{
	BufReader::new(File::open("/etc/passwd").unwrap()).lines()
	.filter(|l| l.as_ref().unwrap().ends_with("/bin/bash"))
	.map(|l| println!("{}", l.as_ref().unwrap().split(':').next().unwrap()))
	.last();
}

Rust nemá exceptions, proto tam jsou všade ty unwraps.

[kralyk z abclinuxu]

Jinak ale zrovna v tomhle případě mi ten funkcionální styl nepřijde moc výhra ani v jednom z výše zmíněných jazyků, použil bych prostě for cyklus přes iterátor (jde to i v Javě, ne?).

[kozzi]

Tak v D to jde, ale nevim co bych tim ziskal, me to takto prijde mnohem vic fajn a efektivni

[kralyk z abclinuxu]

Napiš verzi s for cyklem v D, vsadim se, že bude čitelnější...

[kozzi]

Tak to je asi o zvyku, ja drive taky moc tento zapis nemusel, ale nakonec mi prijde prehlednejsi.

[wamba]

varianta v Perlu 6 funkcionální

open( '/etc/passwd' ).lines
==> map {   ( < user shell > Z=> .split(':').[0,*-1]  ).hash.item  }\
==> grep *.< shell > eq '/bin/bash'
==> map *.< user >.say
;

a s for cyklem

for open( '/etc/passwd' ).lines -> $passwd_line {
    my ( $user, $shell ) = ( split ':', $passwd_line )[ 0, *-1 ];
    if $shell eq '/bin/bash' {
        say $user
    }
};

tak si vyber :)

[xkucf03]

Tak to jde snad všude, ne?

Klasicky bys to zapsal třeba takhle:

try (Scanner sc = new Scanner(new File("/etc/passwd"))) {
    while (sc.hasNextLine()) {
        String řádka = sc.nextLine();
        if (řádka.endsWith(":/bin/bash")) {
            System.out.println("Scanner: " + řádka.split(":", 2)[0]);
        }
    }
}

Není to moc velký rozdíl, pokud se ty funkce píší přímo do kódu v místě, kde se používají. Ale výhodu vidím v tom, že tu funkci můžeš předat zvenku jako parametr dané metody. Případně v tom, že ty proudy se dají zpracovávat paralelně.

[kralyk z abclinuxu]

Proč ne for-each?

Není to moc velký rozdíl, pokud se ty funkce píší přímo do kódu v místě, kde se používají. Ale výhodu vidím v tom, že tu funkci můžeš předat zvenku jako parametr dané metody.

To můžeš s for cyklem taky.

[xkucf03]

For each může být taky, potřebuješ něco, co implementuje rozhraní Iterable. Případně jakoukoli kolekci nebo pole, ale pak by se to nezpracovávalo proudově.

[kozzi]

Diky ja se o to snazil sam ale nejak jsem se ztratil v tech unwrapech a nevedel jsem kde mam pouzit spravne to as_ref :).

[kralyk z abclinuxu]

Jj, s borrow-checkerem se člověk docela pere v Rustu. Taky s tím mám problémy. Ten týpek si tam řádky nejdřív unwrapnul, což mně taky napadlo, to je asi lepší. Další možnost je použít funkci filter_map(), která jak filtruje, tak mapuje.

[pavlix]

To nevypadá moc reálně.

[kozzi]

proc ne?

[pavlix]

Protože do_something_*() je obecná operace, takže ten model je popsaný zcela chybně, ale výše pod ukázkou Javy už je to napraveno, takže není, co řešit.

[kozzi]

jo jenze to prave v D lze udelat (UFCS), to ze je do_something obecna operace nicemu nevadi

[pavlix]

Takže tečková notace není volání metody?

[kozzi]

Ano i ne :). Zjednodusene plati toto. Pokud pouziji teckovou notaci tak se podivam zda dany clen ci metoda existuje na danem objektu. Pokud ano tak ji zavolam. Pokud neexistuje tak se podivam po volne funkci se stejnym nazvem jako ta volana metoda a pokud existuje a jeji prvni parametr je typu meho objektu tak zkusim zavolat ji.

[kozzi]

link na lepsi popis

[pavlix]

A jak je to řešeno v ABI?

[kralyk z abclinuxu]

Počítám, že v ABI se to vůbec řešit nemusí, to zřejmě řeší kompilátor...

[Jardík]

Kozzi, experte na D. Potřebuji v D pořešit jednu věc. Spustím vlákno, kterému přiřadím nějaký objekt, v mém případě smyčku událostí. Ta používá nativní zdroje (eventfd, epoll, ...) ke své funkčnosti. No a tato smyčka událostí má referenci na vlákno a vlákno má (v thread-local) referenci na smyčku událostí. Smyčka událostí má referenci i v jiných vláknech, co ji používají a posílají tak vláknu různé věci, přidávají deskriptory k monitorování, atp. A co potřebuju ... potřebuju, aby se mi nativní prostředky ze smyčky uvolnily (řekněme potřebuju zavolat EventLoop.shutdown()), když někdo udělá Thread.join() na to vlákno, ale né dříve.

[kozzi]

Prvni rada nez se zamyslim je pouzivej uz hotove veci, ktere jsou bud uz ve phobos a nebo pouzij libasync z code.dlang.org. Jinak uplme presne nechapu co potrebujes, ale podle me si nemusis drzet referenci na jednotliva vlakna, ale pouzivej modul std.concurrency na posilani si zprav pomoci Tid.

[Jardík]

Tak jsem zkouknul libasync, a moc použitelný pro můj účel se nezdá. A taky obsahuje spoustu race-conditions. Příklad

import core.atomic;
shared static ushort i;
string* failer = null;

		
m_instanceId = i; // race-condition mezi tímto
static if (!EPOLL) g_threadId = new size_t(cast(size_t)m_instanceId);

core.atomic.atomicOp!"+="(i, cast(ushort) 1); // a tímto
m_evLoop = evl;

Pak tvrdí, že je to nothrow. Ale není. V případě debug buildů asserty hází výjimky. V dalších částech, aby byl nothrow, tak výjimky chytá (a né jen Exception, ale Throwable, což by neměl) a ve spoustě případech ji prostě ignoruje a nijak nehlásí chybu. V dalších místech, když dojde k NEFATÁLNÍ runtime chybě, tak prostě hodí assert. (jinak já asserty v D nemám vůbec rád, chcípne jen aktuální vlákno, kdy by bylo lepší nechat chcípnout celý program, protože assert = fatální programátorova chyba, nikoliv ošetřitelná runtime chyba.

Potřebuju nějak pořešit svůj Poller pro můj EventLoop, ten epoll, to je hrozný. Přese nebudu volat epoll_wait() na vyzvedávání po jednom eventu, abych předcházel race-condition mezi add a del. Koukni na to. Není to hotový, takže je tam spousta věcí, co by šla lépe

module jardik.eventloop.poller;

private import jardik.util.abortif;


private import core.stdc.errno;
private import core.thread;
private import std.exception : ErrnoException;

version(linux) {
	version = POLLER_USE_EPOLL;
	//version = POLLER_USE_POLL;
}
else {
	version = POLLER_USE_POLL;
}

version(POLLER_USE_EPOLL)
{
	private import core.sys.linux.epoll;

	// FIXME: this needs fixing up, its haz race condition
	//        when you remove fd, which hasn't been dispatched yet
	//        and then add it again, it will be dispatched with old
	//        ready events ... even worse is that the fd can be totaly
	//        different file
	public final class Poller
	{
		public alias Callback = void delegate(int fd, uint events);

		public enum : uint {
			POLLIN  = .EPOLLIN,
			POLLOUT = .EPOLLOUT,
			POLLPRI = .EPOLLPRI,
			POLLERR = .EPOLLERR,
			POLLHUP = .EPOLLHUP,
		}

		epoll_event[] events_;
		// FIXME: indexed by file descriptor value, find better way
		Callback[] callbacks_; 
		int fd_;
		uint currentEvent_;
		uint numFDs_;

		public this()
		{
			currentEvent_ = uint.max;
			fd_ = epoll_create1(EPOLL_CLOEXEC);
			if (fd_ == -1) {
				throw new ErrnoException("Poller: epoll_create1() failed");
			}
			//events_ = new epoll_event[16];
			events_ = new epoll_event[1]; // FIXME: make bigger after race condition fixed
			callbacks_ = new Callback[16];
		}

		void poll(int timeoutMillis)
		{
			version(assert) {
				abortIf(fd_ == -1, "Poller: close() already called");
				abortIf(timeoutMillis < 0, "negative timeout");
			}

			// we ensure that events_.length won't go above int.max
			int ret = epoll_wait(fd_, events_.ptr, cast(int)events_.length, timeoutMillis);
			
			if (ret < 0) {
				int errnoSave = errno;
				if (errnoSave != EINTR)
					throw new ErrnoException("Poller: poll() failed");
			}
			else if (ret != 0) {
				currentEvent_ = ret - 1;
			}
		}

		public bool dispatch()
		{
			version (assert) {
				abortIf(fd_ == -1, "Poller: close() already called");
			}

			bool dispatchedSome = false;
			
			// NOTE: current_fd_ can change durring event dispatch in case of recursion
			for (uint currentEvent = currentEvent_; currentEvent != uint.max; currentEvent = currentEvent_)
			{
				const epoll_event ev = events_[currentEvent];
				currentEvent_ = currentEvent - 1; // underflows on 0 to uint.max, which is desired
				
				// dispatch
				Callback cb = callbacks_[ev.data.fd];
				if (cb !is null) {
					dispatchedSome = true;
					cb(ev.data.fd, ev.events);
				}
			}
			return dispatchedSome;
		}

		public void add(int fd, uint events, Callback cb)
		{
			version(assert) {
				abortIf(fd_ == -1, "Poller: close() already called");
				abortIf(cb is null, "Callback is null");
			}

			prepareAdd(fd);

			int ret, errnoSave;
			epoll_event ev;

			ev.events = events;
			ev.data.fd = fd;

			// Add the descriptor
			for (;;)
			{
				ret = epoll_ctl(fd_, EPOLL_CTL_ADD, fd, &ev);
				if (ret == 0) break;
				errnoSave = errno;
				if (errnoSave != EINTR) {
					throw new ErrnoException("Poller: epoll_ctl(EPOLL_CTL_ADD) failed");
				}
			}
			// Store callback
			callbacks_[fd] = cb;
			// Add to count
			++numFDs_;
		}
		
		public void remove(int fd)
		{
			version(assert) {
				abortIf(fd_ == -1, "Poller: close() already called");
				abortIf(fd < 0, "Invalid file descriptor");
				abortIf(callbacks_.length <= cast(uint)fd, "Descriptor not found");
			}

			int ret, errnoSave;

			for (;;)
			{
				ret = epoll_ctl(fd_, EPOLL_CTL_DEL, fd, null);
				if (ret == 0) break;
				errnoSave = errno;
				if (errnoSave != EINTR)
				{
					// Don't treat ENOENT as error iff the descriptor
					// was "autoremoved" from epoll (happens on its last close())
					if (errnoSave == ENOENT && callbacks_[fd] !is null)
						break;
					throw new ErrnoException("Poller: epoll_ctl(EPOLL_CTL_DEL) failed");
				}
			}
			callbacks_[fd] = null;
			--numFDs_;
		}

		private void prepareAdd(int fd)
		{
			version(assert) {
				abortIf(fd < 0, "Invalid file descriptor");
			}

			// Grow callback array if needed
			size_t cblen = callbacks_.length;
			if (cblen <= cast(uint)fd) {
				// this doesn't run often so lets keep it simple
				do {
					cblen *= 2;
				} while (cblen <= cast(uint)fd);
				
				// maximum value of valid file descriptor is int.max
				// so we never need to alocate more than (int.max + 1) elements
				if (cblen > cast(uint)int.max + 1)
					cblen = cast(uint)int.max + 1;
				callbacks_.length = cblen;
			}
		}
		
		public @property uint numFDs() const
		{
			return numFDs_;
		}
		
		public @property bool dispatchIsPending() const
		{
			return currentEvent_ != uint.max;
		}

		public void close()
		{
			// close epoll descriptor
			import core.sys.posix.unistd : system_close = close;
			int ret;
			do {
				ret = system_close(fd_);
			} while (ret == -1 && errno == EINTR);

			// set to invalid state
			fd_ = -1;
			events_ = null;
			callbacks_ = null;
			numFDs_ = 0;
			currentEvent_ = uint.max;
		}
	}

} // version(POLLER_USE_EPOLL)

version(POLLER_USE_POLL) {

	private import core.sys.posix.poll;


	public class Poller
	{
		public alias Callback = void delegate(int fd, uint events);
		
		public enum : uint {
			POLLIN  = .POLLIN,
			POLLOUT = .POLLOUT,
			POLLPRI = .POLLPRI,
			POLLERR = .POLLERR,
			POLLHUP = .POLLHUP,
		}

		pollfd[] fds_;
		Callback[] callbacks_;
		uint numFDs_;
		uint currentFD_;

		public this()
		{
			currentFD_ = uint.max;
		}

		void poll(int timeoutMillis)
		{
			version(assert) {
				abortIf(timeoutMillis < 0, "negative timeout");
			}

			uint numFDs = numFDs_;
			int ret;

			if (numFDs == 0) {
				// nothing to poll, just sleep
				Thread.sleep(dur!"msecs"(timeoutMillis));
				ret = 0;
			}
			else {
				ret = core.sys.posix.poll.poll(fds_.ptr, numFDs, timeoutMillis);
			}

			if (ret < 0) {
				int errnoSave = errno;
				if (errnoSave != EINTR)
					throw new ErrnoException("Poller: poll() failed");
			}
			else if (ret != 0) {
				currentFD_ = numFDs_-1;
			}
		}

		public bool dispatch()
		{
			bool dispatchedSome = false;

			// NOTE: current_fd_ can change durring event dispatch
			for (uint currentFD = currentFD_; currentFD != uint.max; currentFD = currentFD_)
			{
				const pollfd pfd = fds_[currentFD];
				fds_[currentFD].revents = 0;
				currentFD_ = currentFD - 1; // underflows on 0 to uint.max, which is desired

				// dispatch
				if (pfd.revents != 0) {
					Callback cb = callbacks_[currentFD];
					dispatchedSome = true;
					cb(pfd.fd, pfd.revents);
				}
			}
			return dispatchedSome;
		}

		public void add(int fd, uint events, Callback cb)
		{
			version(assert) {
				abortIf(cb is null, "Callback is null");
				abortIf(fd < 0, "Invalid file descriptor");
			}

			pollfd pfd = {fd, cast(short)events, 0};
			uint numFDs = numFDs_;
			prepareAdd();
			fds_[numFDs] = pfd;
			callbacks_[numFDs] = cb;
			numFDs_ = numFDs+1;
		}

		// fuck yeah, cool O(N) search!!
		public void remove(int fd)
		{
			uint fdIndex = findFD(fd);
			version(assert) {
				abortIf(fdIndex == uint.max, "file descriptor not found");
			}

			uint lastIndex = numFDs_-1;
			uint currentIndex = currentFD_;

			if (currentIndex <= lastIndex && fdIndex <= currentIndex)
			{
				fds_[fdIndex] = fds_[currentIndex];
				callbacks_[fdIndex] = callbacks_[currentIndex];
				fdIndex = currentIndex;
				currentFD_ = currentIndex-1;
			}

			fds_[fdIndex] = fds_[lastIndex];
			callbacks_[fdIndex] = callbacks_[lastIndex];
			fds_[lastIndex] = pollfd.init;
			callbacks_[lastIndex] = Callback.init;
			--numFDs_;
		}

		public @property uint numFDs() const
		{
			return numFDs_;
		}

		public @property bool dispatchIsPending() const
		{
			return currentFD_ != uint.max;
		}

		public void close()
		{
			fds_ = null;
			callbacks_ = null;
			currentFD_ = uint.max;
			numFDs_ = 0;
		}

		private uint findFD(int fd) @trusted
		{
			version(assert) {
				abortIf(fd < 0, "Invalid file descriptor");
			}

			uint numFDs = numFDs_;
			pollfd* pfds = fds_.ptr;

			for (uint i = 0; i < numFDs; ++i)
			{
				if (pfds[i].fd == fd)
					return i;
			}
			return uint.max;
		}

		private void prepareAdd()
		{
			size_t capacity = callbacks_.length;

			if (numFDs_ == capacity) {
				version(assert) {
					abortIf(capacity == cast(uint)int.max + 1,
						"The fuck ... where did you get so many descriptors??!");
				}

				if (capacity == 0)
					capacity = 4;
				else
					capacity *= 2;

				// can't have more than int.max+1 descriptors
				if (capacity > cast(uint)int.max + 1)
					capacity = cast(uint)int.max + 1;

				fds_.length = capacity;
				callbacks_.length = capacity;
			}
		}
	}

}

[little.owl]

Po letech jsem dosel k zaveru, ze hrat si s D je ztrata casu, z toho jazyka nic nebude.

[pavlix]

Pro Jardíka tedy ideální jazyk.

[Jardík]

Však já si jen tak blbnu a stejně ze mě nic pořádnýho nevypadne. V podstatě mám napsáno to samé v C++, D a v C a pořád přemýšlím, v čem pokračovat. V C mě štve absence výjimek (nutnost kontrolovat návratové chybové hodnoty) a absence šablon a přetížených fcí. Někdy se to hodí. rust ... když na mě vyplivne půl megovou binárku pro hello world, se mi taky nezdá.

[Jardík]

Jinak v D jsem objevil Fiber a dá se s tím zajímavě docílit "async" funkcí. Kdy do svýho EventLoopu kydnu fd na monitorování s callbackem na zavolání fiberu a fiber chcípnu. Když je fd ready, pokračuju. Jinak na D je hrozná hlavně standardní knihovna, přeplácaná. Šablony někdy vypadají strašidelně. A příliš klíčových slov pro fce. Třeba vidím funkci ozdobenou nothrow @trusted @safe pure override inout a chce se mi zvracet. A pak stejně zjistíte, že fce nothrow není, protože je tam assert().

[kozzi]

tak to nothrow rika ze funkce nevyhazuje zadnou vyjimku tridy Exception (pripadne od ni odvozenou). Coz ale pro assert neplati, ten vyhazuje objekt typu AssertError a ten je odvozen od objektu object.Error a ten zase od object.Throwable. Takze je to v poradku.

[kozzi]

jinak ano je skoda ze to nepojmenovali spis noexception, to nothrow je dost zavadejici

[little.owl]

Jinak na D je hrozná hlavně standardní knihovna,

Celkove implementace. Prosel jsem od 2003 pres D1 na D2, prezil kockoviny se standardni knihovnou a zabugovane kompilatory, a stale to neni moc pouzitelne. Co realne sleduji tvurci jazyka D uz netusim, protoze to vypada jak pejsek a kocicka v kuchyni v kombinaci s Patem a Matem.

[kozzi]

Tak popravde pouzitelne uz te dnes je, ja osobne uz nenarazim na moc problemu. Spis by to ale chtelo vidat nejakou stabilni verzi. A idealne standardni knuhovnu psat tak aby byla stale kompatibilni stou stabilni verzi kompilatoru. Me dokaze obcas fakt vytocit kdy clovek hleda napriklad regresi a neni schopen bisectem ji najit, protoze druntime i phobos jsou tak provazany s kompilatorem ze napriklad jen par komitu novejsi verze phobos uz nejde skompilovat a opacne.

[little.owl]

V C mě štve absence výjimek

To se da castecne osklive resit pomoci setjmp() a longjmp().

nutnost kontrolovat návratové chybové hodnoty

Pokud se vyjimky pouzivaji pro fatalni selhani a ne pro control flow, jste v podobne situaci i s nimi.

půl megovou binárku pro hello world, se mi taky nezdá

Well, soucasna implementace je ma poned rough edges.

[kralyk z abclinuxu]

Dřív jsem výjimkám fandil, teď jsem toho názoru, že s různými způsoby error handlingu si člověk pouze volí různé problémy.

[kozzi]

JJ presne, ja osobne vyjimky moc nemusim. Driv jsem je mel rad a videl jsem na nich jen to dobre. Dnes uz jsem zkusenejsi a vidim i ty problemy.

[Jardík]

Já to mám naopak. Dřív jsem je nemohl vidět, protože způsobovali problémy mému hnusně napsaném exception-unsafe kódu. Dneska zkušenější to už není problém a prostě píšu a a výjimky se starám, jen kde jsou nezbytně potřeba, zbytek funguje sám a výjimku si chytnu, kde chci. A když nechci, protože je to fatální, tak jí nechám, ať mi chcípne program. Kontrola návratových hodnot přidává spoustu manuálního psaní navíc a neustálé větvení na podmínkách taky není zadarmo. A nějaký "hint" kompilátoru, jakou větev optimalizovat, není standardizován. Výjimky dneska skoro nic nestojí, pokud nenastane. Možná trošku nabobtná binárka pro stack-unwind, ale mně to za to stojí. Navíc v C++ může hodit výjimku skoro všechno a nepřizpůsobit se tomu a myslet si "já výjimky nepoužívám, tak nemusím psát exception-safe" (ala Qt) je pitomina.

[kozzi]

Tak me na vyjimkach vadi zejmena to ze se pak spatne propojuji s jinymi jazyky. Jako ve sve aplikaci je klidne pouzivam. Ale u knihovny to je obcas za trest. Clovek kdyz pak dela treba binding pro jiny jazyk, tak ma docela problem.

[Jardík]

Binding je jednoduchý, prostě urobíš wrapper s extern "C" a vněm try-catch a vrátíš chybový kód. V C++ ti může hodit i new operátor (nepoužiješ-li nothrow verzu, což někdy je mimo tvou kontrolu), takže bys to stejně musel urobit.

[Jardík]

Já používám výjimky pouze pro nefatální selhání. Pro fatální programátorovo selhání při předávání parametrů použiju assert. Všechno ostatní je nefatální, dokud uživatel programu či knihovny neurčí jinak. Např. knihovna nabízející mi (např.) vytvoření vlákna mi nemá co shazovat program, když se to nepovede. Má vyhodit výjimku a nechat na mně, jestli je pro mě vlákno tak důležité, nebo se obejdu i bez něho.

Pokud mám 20 úrovní vnořenej kód a někde mi to kyksne na chybě čtení souboru (tj. nefatální chyba, kterou je potřeba sdělit uživateli aplikace), tak prostě ji chytím v úrovni 1 a úrovně 2-20 se o to vůbec nemusí zajímat/starat (případný úklid zajistí destruktory). Kdežto v C musím v každé úrovni kontrolovat návratové kódy. Vracet je výš a výš ... a setjmp() mi úklid nezajistí.

[kralyk z abclinuxu]

Takhle hezky to funguje jen někdy.

Chyby jsou často lokální, týkají se implementačních detailů. Jakmile máš nějakej kód složenej třeba z monha menších částí a/nebo více vrstev, tak ti pak nahoru probublavá bambilion různých výjimek týkajicích se detailů, který tě na vyšší vrstvě vůbec nezajímaj (V Java SW se s tímhle setkávám furt). Případně můžeš kód prošpikovat try bloky a řešit detailní výjimky dole a nahoru rethrowovat nějaký obecný výjimky nebo něco takovýho, jenže tím se ta pointa výjimek tak trochu vytrácí.

Další věc je, že výjimky zesložiťují API - je to položka navíc, kterou je potřeba řešit.

V Rustu je docela hekzý to řešení chyb pomocí návratových enumů (jako Option, Result, apod.), kde ti z funkce buď vyleze výsledek, který jsi chtěl, nebo None / chybový kód / popis chyby / whatever. Scope-base úklid je zachován. Ale zas to má nevýhodu ve vyšší výřečnosti kódu.

[----]

sorry, ale pokud tvůj kód vyhazuje error přes 20 úrovní volání, tak je to docela prasárna.

[pavlix]

Čistě teoreticky se tak dají ošetřovat stavy, které jsou fatální třeba pro obsluhu klienta, ale nejsou fatální pro celý server. Pak se nejedná o prasárny, ale o zcela běžné chyby srovnatelné s tím, když ti sletí proces obsluhující klienta u forkujícího serveru.

[Jardík]

No jó no, já miluju moje kódy

void callMe1() { callMe2(); }
void callMe2() { callMe3(); }
void callMe3() { callMe4(); }
void callMe4() { callMe5(); }
void callMe5() { callMe6(); }
void callMe6() { callMe7(); }
void callMe7() { callMe8(); }
void callMe8() { callMe9(); }
void callMe9() { callMe10(); }
void callMe10() { callMe11(); }
void callMe11() { callMe12(); }
void callMe12() { callMe13(); }
void callMe13() { callMe14(); }
void callMe14() { callMe15(); }
void callMe15() { callMe16(); }
void callMe16() { callMe17(); }
void callMe17() { callMe18(); }
void callMe18() { callMe19(); }
void callMe19() { callMe20(); }
void callMe20() { throw "Jardík rulez!"; }

[deda.jabko]

nebo java...

[xkucf03]

Java je hodně otevřená a ty ty vrstvy jsou vidět. Zvlášť když použiješ nějaký framework nebo knihovnu, tak jich pár bude. Není na tom nic špatného. Jenže když někdo píše v jazyce, kde je ten výkonný kód skrytý v nějakém modulu napsaném třeba v C/C++, tak ho to může zaskočit, protože on obvykle vidí třeba jen dvě tři vrstvy volání svého jednoduchého programu, ale nevidí tu složitost pod tím.

[xkucf03]

Pokud nechceš tupě kopírovat kód nebo psát duplicitní, tak je celkem normální, že máš hodně menších metod/funkcí a ty se navzájem provolávají. Na vyšší čísla se dostaneš celkem snadno a nevidím v tom problém.

[little.owl]

S GC typicky nevíš, kdy se uvolní jaký objekt a v jakém pořadí, což nemusí být přijatelné.

Pak je na programatorovi to oserit, necpat klicove veci do destructoru a GC nechat jen dealokaci pameti.

Scope based memory management je fajn, ale pro systemovy jazyk mi tam chybi [nebezpecna] low-level flexibilita nabizena C/C++.

[kralyk z abclinuxu]

pro systemovy jazyk mi tam chybi [nebezpecna] low-level flexibilita nabizena C/C++.

Chybí? Viz.

[little.owl]

Ano. unsafe {} znam, ale to neni reseni. Chybi mi tam treba veci jako custom allocatory, u systemoveho programovani nemusite mit k dispozici globalni heap, nebo jich mate nekolik a pak potrebuji mit kontrolu, kde se to explicitne alokojuje, uz jen treba kvuli latencim a fragmentaci.

Rust to bude mit tezke. C++ se rychle vyviji, a je/bude v nem mozne psat bezpecnejsi kod, pak tu mame treba Go a pro High Integrity Software je tu standardizovana Ada2012, ktera resi plno problemu Ada83.

[kralyk z abclinuxu]

Jj, custom alokátory jsou problém. Četl jsem nějakou práci (tušim něčí diplomka), kde ten člověk implementoval minimalistický unix kernel v Rustu. Celkově Rust chválil, ale absenci custom alokátorů zmínil jako problém.

Nicméně autoři o tomhle vědí a Allocator API je jedna z top priorit po 1.0, v plánu je přidat to co nejdříve.

Rust to bude mit tezke.

Souhlasim, mam trochu obavu, aby to nebylo další D. Nicméně D imho trpí od začátku tím, že se snaží mít strašně moc featur a ve velké šíři. Přijde mi to na zvládnutí náročnější než C++ a to už je co říct. Naprosti tomu Go má přesně opačný problém, poskytuje featur naprosté minimum; např. absence generik by mi asi vadila. Imho Go zachraňuje vliv Googlu.

[kozzi]

Tak rekl bych ze D nema zas tolik featur, teda minimalne mi prijde lehci na nauceni nez C++, nehlede na to ze nikdo nikoho nenuti pouzivat vse. Spis mi prijde ze lide okolo D se priliz snazi ukazovat vlastnosti jazyka, ktere jsou sice krasne ale pro normalniho programatora treba i nezajimave.

[little.owl]

Nicméně autoři o tomhle vědí a Allocator API je jedna z top priorit po 1.0, v plánu je přidat to co nejdříve.

Vyborne, jen si tim s ohledem na soucasny design otevrou Pandorinu skrinku.

Naprosti tomu Go má přesně opačný problém, poskytuje featur naprosté minimum;

Coz neni vubec spatny pristup: Make things as simple as possible, but not simpler.

absence generik by mi asi vadila.

Souhlas.

Imho Go zachraňuje vliv Googlu.

Google si navrhnul Go pro sve vlastni potreby a specificke uziti, a dal ho k dispozici. To je trochu jiny pristup, nez "uvedu novy jazyk a uvidim jestli to nekdo zacne pouzivat".

[kralyk z abclinuxu]

Google si navrhnul Go pro sve vlastni potreby a specificke uziti, a dal ho k dispozici. To je trochu jiny pristup, nez "uvedu novy jazyk a uvidim jestli to nekdo zacne pouzivat".

Rust byl navržen pro Servo.

[little.owl]

Servo je dalsi experimentalni projekt.

[sid]

Otazne je ci by sa zrovna na pouzitie kde je rust cieleny gc uplatnil. Smerom hore nevidim nejaky obzvlast dovod nepouzit nejaky sucasny jazyk kde gc je a navyse nejaky typ reflection. Toto mi btw chyba v rust podstatne viac ako gc. Kludne ako volitelna sucast ked niekomu ide o velkost binarky.

[kozzi]

pomala kompilace vuci cemu? Pokud vuci C, tak to se te kritice nedivim. Rychlost kompilace je pro me jedna z nejdulezitejsich vlastnosti kompilovanych jazyku, proto mam rad napriklad D, jelikoz oficialni kompilator je vcelku velmi rychly (ackoliv obcas dovede pekne papkat RAM).

[kralyk z abclinuxu]

Vypadá to, že ani Rust neunikne genderové otázce, viz vlákno. Omg.

[xm]

Fuuuuu, ty SJW (Social Justice Warriors) jsou snad už horší než rakovina! Vidím to v poslední době všude, v programátorských komunitách se to šíří jak mor... kam tohle povede? :-/

[kralyk z abclinuxu]

Si ze mě dělaj prdel asi...

[xkucf03]

LOL. Myslím, že se tady na AbcTrollingu máme ještě hodně co učit.

[Jardík]

Na co píšou browser v rustu, když pak stejně potřebujete kraviny jako python ke kompilaci.

[Jardík]

Koukám, že se není čemu divit. Závislosti v Archu pro rust (make): perl, python2. Furt mi programy cpou 3 skriptovací jazyky, abych je vůbec mohl zkompilovat.

[Hans1024]

A vzhledem k tomu, ze Rust je napsany v Rustu, tak uz si rovnou muzes stahnout binarku

[Jardík]

To mě ani nepřekvapuje. Např FPC je psanej v pascalu. GCC/clang v C++. PyPy v rpyhtonu, ...

[pavlix]

Ono je dobrý oddělit standard od implementace, aby mohl člověk na systému, jehož základem je GCC zkompilovat kompilátor Rustu v dostatečné kvalitě, aby byl schopný kompilovat kompilátor Rustu. Pokud tomu tak není, je k bootstrapu potřeba binárka Rustu, stejně jako je k bootstrapu systému potřeba céčkovský kompilátor a pár nástrojů okolo. Rozdíl je v tom, že s céčkem se u unixových systémů tak nějak počítá, Rust potom působí tak trochu jako vetřelec.

[kralyk z abclinuxu]

Jakmile máš rustc na jednom stroji, můžeš cross-kompilovat pro další stroje...

[xkucf03]

Ale kde ten první vezmeš? Můžeš ho leda překládat nějakou starší verzí a tu ještě starší, až nakonec dojdeš k nějaké, která šla ještě přeložit něčím jiným, ne?

[pavlix]

Ještě aby ne...

[Hans1024]

Pripada mi, ze implementovat jazyk v sobe samotnem ma podstatne vic nevyhod nez vyhod. U C je to pochopitelne, neni tam moc jinych rozumnych moznosti. Ale nevim, jaky duvod k tomu maji u Rustu - mozna vyuzivani tech safety featur jazyka, ale nezda se mi, ze zrovna kompilator by je nejak moc potreboval. Osobne mi to pripada spis jako programatorska onanie, ktera komplikuje uzivatelum jazyka zivot. Mam nutkani demonstrativne implementovat trusting trust utok na Rust, ktery by byl diky jedinne relevantni implementaci toho jazyka daleko hure odhalitelny, nez stejny utok na Ceckovy kompilator.

[kralyk z abclinuxu]

Ale nevim, jaky duvod k tomu maji u Rustu - mozna vyuzivani tech safety featur jazyka

To ani ne, spíš hlavně je rustc společně se Servem takový test nasazení jazyka.

Mam nutkani demonstrativne implementovat trusting trust utok na Rust, ktery by byl diky jedinne relevantni implementaci toho jazyka daleko hure odhalitelny, nez stejny utok na Ceckovy kompilator.

Přijde mi, že když zaneseš něco do GCC, vyjde to úplně nastejno, resp. získáš ještě mnohem víc, vzhledem k tomu, co všechno je na Linuxu kompilováno GCC...

[Hans1024]

To ani ne, spíš hlavně je rustc společně se Servem takový test nasazení jazyka.

Pokud nekdo testuje jazyk tak, ze jedinna implementace kompilatoru toho jazyka je v tom jazyku, tak bych to opravdu zaradil do kategorie "programatorska onanie".

Přijde mi, že když zaneseš něco do GCC, vyjde to úplně nastejno, resp. získáš ještě mnohem víc, vzhledem k tomu, co všechno je na Linuxu kompilováno GCC...

Trusting trust na GCC s velkou pravdepodobnosti odhalim jinym ceckovym kompilatorem. Navic GCC se snad nikde nebuilduje tak, ze by se stahla "oficialni binarka" ze serveru autoru, ale distribuce pouzivaji vlastni binarky, takze se muzou navzajem kontrolovat.

[kralyk z abclinuxu]

Pokud nekdo testuje jazyk tak, ze jedinna implementace kompilatoru toho jazyka je v tom jazyku, tak bych to opravdu zaradil do kategorie "programatorska onanie".

Napsal jsem "test nasazení jazyka"... Ale klidně to do té kategorie zařaď, jsem si jist, že o tom TV Nova natočí reportáž

Trusting trust na GCC s velkou pravdepodobnosti odhalim jinym ceckovym kompilatorem.

Jde vůbec GCC skompilovat něčím jiným než GCC? Krom toho, abys skutečně spolehlivně ten útok odhalil, musel bys jít do vygenerovaného kódu, a to už je jedno, jestli udělám s céčkovým programem nebo rustovým...

Nicméně (pokus o) trusting trust útok na Rust (nebo jiný kompilátor) by byl určitě zajímavý, takže s chutí do toho...

[Hans1024]

Nechapu co ma nesmyslne komplikovani bootstrapu spoleceneho s TV Nova.

GCC jde skompilovat Clangem. A pred cca dvema lety jsem skompiloval pomoci TCC stare GCC a pomoci nej novejsi GCC a pomoci nej nejnovejsi GCC (tusim verze 4.8)

[kralyk z abclinuxu]

A zkontroloval jsi, jestli tam ten trusting trust útok není?

[Hans1024]

Zkontroloval jsem, ze v testing debianu z te doby pravdepodobne neni

[kozzi]

Tak ona to samozrejme je i trochu onanie, ale na tom nevidim nic spatneho (onanie je zdrava). Ale napriklad kompilator jazyka D bude od pristi verze obsahovat i verzi kompilatoru v D (bavim se o frontendu). Vyhod to ma nekolik.

 

1. test samotneho jazyka, jedna se o vetsi projekt na kterem se budou dobre testovat regrese, vyspelost, stabilita atd
2. snazsi a rychlejsi vyvoj, v D se proste nektere veci delaji lepe
3. pritahnuti novych vyvojaru viz. bod 2
4. safe vlastnosti jazyka

nasly by se urcite i dalsi vyhody, ale tyto jsou prvni co me ted napadly. Samozrejme je potreba brat v uvahu i nevyhody:

1. Mirne komplikovanejsi bootstrap na nove platformy
2. Urcite komplikace pro ostatni backendy (LDC a GDC)
3. Nutnost znat jazyk D pro vyvoj ci opravy (toto nevidim jako velky problem)

1. bod je jen kratkodoby problem a diky crosscompilaci to neni zas tak velky problem. U 2. bodu si nejsem jistej jak se nakonec bude postupovat, ale tusim ze to patricni lidi uz maji nejak vyresene. No a to ze clovek by mel znat jazyk pro kterej chce hackovat kompilator mi prijde vcelku jako relevatni pozadavek.